SPF, DKIM, DMARC:
The Mail Authentication Trio

SMTP, the protocol that delivers email, was designed in 1982 with no authentication of any kind. Anyone can send a message claiming to be from anyone. Without help, every email is anonymous.

This was fine in 1982 because the entire internet trusted itself. By the time spam, phishing, and business-email-compromise became the dominant economic activity on email, the protocol was too widely deployed to redesign. So the industry stacked authentication standards on top of SMTP, one at a time, each filling a different gap that the others had missed.

The result is the trio on this page. None of them are mandatory parts of SMTP. None of them prevent a message from being sent. All of them help the receiver decide whether to trust a message after it arrives. They are also additive: a domain that publishes all three is much harder to spoof than a domain that publishes one or none.

SPF is an allow-list of IP addresses (and other domains) permitted to send mail for your domain. It lives as a single TXT record in DNS.

The domain owner publishes a list saying, in effect, "these IPs and these third-party services are allowed to send email claiming to be from me." When a receiving server gets a message, it looks at the SMTP envelope sender's domain, pulls up that domain's SPF record, and checks whether the connecting IP is in the allow-list. If it is, SPF passes. If it is not, SPF fails (or soft-fails, depending on the all-mechanism at the end of the record).

SPF has limits. It checks the MAIL FROM address (the envelope sender, which becomes Return-Path), not the visible From: header. A phisher can put one domain in the envelope and a different domain in the visible From, and SPF will happily pass on the envelope while the user still sees the spoofed name. DMARC (later) closes this gap by checking alignment between the two.

Read the record as a series of mechanisms separated by spaces. Each mechanism either matches the connecting IP or does not. Evaluation stops at the first match. The final all mechanism is the catch-all and decides what happens when nothing else matched.

DKIM cryptographically signs each outgoing message with a private key. The matching public key lives in the sender's DNS. Receivers verify the signature against the public key and know the message has not been tampered with in transit.

The sending mail server computes a cryptographic hash over the body and a selected list of headers, then signs the hash with its private RSA or Ed25519 key. The resulting signature, along with metadata describing which headers were signed and which selector to use, is attached as a DKIM-Signature: header. The corresponding public key is published as a TXT record at a well-known location: <selector>._domainkey.<domain>.

The receiving server pulls the public key from DNS using the selector named in the DKIM-Signature header, recomputes the hash, and verifies the signature. If the body or any signed header has changed (or never matched in the first place), verification fails. If the public key cannot be retrieved, DKIM is treated as none.

DMARC is the standard that ties SPF and DKIM to the visible From header, declares what to do when neither aligns, and asks the world to send aggregated reports back to the domain owner.

SPF and DKIM each authenticate a piece of the message, but neither one inherently protects the field your users actually see — the From: header. DMARC fills that gap. It defines two new requirements: alignment (covered in the next section), and a published policy of what receivers should do when the alignment check fails. It also adds a reporting channel so the domain owner can see who is sending mail as them.

The DMARC policy lives at a well-known DNS location: _dmarc.<domain>. It is a single TXT record with a small set of tags.

SPF can pass while the message is still spoofed. DKIM can pass while the message is still spoofed. DMARC catches both because it requires alignment: SPF's domain or DKIM's signing domain has to match the visible From domain.

Recall: SPF checks the SMTP envelope sender (the domain in MAIL FROM, which becomes Return-Path:). DKIM signs whichever domain the sender chose to sign with (the d= tag in the DKIM-Signature header). Neither is required to be the same as the From: header that the user sees. A phisher can perfectly pass SPF for bulkmailer.co (the envelope they actually used) while writing From: alice@northgate.edu in the visible header.

DMARC declares this attack out of bounds. It requires that at least one of SPF or DKIM passes and aligns with the From domain. Either one is sufficient. Both failing means DMARC fails. Whether "aligns" means "exact match" or "organizational match" depends on the alignment mode in the DMARC record.

When a message arrives at a receiving server, it runs the trio in order. The diagram below shows the full decision tree.

Major mailbox providers have moved from "we encourage SPF / DKIM / DMARC" to "we require all three for any bulk sender." That requirement quietly went into effect on February 1, 2024 and has not relaxed since.

If you operate any mailing list, marketing platform, or transactional sender that delivers more than 5,000 messages per day to Gmail or Yahoo accounts, your domain must pass all three checks or your messages will be filtered, deferred, or rejected. Microsoft has signaled they will reach the same posture on similar timelines. The era of opt-in mail authentication is over.

Below are the three DNS records a hypothetical small institution would publish to authenticate its mail. Together they take less than five lines of zone file.

You now have the three pieces of the phishing puzzle. Take the concepts back to a real email and read its headers.