Why Phishing Gets Through Despite SPF, DKIM, and DMARC

What SPF, DKIM, and DMARC Actually Authenticate

SPF authorizes which mail servers are allowed to send email for your domain. When a receiver checks SPF, it asks: "Was this message sent from a server that this domain has approved?" If yes, SPF passes. That answer tells you nothing about who is operating that server or what they are trying to send.

DKIM adds a cryptographic signature to email headers. The receiver checks: "Did this message's headers get signed by a key associated with this domain, and was the message altered in transit?" Again, a pass tells you the message came from your domain's infrastructure and wasn't tampered with - not that the sender is who they claim to be or that the message is legitimate.

DMARC ties SPF and DKIM together and adds the alignment check. It asks: "Does the domain that passed SPF or DKIM match the domain shown in the From header?" This is the crucial layer - without alignment, a骗子 could send mail through your authorized server with an SPF pass but a completely different From address. DMARC closes that gap. But it only closes it for domains you control.

The point is: all three protocols authenticate that mail originated from infrastructure authorized for a specific domain. None of them authenticate the human being who sent the message, the content of the message, or whether the links in the message lead to real destinations.

The Five Ways Phishing Bypasses Email Authentication

1. Lookalike domains

A lookalike domain uses a character that looks like a letter in your domain - think "rnbnk.com" instead of "rnbank.com" - or uses a different top-level domain. "yourcompany.co" instead of "yourcompany.com." SPF, DKIM, and DMARC all pass because the attacker genuinely owns their domain and sends mail through their own infrastructure. Your authentication protocols have no way to know that "co" is not "com." DMARC only checks alignment between the sending domain and the From domain. It does not check whether those domains are visually similar.

2. Display name spoofing

The From header in an email has two parts: the display name and the actual email address. An attacker can set the display name to "Your CEO" while using an email address like "ceo-attacker@external-domain.com." Most email clients show the display name prominently and bury the actual address. SPF passes for the external domain. DKIM passes for the external domain. DMARC alignment checks the From address against the sending domain - both external - and passes. No authentication check catches the mismatch between display name and actual email address.

3. Compromised legitimate accounts

This is the one that confuses IT administrators the most. If an attacker compromises an employee's Microsoft 365 or Google Workspace account, every email they send from that account will pass SPF, DKIM, and DMARC perfectly. The message comes from your infrastructure, your servers, your domain. The authentication is working exactly as designed. The attacker is inside your perimeter. Email authentication cannot detect credential theft - that is a different security problem.

4. Email forwarding chains

When a message is forwarded through a mailing list, a forwarding service, or an auto-forwarding rule, the message envelope gets rewritten. The original SMTP MAIL FROM is replaced by the forwarder's address. This breaks SPF - the new sending server is not in your domain's SPF record. DKIM survives in many cases because forwarding services often preserve the DKIM signature. But DMARC alignment requires both the From domain and the envelope sender to align with your domain. When the envelope sender changes during forwarding, DMARC alignment fails - even when the message is legitimate forwarded mail. Some forwarders are ARC-aware and preserve authentication results, but many are not, which means forwarding chains routinely fail DMARC without being malicious.

5. Subdomain policy gaps

This is a configuration mistake more than an attack technique, but it gets exploited. If your DMARC record is v=DMARC1; p=reject; without an sp= parameter, your policy only applies to the root domain. Subdomains are not covered by the record unless you explicitly include sp=reject. An attacker who controls a forgotten subdomain - one that was delegated to a vendor, a test environment, or an old service - can send mail that passes DMARC because the subdomain's policy defaults to none. The attacker doesn't need to spoof your root domain. They just use a subdomain you forgot to protect.

What DMARC at p=reject Actually Protects

DMARC at p=reject stops spoofing from domains you do not control. When someone tries to send mail with a From address claiming to be from your domain, but the message originates from infrastructure not authorized for your domain, DMARC catches it and the receiver rejects it.

This is real protection. It stops the most common form of domain spoofing - the Nigeria prince emails, the fake invoice scams, the phishing that claims to be from your bank. If your domain has high Brand recognition, p=reject reduces impersonation emails that use your domain fraudulently.

But it protects against a specific attack vector: external actors pretending to be you using your domain name.

What DMARC Does Not Protect You Against

Business Email Compromise (BEC): When an attacker uses a genuinely different domain that looks like yours, or compromises a vendor who sends mail on your behalf, DMARC does not help. BEC often uses lookalike domains or compromised consumer email accounts that have their own valid SPF/DKIM/DMARC configuration. The attacker owns their domain and controls it legitimately.

Internal account takeover: As described above. DMARC cannot detect credential theft. A compromised internal account sends mail that looks exactly like every other employee email. Authentication passes. The attack is invisible to email authentication.

Malicious links: None of these protocols inspect URLs, analyze attachments, or check for social engineering patterns in the message body. DMARC tells you a message came from an authorized server. It says nothing about whether the links in that message lead to a credential harvesting page.

Display name manipulation: Described above. DMARC checks the From address domain - not the display name. An attacker who spoofs the display name while using a valid external email address will pass DMARC authentication on many configurations.

Forwarding failures: When legitimate forwarding breaks DMARC alignment, the email may be rejected - not because it is malicious, but because the forwarding infrastructure modified the envelope. This is a deliverability problem, not a security failure.

How to Detect Impersonation Attempts with DMARC Reports

DMARC aggregate reports (sent to your rua= endpoint) tell you which servers are sending mail claiming to be from your domain, and whether those servers are passing or failing authentication. When you see failed authentication events from servers you do not recognize, that is a signal worth investigating.

For example: if your DMARC reports show that emails are being sent from IP addresses in countries where you have no vendors, or from netblocks you have not authorized, those failed-auth events are likely spoofing attempts that your p=reject policy blocked. Monitoring your DMARC aggregate reports turns your reject policy into a detection mechanism - you know which attackers tried to impersonate your domain and failed.

Forensic reports (sent to ruf=) give you individual message-level detail on failures. When a high-value domain like your CFO's executive@ address shows failed authentication attempts, that is a credible signal of a targeted impersonation campaign.

Most organizations that implement DMARC never look at these reports. They configure p=reject, consider the problem solved, and miss the intelligence in their own mailbox.

Layered Email Security: What You Need Beyond DMARC

Email authentication is the foundation. It is not the whole security stack.

Anti-impersonation policies: Add sender identity verification that checks whether the display name matches the actual sender address for high-value targets like executives and finance teams. Microsoft Defender for Office 365 and Google Workspace have these features. They catch display name spoofing that DMARC misses.

Link isolation: Even if a link passes all authentication checks, it can still lead to a credential harvesting page. Link sandboxing - opening URLs in an isolated browser environment - catches malicious links that make it past URL filtering.

Account compromise detection: Monitor for anomalies in internal send behavior. A compromised account often exhibits unusual patterns: sending at odd hours, high recipient counts, similar messages to multiple contacts in a short window. This is not email authentication - it is behavioral analytics on top of your email infrastructure.

DMARC forensic reporting: Review your RUF reports for failed authentication targeting high-value senders. Catch impersonation attempts that your p=reject policy blocked before you can analyze them.

Vendor and subdomain inventory: Audit which subdomains you have, who controls them, and what their DMARC policies are. Forgotten subdomains are a common entry point. Your DMARC aggregate reports will show you which subdomains are generating authentication failures - that is your inventory of unprotected space.

Frequently Asked Questions

Does DMARC stop all phishing?

No. DMARC authenticates domain ownership, not sender intent. It stops external domain spoofing but cannot detect lookalike domains, compromised accounts, or malicious links.

Why does my p=reject policy still let phishing through?

Because the phishing is not using your domain in the From address. It is coming from lookalike domains, compromised internal accounts, or using display name manipulation that your DMARC policy does not catch.

Is SPF, DKIM, and DMARC useless?

No. They are necessary foundational controls. Without them, external domain spoofing is trivial. With them, you eliminate the easiest and most common phishing vector. But they are the first layer, not the last.

What additional protections should I add?

Anti-impersonation for executive names, link isolation, account anomaly detection, and regular review of DMARC aggregate and forensic reports. DMARC protects your domain's identity. The other layers protect against the attacks that authentication cannot see.

The Short Version

SPF, DKIM, and DMARC authenticate that mail came from infrastructure authorized for a specific domain. They do not authenticate the human sender, the message content, or the destination of links. Phishing works because attackers exploit gaps these protocols were never designed to fill: lookalike domains, display name spoofing, compromised accounts, and forwarding chain rewriting.

Deploying DMARC at p=reject eliminates external domain spoofing. That is worth doing. But organizations that stop there will continue to get phished - not because their configuration is wrong, but because the threat operates outside what these protocols can see.

Monitor your DMARC reports. Catch the impersonation attempts your policy blocked. Use that signal to understand who is targeting your domain and what they are trying to do. DMARCFlow automates aggregate and forensic report collection and surfaces the failed-authentication events that matter, so you can investigate before the next phishing campaign succeeds.