SPF and DKIM only tell you that the message was authenticated at the transmission layer. Attackers can still use legitimate sending services, reply-to mismatches, sender impersonation, and malicious HTML or JavaScript to deliver a harmful message that passes those checks.
Why SPF and DKIM are necessary but not sufficient
SPF and DKIM help validate how a message arrived, but they do not verify whether the content, intent, or linked destination is trustworthy. A message can pass both checks and still be crafted to steal credentials, move the recipient to a convincing lookalike site, or trigger a harmful action. The practical question is not “was it authenticated?” but “what was authenticated, and what did the sender actually use that access to deliver?”
In phishing cases, attackers often abuse legitimate mail infrastructure, brand trust, or compromised accounts so the message looks routine to both users and filters. That means SPF and DKIM can reduce obvious spoofing while leaving email impersonation and business email compromise still very much in play.
How attackers bypass the protection those checks seem to imply
SPF answers whether the sending host is allowed to send for a domain, and DKIM answers whether the message was signed by a domain key and preserved in transit. Neither control says the mailbox owner intended the message, that the display name is honest, or that the body is safe. Attackers exploit that gap by using legitimate third-party senders, compromised mail accounts, reply-to manipulation, and content that pushes the victim toward a credential harvest or invoice fraud flow.
That is why a technically valid message can still be dangerous when it contains malicious HTML, deceptive buttons, or embedded links that land on an attacker-controlled page. Modern phishing does not need to break transport authenticity if it can borrow trust from a real service. Similar abuse patterns show up when attackers reuse stolen credentials or trusted sending services to pass superficial checks, as seen in the TruffleNet stolen AWS keys campaign and CoPhish OAuth phishing via Copilot Studio.
What defenders should treat as the real trust boundary
For practitioners, SPF and DKIM should be treated as inputs to mailbox and gateway policy, not as a final safety verdict. A message that passes them may still need DMARC alignment, sender reputation context, URL inspection, attachment handling, and user-behaviour analysis before it is allowed through without friction. This is especially important where the email body is designed to create urgency, redirect payment, or harvest a session token rather than to impersonate the SMTP path itself.
The useful mental model is that authentication at the mail layer is one signal among several. A legitimate sender can be abused, and a legitimate domain can be used to distribute a malicious message. That is why email security must also account for account compromise and downstream misuse of trusted delivery systems, as illustrated by the Mailchimp breach 2022 and the credential theft path documented in EmeraldWhale Git config credential theft.
Risk and Threat Considerations
Valid SPF and DKIM can create false confidence if teams interpret them as proof that an email is safe. The main risk is not spoofed transmission alone, but trusted delivery being used to carry malicious intent from a real or compromised sender. That leaves organizations exposed to credential theft, invoice fraud, reply-chain abuse, and business email compromise even when the message appears authenticated.
Failure mechanism: The attacker uses an allowed sender, a compromised account, or a properly signed message to pass mail authentication, then places the malicious action in the body, link, attachment, or reply path where SPF and DKIM do not provide content-level protection.
Impact: Users, finance teams, and help desks may trust the message because it looks authenticated, which increases the chance of credential capture, fraudulent payment, mailbox takeover, or broader account compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Authenticated sender services still need service-level trust checks. |
| Recommendation — Validate mail service identity and pair it with content and sender-context inspection. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Phishing succeeds when authenticated channels are trusted too far. |
| Recommendation — Layer authentication with access and trust decisions before acting on email. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Passing checks is not the same as proving a safe actor or safe request. |
| Recommendation — Treat authentication as necessary input, then verify message intent and destination separately. | ||
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | Email threats require layered controls beyond transport authentication. |
| Recommendation — Harden mail and browser protections to inspect links, attachments, and destinations. | ||
Practitioner Guidance
What to verify: Check whether your mail controls evaluate domain authentication separately from sender reputation, URL reputation, and message intent. If your workflow stops at “SPF pass” or “DKIM pass,” you do not have a complete phishing decision, only a transport decision.
Decision rule: If a message asks for credentials, payment, MFA approval, or a business action, treat SPF and DKIM as background signals and require stronger scrutiny of destination, branding, reply chain, and account context before trust is extended.
Common mistake: Teams often tune filters to reduce spoofing and then assume authenticated mail is benign. That shortcut fails precisely when an attacker uses a legitimate service or a compromised mailbox to deliver the lure.
Practitioner takeaway: SPF and DKIM can tell you the message had a plausible sending path, but they cannot tell you the message was safe, honest, or non-malicious. Trust must be decided from content, destination, and sender context together, not from mail authentication alone.