Website and Email Security Mistakes We Keep Seeing
March 2026
- 7 minute read
Each month, vulnerabilities affecting email infrastructure are disclosed across platforms, gateways, and delivery services. In most cases, exploitation does not depend on a single technical weakness but on gaps between authentication, enforcement, and monitoring.
Email security controls are frequently deployed, yet domain abuse and impersonation incidents continue to occur in environments where baseline protections already exist.
This edition focuses on recurring configuration mistakes that allow email-based threats to remain operational despite authentication being present.
Mistake 1: Publishing SPF records that exceed lookup limits
Where this shows up
- Microsoft 365 tenants
- Google Workspace domains
- Marketing platform integrations
- Multi-provider sending environments
How this happens
SPF records are expanded over time as new services are added. Each additional provider introduces includes, redirects, or nested references that increase DNS lookup complexity.
As integrations accumulate, the lookup count exceeds permitted limits without being detected during routine configuration updates.
Why this causes damage
The issue is not the presence of SPF, but loss of evaluation reliability. When lookup limits are exceeded, SPF validation may fail silently or produce unpredictable results, allowing unauthorized senders to pass validation in some receiving environments.
How to avoid this mistake
- Audit SPF lookup depth regularly
- Consolidate sending providers where possible
- Remove unused includes
- Test SPF behaviour after configuration changes
Mistake 2: Assuming DKIM alone protects against domain impersonation
Where this shows up
- Business email domains
- Newsletter platforms
- SaaS-generated transactional email
How this happens
DKIM signing is enabled by default within email platforms. Because signatures validate successfully, the domain is assumed to be protected against spoofing.
However, DKIM validation alone does not enforce alignment or rejection behaviour.
Why this causes damage
The issue is not missing DKIM, but misunderstanding its scope. DKIM confirms message integrity, not sender legitimacy. Without alignment enforcement through DMARC policy progression, attackers can still impersonate the domain in receiving environments that do not strictly evaluate alignment.
How to avoid this mistake
- Verify DKIM alignment with the visible sender domain
- Combine DKIM with enforced DMARC policy
- Monitor authentication results in aggregate reports
- Treat DKIM as one component of domain protection
Mistake 3: Leaving DMARC reporting enabled but unreviewed
Where this shows up
- Domains with DMARC policy set to none
- Early-stage authentication deployments
- Organisations using multiple email platforms
How this happens
DMARC reporting is enabled to observe authentication behaviour before enforcement decisions are made. Reports begin arriving but are not assigned ownership or review processes.
Over time, reporting remains active without influencing configuration decisions.
Why this causes damage
The issue is not absence of reporting, but absence of interpretation. DMARC reports provide visibility into unauthorized sending sources. When they are not analysed, spoofing activity can continue undetected even though telemetry exists.
How to avoid this mistake
- Assign ownership for DMARC report review
- Establish review intervals
- Identify unknown sending sources
- Progress policy beyond monitoring once alignment is verified
Mistake 4: Allowing unused sending services to remain authorised
Where this shows up
- Legacy marketing platforms
- Retired CRM integrations
- Historic automation workflows
How this happens
Email platforms are authorised through SPF or DKIM during earlier deployments. When services are retired, authentication references remain in DNS configuration.
These unused services continue to appear as authorised senders.
Why this causes damage
The issue is not authentication misconfiguration, but authentication persistence. When unused services remain authorised, compromised accounts within those platforms may still send trusted messages from the domain.
How to avoid this mistake
- Inventory authorised sending platforms
- Remove unused SPF includes
- Rotate DKIM selectors when services change
- Review authentication configuration periodically
Mistake 5: Treating inbound filtering as a replacement for domain protection
Where this shows up
- Organisations relying on secure email gateways
- Microsoft Defender deployments
- Hosted filtering environments
How this happens
Inbound filtering solutions are deployed to reduce phishing exposure. Because filtering blocks malicious messages entering the organisation, domain-level authentication enforcement is deprioritised.
Protection is treated as perimeter filtering rather than identity protection.
Why this causes damage
The issue is not filtering effectiveness, but scope misunderstanding. Inbound filtering protects recipients. It does not prevent attackers from impersonating the organisation when targeting external parties.
Without enforced outbound authentication policy, domain reputation remains exposed.
How to avoid this mistake
- Enforce DMARC policy progression
- Monitor external spoofing indicators
- Validate domain alignment across senders
- Treat filtering and authentication as separate controls
Closing observation
Across these cases, authentication mechanisms were present but incomplete as protection controls. SPF existed without evaluation reliability, DKIM existed without alignment enforcement, and DMARC existed without operational review.
Email compromise rarely begins with missing authentication. It begins with authentication that exists but is not maintained as an active control.
This pattern remains consistent across organisations of different sizes and platforms and typically persists until ownership of domain-level email authentication becomes explicit and continuous.
Each month, new email-related vulnerabilities appear.
However, most email security incidents are not caused by missing protections.
They happen when authentication controls exist but are not enforced or reviewed properly.
This edition focuses on recurring email configuration mistakes that allow spoofing and impersonation to continue.
Mistake 1: Publishing SPF records that exceed lookup limits
Where this shows up
- Microsoft 365 tenants
- Google Workspace domains
- Marketing platform integrations
- Multi-provider sending environments
How this happens
SPF records grow as new services are added.
Each service increases the number of DNS lookups.
Over time, the record exceeds the allowed lookup limit.
This usually happens without being noticed.
Why this causes damage
SPF still exists but stops working reliably.
Some receiving systems cannot evaluate the record correctly.
Unauthorized senders may pass validation in certain situations.
How to avoid this mistake
- Review SPF lookup depth regularly
- Remove unused sending services
- Consolidate providers where possible
- Test SPF behaviour after configuration changes
Mistake 2: Assuming DKIM alone protects against impersonation
Where this shows up
- Business email domains
- Newsletter platforms
- SaaS-generated transactional email
How this happens
DKIM signing is enabled by default in many platforms.
Because signatures validate successfully, the domain appears protected.
However, DKIM does not enforce sender identity by itself.
Why this causes damage
DKIM confirms message integrity.
It does not confirm whether the sender is authorised.
Without DMARC enforcement, attackers can still impersonate the domain.
How to avoid this mistake
- Verify DKIM alignment with the visible sender domain
- Combine DKIM with enforced DMARC policy
- Monitor authentication results in reports
- Treat DKIM as one layer of domain protection
Mistake 3: Leaving DMARC reporting enabled but unreviewed
Where this shows up
- Domains with DMARC policy set to none
- Early-stage authentication deployments
- Organisations using multiple email platforms
How this happens
DMARC reporting is enabled to observe authentication behaviour.
Reports begin arriving but are not reviewed regularly.
Over time, the configuration remains unchanged.
Why this causes damage
DMARC reports show who is sending email using your domain.
If reports are not reviewed, unauthorized sending activity remains unnoticed.
How to avoid this mistake
- Assign ownership for DMARC report review
- Establish review intervals
- Identify unknown sending sources
- Progress policy beyond monitoring once alignment is verified
Mistake 4: Allowing unused sending services to remain authorised
Where this shows up
- Legacy marketing platforms
- Retired CRM integrations
- Historic automation workflows
How this happens
Older email services remain authorised in SPF or DKIM records.
These services are no longer used but remain trusted senders.
This increases exposure without being noticed.
Why this causes damage
Unused authorised services can still send trusted messages.
If those services are compromised, attackers may send email using your domain.
How to avoid this mistake
- Maintain an inventory of authorised sending platforms
- Remove unused SPF includes
- Rotate DKIM selectors when services change
- Review authentication configuration periodically
Mistake 5: Treating inbound filtering as a replacement for domain protection
Where this shows up
- Organisations relying on secure email gateways
- Microsoft Defender deployments
- Hosted filtering environments
How this happens
Inbound filtering blocks malicious messages entering the organisation.
Because filtering reduces internal risk, domain authentication enforcement is delayed.
Protection is treated as filtering only.
Why this causes damage
Inbound filtering protects recipients inside the organisation.
It does not prevent attackers from impersonating your domain when targeting external recipients.
Domain reputation remains exposed.
How to avoid this mistake
- Enforce DMARC policy progression
- Monitor external spoofing indicators
- Validate domain alignment across senders
- Treat filtering and authentication as separate controls
Closing observation
Email authentication controls are usually already deployed.
The issue is incomplete enforcement and missing review processes.
SPF may exist but exceed lookup limits.
DKIM may exist without alignment enforcement.
DMARC may exist without operational monitoring.
These gaps allow impersonation to continue even when protections appear to be in place.
Need expert help protecting your environment?
Get Started