Why Phishing Emails Pass SPF, DKIM, and DMARC

If SPF, DKIM, and DMARC all pass on an incoming email, it must be safe. Right?

No. That assumption is why some phishing emails land in inboxes despite showing a clean auth result on every check.

Email authentication protocols verify that the sender had permission to send for that domain. They do not verify that the sender should have been sending that particular message. That distinction sounds subtle, but it's the entire reason phishing survives email auth.

The misconception what auth passing actually proves

All three passing means: this email came from infrastructure that the domain owner authorized, and it wasn't tampered with in transit.

What it does not mean: the person using that infrastructure had good intentions.

This is the core of the confusion. Most people assume auth passing equals safe sender. It doesn't. It equals authorized sender. Those are not the same thing.

What SPF, DKIM, and DMARC each actually check

SPF - is this IP allowed to send for this domain?

SPF checks whether the IP address sending the email is listed in the domain's DNS SPF record. If the server is listed, SPF passes. If someone is sending from an IP that isn't in the record, SPF fails. SPF does not check the content of the email. It does not check who is sitting at the keyboard. It only checks: is this IP supposed to be sending for this domain?

DKIM - was this message signed by the domain and unchanged?

DKIM uses public-key cryptography. The sending mail server attaches a digital signature to the message headers, verified against the domain's public key published in DNS. If the signature is valid and nothing was altered in transit, DKIM passes. DKIM does not verify that the sender is authorized to use the account. It only verifies that the message was signed with the domain's private key and arrived intact.

DMARC - do SPF and DKIM align with the From domain?

DMARC enforces alignment. It checks that either SPF or DKIM (or both) used the same domain as the From address shown to the recipient. Without alignment, an attacker could set SPF for their own server and put your domain in the From field, SPF would pass even though the email has nothing to do with you. DMARC closes that gap.

All three passing means the email is from the right infrastructure, signed with the right key, and aligned to the right domain. It does not mean the sender is legitimate.

Why all three can pass on a phishing email

A compromised mailbox inside the organization

This is the most common explanation. Someone in the company opens a phishing link and enters their credentials. An attacker logs into their real mailbox and sends phishing through the company's legitimate mail server, Google Workspace, Microsoft 365, whatever they use. SPF passes because the IP is correct. DKIM passes because the server signed it with the real key. DMARC passes because the From domain matches SPF or DKIM alignment. No forging happened. The domain is being used against itself with full credentials.

This is exactly what happened with Truist Bank in a recent incident, discussed in detail below.

Compromised DNS

If an attacker gains access to a domain's DNS management, they can replace the SPF record with their own servers and swap the DKIM public key for one they control. SPF passes because the attacker's server is now in the record. DKIM passes because the attacker signed with the corresponding private key. DMARC passes because, from an auth perspective, the attacker is now the legitimate domain owner. DNS compromise is rare but devastating, and invisible to recipients.

Abused authorized third-party sender

Companies authorize dozens of third-party platforms to send email on their behalf: SendGrid, Mailchimp, Salesforce, HubSpot, Zendesk, and others. All of these are listed in the company's SPF record. If one of those platforms has an account compromised, or allows anyone to create an account and specify a "from" address, attackers can send through it and pass SPF. If the platform also DKIM-signs with the company's key (some do, if set up that way), both SPF and DKIM pass.

The result: legitimate auth credentials on illegitimate email.

Compromised service account or API key

Marketing automation tools, CRM integrations, and internal relay servers often have SMTP credentials stored for the company's mail system. If one of those credentials leaks in a data breach or gets left in a public GitHub repo, an attacker can relay mail through the company's own MTA. The email passes every auth check, because it genuinely originated from the company's infrastructure, via a credential the company issued.

A real example - what the headers actually show

A sysadmin posted a real incident on r/sysadmin recently. The email appeared to come from Truist Bank. The message headers showed the email originated from Truist's own internal infrastructure:

ip-10-72-1-25.ec2.internal prd-iptblk103.bbtnet.com (10.168.240.184) appliancehostname.parentdomain.com (172.25.26.10) (Forcepoint) mail12308.bbandt.com (74.120.68.127)

SPF: pass. DKIM: pass. DMARC: pass.

The email was phishing. Truist's own systems sent it.

Looking at the header chain, the email went through Truist's internal network before hitting the public internet. Thatdmar means either a compromised internal account, a compromised third-party platform Truist uses, or an abused internal relay, not an external forger. All three auth results were accurate. The email really did come from Truist. That doesn't mean a Truist employee sent it deliberately.

Someone outside the organization, or a compromised account inside it, used Truist's own infrastructure to send phishing. That's the attack pattern. That's why auth passing doesn't mean safe.

What recipients can actually check instead

Authentication results are one signal among many. They do not replace human judgment or technical inspection. Here's what actually helps when auth passes but the email looks wrong:

Unexpected requests for payment, credentials, or sensitive data. Legitimate organizations don't normally ask for this via email without prior context. Banks don't email you asking you to verify login credentials via a link.
Reply-To address that doesn't match the From address. Even when auth passes, attackers often set a different Reply-To so responses go to them.
Link destinations that don't match the supposed sender. Hover before clicking. A link that says it's from your bank but goes to a registrar you don't recognize is a problem - regardless of what the auth headers say.
Unexpected urgency or social pressure. Wire transfer requests, password expirations, account suspensions - attackers use urgency to bypass rational analysis.
Forwarded to you. Attackers often forward legitimate emails to add false legitimacy. The original email looks real; the forward header is the tell.

For organizations running their own mail servers, DMARC aggregate reports are worth monitoring. These reports tell you which servers are sending email on behalf of your domain - including servers you may not have authorized. If an unauthorized server starts sending as your domain and your own users are receiving bounce-backs or complaints, that's a signal worth investigating.

Tools like DMARCFlow make it practical to track aggregate reports across multiple domains without spending hours parsing XML. Monitoring isn't just for senders - any organization with a domain worth protecting can benefit from knowing who's sending as them.

FAQ

Doesn't DMARC p=reject stop this?

No. DMARC p=reject tells receiving servers to reject emails that don't pass authentication. But if the email passes authentication, because it genuinely originated from the domain's own infrastructure, reject does nothing. The attacker's email has the same credentials as a real employee's. p=reject prevents forgery. It doesn't prevent a compromised legitimate sender from being exploited.

Why do banks and large organizations still have phishing coming from their own domains?

Usually one of three reasons: a compromised internal mailbox, a compromised third-party platform in their SPF chain, or an abused internal system. It's not that their email security is misconfigured. It's that someone inside their authorized infrastructure was exploited.

Can I tell from the headers alone that something is wrong?

Sometimes. Look for Received headers showing unexpected routing, or Authentication-Results showing a sending infrastructure that doesn't match what the sender normally uses. But headers can be misleading, and forging Received headers is trivial. Don't rely on headers alone when the content of the email raises red flags.

Should I report this to the domain owner?

Yes. Find their abuse contact, often `abuse@domain.com` or listed in their WHOIS record. Reporting helps them detect the compromise faster. Many organizations don't know their domain is being used until a recipient tells them. The Truist sysadmin in the example was contacted by another practitioner who recognized the pattern from their own M365 environment.

Is this a failure of email authentication?

In the traditional sense, no. Email auth worked exactly as designed. The problem is that auth protocols were designed to verify sending infrastructure, not to distinguish between a legitimate sender and an attacker who has taken over that infrastructure. That's a different class of problem, and it requires different solutions: better account security, credential monitoring, and for recipients, treating unexpected requests with appropriate skepticism regardless of what the auth headers say.