SMTP — the protocol that carries email — was designed in 1982 with no mechanism for verifying that a sender is who they claim to be. Anyone with a mail server can send an email claiming to be from president@whitehouse.gov, ceo@yourbank.com, or any address on any domain. SPF, DKIM, and DMARC are the retrofit that closes most of that gap. Here's how they actually work.
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.
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's Critical Limitation: 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.
The domain owner generates a public/private key pair. The private key stays on the mail server. The public key is published in DNS. 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 — strong evidence it was actually sent from that domain's infrastructure.
DKIM has real advantages over SPF. Because the signature is on the message itself rather than tied to the sending IP, it survives forwarding. And DKIM covers the message content: if the message is modified in transit, the signature will fail to verify.
DKIM also has limitations. It signs the message at send time; it doesn't say anything about whether the account was compromised. A phishing email sent from a compromised but legitimate mail account will pass DKIM.
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.
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).
| 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 | Partial | Yes |
DMARC also enables reporting: domain owners can receive aggregate and forensic reports showing how their domain is being used. This is how organizations discover that their domain is being actively spoofed.
What This Stack Doesn't Protect Against
SPF + DKIM + DMARC 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 registers their own domain and sets up valid SPF, DKIM, and DMARC can send email that passes all checks — from a domain that looks similar to but isn't the one you expect.
- Compromised legitimate accounts. If an attacker gains access to a legitimate email account, their emails pass all checks because they're technically authentic. 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. That's a separate problem with separate solutions.
-
Mailing list compatibility. Many mailing lists modify message bodies or subjects, breaking DKIM signatures. This is why moving directly to
p=rejectwithout understanding your mail flows can break legitimate delivery.
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) builds on DMARC enforcement to display a brand logo next to authenticated email in supported mail clients (Gmail, Yahoo Mail, Apple Mail). It requires DMARC at p=quarantine or p=reject and a validated logo SVG. BIMI is primarily a brand trust signal, not a new security mechanism.
If You Run a Domain
Publishing SPF, DKIM, and DMARC for any domain you control is basic hygiene — even for domains you don't actively send email from. A domain with no authentication records is an easier spoofing target than one with an explicit reject policy.
The deployment path: start with SPF, add DKIM, deploy DMARC at p=none with reporting to observe failures, then tighten to p=quarantine and ultimately p=reject once you're confident in your coverage. Moving directly to p=reject without understanding your full mail infrastructure will break legitimate mail flows.
Originally published at havenmessenger.com
Top comments (0)