SPF DKIM Passing Phishing Emails: Why Authentication Fails

SPF and DKIM confirm that a message's sending server and signing domain are authorized and that the content was not altered in transit. They say nothing about whether the request inside the message makes sense for the recipient. Attackers using real sending platforms, compromised vendor accounts, or hijacked mailboxes pass both checks while still delivering credential phishing.

Key takeaways

What do SPF and DKIM actually verify?

Email authentication was built to answer one question: is this message coming from a server or domain that's allowed to send it? That's a narrower question than "is this message safe?" and the gap between the two is where a lot of current phishing lives.

What does SPF check?

SPF (Sender Policy Framework) checks whether the sending IP address is listed in the DNS record for the envelope sender domain, also known as the Return-Path. It's an infrastructure check. It doesn't look at the visible From address a recipient sees, and it doesn't look at what the email asks the recipient to do.

What does DKIM check?

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the message using a private key controlled by the sending domain. A passing signature means the message wasn't altered after it left that domain's servers. It confirms integrity and a verified signing domain, not that the request inside the message is legitimate.

What do neither protocol check?

Neither SPF nor DKIM evaluates:

How do attackers send phishing through legitimate platforms?

Attackers abuse sending platforms that recipients already trust and already receive mail from, rather than trying to spoof a domain outright.

In an AegisAI review of attacks reaching Writer, the pattern was explicit: "The attacks reaching Writer were built to give a rule nothing to fire on: real sending platforms, compromised vendor domains, valid SPF and DKIM, lookalike infrastructure registered the morning of the attack, and a malicious link hidden one layer down inside an attachment."

Three lures from that review illustrate the point:

In all three cases, authentication worked exactly as designed. The sending infrastructure was genuine. That's precisely why the checks returned clean.

Why do compromised vendor domains defeat authentication?

Platform abuse is one path. Account takeover is another. An attacker compromises a real mailbox at a vendor or partner organization, then sends from it directly. Since the mail originates from the real tenant, every check passes: SPF passes, DKIM passes, DMARC passes, and the display name, reply-to address, and signing domain are all genuine.

One account takeover analysis put it directly: "SPF passes. DKIM passes. DMARC passes. The headers are clean. The display name is real. The reply-to address is real" (Infinet, March 2026). The same piece notes that authentication protocols "verify that the sender is who they say they are, not that the message is legitimate."

This is a structural limitation, not a configuration mistake. No amount of DMARC enforcement changes the outcome when the attacker is operating from inside an account that was never forged to begin with. AegisAI's own research into compromised infrastructure used in AI spearphishing documents the same shift away from forged domains toward living off infrastructure that's already trusted.

Is authentication evidence or a verdict?

Forensic analysis treats authentication results as one data point among several, not a standalone answer. SPF only validates the envelope sender, which can differ from the visible From header a recipient actually reads. A passing DKIM signature on the From-header signing domain is a stronger signal, but it still only tells an investigator where the message came from, not what it's asking the recipient to do (Sherlock Forensics, June 2026).

Authentication headers are useful for tracing a message's path during an investigation. They were never designed to evaluate whether a request is appropriate for the person receiving it.

What does contextual email security check instead?

If authentication confirms the pipe is clean but says nothing about what's flowing through it, detection has to move to a different layer: the content, the destination, and the fit between the request and the recipient.

That means investigating a message the way an analyst would, not just the way a filter would:

This is the gap AegisAI's agentic investigation is built to close: it follows links and attachments to their final destination and evaluates whether the resulting request is plausible for the recipient's role, rather than stopping once a sending domain checks out. For a deeper look at how the underlying protocols fit together and where each one stops short, see AegisAI's explainer on SPF, DKIM, and DMARC architecture.

FAQ

See where authentication-passing phishing gets through

If credential phishing is reaching inboxes despite clean SPF and DKIM results, the gap is likely in how those requests are evaluated after authentication passes. Book a demo to see how AegisAI investigates links and attachments to their final destination.