Authentication protocols were designed to stop spoofed email — but attackers have spent years mapping the gaps between what the standard says and what mail servers actually do.
SPF, DKIM, and DMARC are the three-legged stool of email authentication. They've been around long enough that security teams treat a ✅ pass on all three as a green light. That assumption is wrong — and attackers know it.
The problem isn't the protocols. SPF correctly describes who may send mail for a domain. DKIM cryptographically signs message content. DMARC ties both to a policy and tells receivers what to do on failure. The problem is the *interpretation gap*: what a mail server does when one check passes and two fail, or when the header-from and envelope-from disagree.
SPF validates the Return-Path address (also called the envelope sender, the MAIL FROM), not the From: header your user sees in their email client. These two fields can be completely different domains.
An attacker registers victim-support.com, points its SPF record at a legitimate sending IP, and crafts a message with From: security@victim.com in the header. The SPF check passes — because the check runs against the domain they control, not the one your user is reading. This technique, called a *From header spoof with aligned envelope*, bypasses SPF without any DNS manipulation on the victim's side.
victim-support.com
From: security@victim.com
Return-Path: <bounce@victim-support.com> ← SPF passes here From: security@victim.com ← User reads this
Receivers that show SPF=pass without checking DMARC alignment hand attackers a free pass.
DKIM signs a defined set of headers and body content. The signature is attached via a DKIM-Signature header and validated against a public key in DNS. A valid DKIM signature proves two things: the signing domain authorised the message, and the signed portions haven't changed since signing.
DKIM-Signature
What it doesn't prove: that the signing domain matches the visible From: address. Domains may sign mail on behalf of others — legitimate in newsletter platforms, dangerous when abused.
From:
The nastier attack vector is DKIM replay. Attacker receives a legitimately signed marketing email from a brand they've subscribed to. They extract the message verbatim, swap the recipient in the To: header (which typically isn't part of the signed header set), and re-inject it at scale. The DKIM signature stays valid because the signed content hasn't changed. Mail security tools see a valid signature from a trusted domain, and the message sails through.
To:
Mitigations exist — h=to in the signed headers list, short key rotation — but most bulk senders don't enforce them.
h=to
DMARC aligns SPF and DKIM results against the header-from domain and applies a policy: none (monitoring only), quarantine (spam folder), or reject. The critical word is alignment. DMARC only passes if at least one of SPF or DKIM aligns with the header-from domain.
none
quarantine
reject
A common real-world configuration looks like this: a company sets p=reject on their primary domain but never covers subdomains. Attackers register mail.victim.com as a subdomain (if they can, through a takeover), or more practically, exploit the wildcard gap in subdomain policy. If the DMARC record doesn't include sp=reject, subdomain spoofing routes around the policy entirely.
p=reject
mail.victim.com
sp=reject
The aspf and adkim tags control *strict* vs *relaxed* alignment. Relaxed alignment (the default) means subdomain.example.com satisfies alignment for example.com. Strict alignment requires exact domain match. Most organisations leave alignment relaxed — a choice that widens the attack surface.
aspf
adkim
subdomain.example.com
example.com
Beyond authentication bypasses, attackers abuse MIME structure to create visual spoofs inside the message body. Multipart MIME messages contain boundaries — delimiter strings that separate text, HTML, and attachment sections. Some parsers can be confused by:
Content-Type
These tricks don't break authentication — they manipulate rendering, making a message *look* like it comes from a trusted sender even after the raw header shows something different.
When you're inspecting a suspicious message, look for these discrepancies:
p=none
The fastest way to check all of this in one pass is to copy the full raw header into a purpose-built parser. The structure can be intimidating to read manually, but the authentication chain tells a clear story once you know what you're looking for.