How Email Authentication Works: SPF, DKIM and DMARC

Email was designed without any check that a message really comes from the address it claims. Anyone can write From: [email protected]. Three DNS-based standards close that gap: SPF, DKIM and DMARC. They work together, and each answers a different question. Without them, your own mail is more likely to land in spam, and criminals can impersonate your domain.

SPF: which servers may send for this domain?

The owner of a domain publishes a list of allowed sending servers as a TXT record:

example.com.  IN TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.example.net -all"

When a message arrives, the receiving server looks up the SPF record of the domain in the envelope sender (the hidden MAIL FROM address, not the visible From line) and checks whether the connecting server's IP is on the list. The ending says what to do with everything else:

SPF has two famous limits: a record may trigger at most 10 DNS lookups (each include: and a/mx counts), and a domain must publish only one SPF record. SPF also breaks when mail is forwarded, because the forwarder's IP is not on your list.

Build a record with the SPF Record Generator.

DKIM: was the message altered, and does the domain vouch for it?

The sending server signs selected headers and the body with a private key and adds a header like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com;
 [email protected]; q=dns/txt; s=selector1; t=1791022872; h=from : to :
 subject : date; bh=Ba3gj8+xBPQLJTahTfzW6RbWQ/XPgESxkCi2B66PSQg=;
 b=<signature>

d= is the signing domain, s= the selector that says which public key to use, h= the signed headers, bh= a hash of the body and b= the signature. The matching public key sits in DNS at selector._domainkey.domain:

selector1._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

The receiver fetches the key and verifies the signature. Change a single character of the signed body and verification fails, which is how tampering is detected. DKIM survives forwarding, because the signature travels with the message. Create a key pair and record with the DKIM Record Generator.

DMARC: what should happen when checks fail?

SPF and DKIM prove a domain, but not necessarily the one the reader sees in the From line. DMARC ties it together with alignment: for mail to pass, SPF or DKIM must pass and the domain they authenticated must match the visible From domain. The record lives at _dmarc.domain:

_dmarc.example.com.  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

rua= names where daily aggregate reports are sent, showing who is sending mail as your domain and whether it passes. Make a record with the DMARC Record Generator.

A safe rollout

1. Inventory everything that sends mail for the domain: your mail provider, newsletter service, CRM, invoicing system, website forms.
2. Publish SPF listing them, and enable DKIM signing at each service.
3. Publish DMARC with p=none and a rua address, and read the reports for a few weeks.
4. Fix any legitimate sender that fails alignment.
5. Move to p=quarantine, then p=reject, ideally raising pct gradually.

Reading the result of a real message

In a received message, the Authentication-Results header shows the verdicts, for example spf=pass dkim=pass dmarc=pass. Paste the full headers into the Email Header & Security Analyzer to read them, or test your whole setup with the Email Deliverability Checker.

See also SPF, DKIM, DMARC and Phishing.