Why Your Email Can Still Be Spoofed Even With SPF, DKIM, and DMARC

SPF, DKIM, and DMARC all passed. Someone still received an email impersonating your address. Here is what that actually means and why the three protocols do not prevent it.

The answer comes down to what each protocol actually checks. SPF and DKIM verify that the sending server is authorized and that the message was not tampered with. DMARC requires them to be aligned with the From header domain. But these protocols verify the authorization chain, not the display chain. The impersonation usually happens in the part they do not cover.

DMARCFlow helps by giving you aggregate visibility across all your domains so you can identify which of the three scenarios below is actually happening when a spoofing report comes in.

What SPF, DKIM, and DMARC Actually Protect

SPF authorizes the envelope MAIL FROM. This is the server-to-server address, not what users see in their email client. DKIM signs the message body and selected headers using a cryptographic key published in DNS. The signing domain is embedded in the DKIM-Signature header and does not have to match the From address. DMARC bridges them: it requires either SPF or DKIM to pass and to be aligned, which means the domain in the From header must match the domain that passed SPF or DKIM.

The critical distinction is this: these protocols protect the authorization chain, not what the recipient sees in their email client.

The Three Scenarios Where Spoofing Happens Even With Full Auth

Mailing Lists and Auto-Forwarding Break the Auth Chain

When a message goes through a mailing list or auto-forwarding service, the server rewrites the envelope MAIL FROM to its own domain. SPF then validates the mailing list server, not your domain. Many mailing list tools also modify headers or add content, which breaks DKIM. DMARC alignment fails because the From header domain does not match the mailing list domain.

The recipient sees your address in the From header. The servers see a message authorized by the mailing list domain. This is the scenario behind most "I received an email from myself" reports. It is a structural consequence of forwarding, not an attack.

Subdomains Without SPF and DMARC Send Without Restriction

This one trips up people who have done email security correctly at the root domain. If example.com has p=reject, you might assume all subdomains are equally protected. They are not.

A subdomain that sends mail, like legacy.example.com, needs its own SPF record and its own DMARC policy. If legacy.example.com has neither: - The subdomain can send mail without any SPF check preventing it. SPF for the subdomain simply has no mechanisms to evaluate, so no check fails and no check passes. - There is no DMARC record for legacy.example.com, so DMARC does not apply to mail from that subdomain at all.

The practical consequence: if legacy.example.com has no SPF and no DMARC, any system at that subdomain can send mail that arrives with a From address in the example.com family. DMARCFlow aggregate reports surface this gap by showing which subdomains are generating alignment failures or sending without any DMARC record at all.

From-Display Impersonation Passes All Three Protocols

This is the subtlest case and the one most likely to cause genuine confusion.

An attacker sets up a mail server they control with valid SPF and DKIM for attacker.com. In their email client, they set the From display name to "Your Company Name" while the actual RFC 5322 From address is attacker.com. SPF passes for attacker.com. DKIM passes for attacker.com. DMARC alignment passes for attacker.com. Every protocol works correctly.

The recipient sees the display name Your Company Name, not the actual email address. The message passes all authentication because all authentication is checked against attacker.com, which is exactly what the attacker owns and operates.

This is why BIMI does not prevent it. BIMI verifies the logo associated with the DKIM signing domain. It does not verify that the From display name matches anything.

How to Diagnose Which Scenario You Are Dealing With

The diagnostic is in the message headers, specifically in the Authentication-Results header and the difference between the envelope sender and the From header.

Look at the RFC 5321 Mail From address (envelope) versus the RFC 5322 From header (what recipients see). Then look at which authentication checks passed and for which domains.

Mailing list forwarding shows as: envelope sender is forwards@example.com, From header is user@example.com, SPF fail or DKIM fail for example.com. DMARC fails because the From domain does not match the envelope domain.

Subdomain gap shows as: aggregate reports showing subdomains with no SPF mechanism and no DMARC record. DMARCFlow surfaces these across all your domains in one view, making it faster to spot which subdomain has no policy and is generating alignment failures.

Display name spoofing shows as: SPF and DKIM both pass for an unrelated domain, DMARC passes for that same unrelated domain. The From header display name is your organization, but the From header address is something else. The recipient sees the name, not the address.

How DMARCFlow Helps

The diagnosis requires aggregate report data. DMARCFlow collects aggregate reports and surfaces the specific alignment failures that distinguish forwarding from subdomain gaps from display spoofing. When a spoofing report comes in, DMARCFlow shows you which failure mode you are dealing with, which domains are involved, and how the pattern has changed over time.

This is more useful than reading raw aggregate reports because the tool highlights the domains and failure types that need attention rather than requiring you to parse XML yourself.

Quick Checklist

• SPF protects the envelope MAIL FROM, not the From header address.
• DKIM signs for a domain that does not have to match the From address.
• DMARC requires alignment: the From domain must match the SPF or DKIM domain.
• Mailing lists and auto-forwarding break the auth chain and cause DMARC failures for legitimate forwarded mail.
• Subdomains without SPF and DMARC are gaps. The root domain policy does not cover them. They can send without restriction.
• From-display impersonation passes all three protocols. It exploits display, not the auth chain.
• Aggregate reports are the diagnostic tool. DMARCFlow surfaces the specific failure patterns so you can identify which scenario you are dealing with.