Email spoofing — sending a message that falsely claims a sender address — has existed for as long as email itself. It's the enabling mechanism for a significant fraction of phishing, business email compromise, and brand impersonation. The three email authentication standards built to address it each solve a different piece of the problem, and they layer together in a specific way.
Understanding them separately before understanding how they interact makes the overall picture clearer.
SPF: Authorizing Sending Servers
Sender Policy Framework (SPF) is the simplest of the three standards. A domain owner publishes a DNS TXT record listing which IP addresses and mail servers are authorized to send email on behalf of that domain. When a receiving mail server gets a message claiming to be from your domain, it looks up your SPF record and checks whether the sending server's IP is on the list.
An SPF record looks like this:
v=spf1 include:_spf.google.com ip4:203.0.113.1 -all
This says: messages from this domain should come from Google's mail servers or the specific IP 203.0.113.1. Anything else should fail (-all means hard fail; ~all means soft fail).
SPF checks the envelope sender (the MAIL FROM address in the SMTP session), not the From header that users actually see in their mail client. These can be different. A sophisticated spoof can pass SPF on the envelope address while showing a different, spoofed From header to the recipient.
SPF also breaks when email is forwarded. When a forwarding server relays your message to the final destination, the original IP is no longer in the path — the forwarder's IP is. The receiving server checks SPF against the forwarder's IP, which isn't in your SPF record, and the check fails even though the email is legitimate. This is one of the reasons SPF alone isn't sufficient.
DKIM: Cryptographic Signing
DomainKeys Identified Mail (DKIM) takes a different approach. Instead of checking which server sent the mail, it checks whether the message was cryptographically signed by the domain it claims to come from.
Here's how it works: the domain owner generates a public/private key pair. The private key stays on the mail server. The public key is published in DNS (as a TXT record at a specific subdomain). When the mail server sends a message, it signs a defined set of headers and the message body with the private key and adds the signature as a DKIM-Signature header.
When the receiving server gets the message, it fetches the public key from DNS and uses it to verify the signature. If it verifies, the message was signed by someone who has the private key for that domain — which is strong evidence it was actually sent from that domain's infrastructure.
DKIM has advantages over SPF. Because the signature is on the message itself rather than tied to the sending IP, it survives forwarding — the forwarder doesn't need to resign the message. And DKIM covers the message content: if the message is modified in transit (headers or body), the signature will fail to verify, detecting tampering.
DKIM also has limitations. It signs the message at send time; it doesn't say anything about whether the account was compromised or whether the sender is actually who you think they are. A phishing email sent from a compromised but legitimate mail account will pass DKIM. It also doesn't prevent replay attacks — a valid DKIM-signed message could theoretically be re-sent.
DMARC: The Policy Layer That Ties Them Together
Domain-based Message Authentication, Reporting and Conformance (DMARC) is what makes SPF and DKIM useful for preventing spoofing of the visible From address.
DMARC does two things. First, it requires alignment: for a message to pass DMARC, either SPF or DKIM must pass and the domain used in those checks must align with the domain in the visible From header. This closes the gap that SPF alone leaves — you can't pass SPF on a different envelope address while showing a spoofed From header.
Second, DMARC lets domain owners specify what receiving servers should do with messages that fail: nothing (p=none), mark them as spam (p=quarantine), or reject them outright (p=reject). A domain with p=reject DMARC enforcement is telling the world: if a message claims to be from us but fails authentication, throw it away.
| Standard | Checks | Survives Forwarding | Covers Visible From |
|---|---|---|---|
| SPF | Sending server IP against DNS allowlist | ✗ No | ✗ No |
| DKIM | Cryptographic signature from sending domain | ✓ Yes | ✗ Alone, no |
| DMARC | Alignment of SPF/DKIM with visible From + policy enforcement | ~ Partial | ✓ Yes |
DMARC also enables reporting: domain owners can receive aggregate reports (from receiving mail servers) and forensic reports (per-message failure details) that show how their domain is being used across the internet. This reporting is how organizations discover that their domain is being actively spoofed.
What This Stack Doesn't Protect Against
SPF + DKIM + DMARC, properly configured with a reject policy, is robust protection against direct domain spoofing. But it's worth being clear about what it doesn't do:
- Authenticated phishing. An attacker who controls a domain and sets up valid SPF, DKIM, and DMARC for that domain can send email that passes all authentication checks — from a domain that looks similar to but isn't the one you expect. havenmessenger.com has full email authentication; haven-messenger.com could too, if someone registered it.
- Content manipulation from legitimate accounts. If an attacker gains access to a legitimate email account, emails they send from that account will pass all authentication checks, because they're technically legitimate. Authentication proves the message came from the domain's infrastructure; it doesn't prove the account wasn't compromised.
- Email encryption. SPF, DKIM, and DMARC say nothing about whether your email is encrypted in transit or at rest. Email encryption is a separate problem with separate solutions.
- Mailing list modification. Many mailing lists modify message bodies or subject lines, which breaks DKIM signatures. This is a known compatibility issue and the reason why DMARC at
p=rejectcan cause delivery problems for domains that use mailing lists heavily.
A message that passes DMARC was sent by infrastructure authorized by the domain it claims to be from. It was not necessarily sent by someone you trust, from an account that wasn't compromised, with content you should trust. Authentication is a floor, not a ceiling.
BIMI: The Optional Fourth Layer
Brand Indicators for Message Identification (BIMI) is an extension that builds on DMARC enforcement to display a brand logo next to authenticated email in supported mail clients. Gmail, Yahoo Mail, and Apple Mail are among the clients that support it.
BIMI requires a domain to have DMARC at p=quarantine or p=reject and a validated logo SVG file. Some implementations also require a Verified Mark Certificate (VMC) from a certificate authority, which involves trademark verification. BIMI is primarily a brand trust signal — the logo tells recipients the email is authenticated — rather than a new security mechanism.
If You Run a Domain
Publishing SPF, DKIM, and DMARC for any domain you control is a basic hygiene requirement, even for domains you don't send email from. A domain with no email authentication records is an easier target for spoofing than one with an explicit reject policy.
The deployment path: start with SPF (list your authorized senders), add DKIM (configure your mail server to sign outgoing mail, publish the public key), deploy DMARC at p=none with reporting to observe failures, then tighten to p=quarantine and ultimately p=reject once you're confident in coverage. Moving directly to p=reject without understanding your full mail infrastructure will break legitimate mail flows.
Email aliases add another layer to this stack for personal privacy — separating your identity from your address — but rely on the same authentication infrastructure underneath.