Why do attacks that pass SPF and DKIM still create real risk for organisations?

SPF and DKIM only prove that a message was authorised by the sending domain, not that the message is safe. Attackers can abuse legitimate platforms or compromised accounts to send convincing fraud attempts that still reach users. Once the recipient engages, the attacker can drive the victim into payment fraud, data disclosure, or remote access abuse.

Why SPF and DKIM Are Only Part of the Trust Signal

SPF and DKIM help recipients and mail systems verify that a message was sent from an allowed infrastructure path and that the content was not altered in transit. That is useful, but it is not the same as proving the sender is trustworthy or the message is benign. A valid signature can still carry a malicious request, a fraudulent invoice, or a social-engineering lure.

The important distinction is between message authenticity and message intent. Email authentication reduces impersonation at the protocol layer, yet it does not judge business context, user expectation, or whether the sender has been compromised. That is why organisations still need policy, user verification, and mailbox controls around email identity and BEC defence.

In practice, SPF and DKIM are strongest when they are treated as filtering signals, not as a final trust decision. They can lower the odds of crude spoofing, but they cannot distinguish a legitimate supplier from a compromised supplier account, or a real invoice from a fraud attempt sent through a legitimate service.

How Real Abuse Still Gets Through Legitimate Email Paths

Attackers do not need to break SPF or DKIM to cause harm. They can abuse a compromised mailbox, a sanctioned bulk mail platform, or a third-party service that the domain has authorised to send on its behalf. In those cases the message can pass technical checks and still be malicious because the sending path is legitimate even though the content or intent is not.

This is why recipient behaviour matters so much. Once a user trusts the message, the attacker can pivot from delivery to action, such as redirecting payments, harvesting credentials, inducing document disclosure, or steering the victim into a remote access workflow. The control gap is often not message delivery, but downstream decision-making after delivery.

That pattern is common across email-driven fraud and account abuse, and it is one reason broad incident collections matter. Real-world compromise cases show how legitimate access paths, stolen credentials, and trusted services can be combined into successful fraud or lateral movement, even when basic validation checks are satisfied. The 52 NHI Breaches Report is useful here because it illustrates how trusted access is abused after the initial trust boundary has already been crossed.

What Organisations Need to Verify Beyond SPF and DKIM

Organisations need to verify the transaction, not just the email. That means checking whether the request matches normal business flow, whether the sender identity fits the context, whether the payment or data request is expected, and whether the message originates from a path that matches the recipient’s relationship with that party. Email controls should be paired with anti-fraud processes, mailbox hardening, and access governance for any service that can send mail on behalf of the business.

When the message asks for money, credentials, or sensitive documents, the safest judgment is to require an independent verification step outside the email channel. That is especially important where an attacker may be using a compromised account, because the technical authenticity checks can still be satisfied while the operational request is fraudulent.

For organisations that rely on cloud mail systems or delegated sender permissions, the practical question is whether the environment can still be abused after authentication succeeds. That is why sending permissions, mailbox rules, and third-party integrations should be reviewed as part of the control set, not treated as separate from email security.

Risk and Threat Considerations

Passing SPF and DKIM can create a false sense of safety. The main risk is that defenders and users may over-trust a message because it appears authenticated, even though the sender account, sending service, or business process has been abused to deliver fraud.

Failure mechanism: The attacker uses a legitimate or compromised sending path, so protocol checks succeed while the message content drives payment fraud, credential theft, data disclosure, or remote access abuse.

Impact: The organisation may suffer financial loss, account compromise, confidential data exposure, or operational disruption, and the message is more likely to bypass attention because it arrived through a trusted channel.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-5 — Account Management	Email abuse often rides on compromised accounts and delegated senders.
Recommendation — Review and disable unnecessary sending accounts and delegated mail permissions.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Authenticated mail paths still depend on secret and token lifecycle control.
	AU-6 — Audit Review, Analysis, and Reporting	Detecting fraudulent authenticated mail depends on reviewing mail and mailbox activity.
Recommendation — Rotate and retire mail-related credentials and tokens on a defined lifecycle. Correlate sender, mailbox, and payment-change activity for suspicious patterns.
ISO/IEC 27001:2022	A.5.16 — Identity management	Trusted senders and delegated services need clear ownership and review.
Recommendation — Assign ownership for authorised mail senders and review them periodically.
OWASP ASVS	V10 — OAuth and OIDC	Mail fraud often follows abuse of delegated access and connected services.
Recommendation — Validate delegated access and revoke unneeded third-party mail permissions.

Practitioner Guidance

What to verify: Treat SPF and DKIM as one input to triage, not as a trust decision. Verify whether the sender, the request, and the business context all align before a user can approve payment, share data, or grant access.

Decision rule: If the message asks for money, credentials, or a change to payment details, require an out-of-band confirmation path and assume the email channel itself may already be compromised.

Common mistake: Teams often block spoofing but leave mailbox compromise, delegated senders, and workflow abuse untouched. That leaves the organisation protected against forged headers but exposed to authenticated fraud.

Practitioner takeaway: The right question is not whether the email passed authentication, but whether the request can be trusted independently of the message transport.