SPF, DKIM and DMARC Explained

Email's original protocol (SMTP) has no built-in way to verify that a message actually came from who it claims to be from — the "From" address is just a text field a sender can set to anything. This is why email spoofing and phishing have historically been so easy. SPF, DKIM and DMARC are three DNS-based standards that, used together, let receiving mail servers verify a message's authenticity and decide what to do with messages that fail.

SPF is a DNS TXT record published on your domain that lists which mail servers are authorized to send email on its behalf. A receiving server checks the sending server's IP against this list.

• v=spf1 — declares this a valid SPF record (there must be exactly one per domain)
• ip4: / ip6: — authorizes a specific IP address
• include: — authorizes another domain's SPF-listed senders (common for services like Google Workspace or Microsoft 365)
• -all — hard fail: reject anything not explicitly listed. ~all is a soft fail (mark as suspicious but don't outright reject); +all effectively disables SPF and should never be used.

SPF has a hard limit of 10 DNS lookups per check (each include, a, mx and similar mechanism counts). Exceeding it causes the SPF check to fail entirely — a surprisingly common misconfiguration when several third-party services are chained together with include statements.

DKIM works differently: instead of checking the sending IP, it adds a cryptographic signature to each outgoing message's headers. The corresponding public key is published in DNS at a location identified by a selector — a short string chosen by the sending service, forming a record at selector._domainkey.yourdomain.com.

The receiving server fetches this public key from DNS and verifies the signature against the message content. If the signature validates, it proves two things: the message really was signed by a server holding the matching private key, and the signed parts of the message weren't altered in transit.

DMARC ties SPF and DKIM together and tells receiving servers what to do when a message fails both. It's published as a TXT record at _dmarc.yourdomain.com:

• p= — the policy: none (monitor only, take no action), quarantine (send to spam), or reject (refuse the message outright)
• rua= — an address to receive aggregate daily/weekly reports showing which servers are sending mail as your domain and whether they pass authentication
• DMARC also requires alignment — the domain in SPF or DKIM must match the visible "From" domain, not just pass in isolation

The standard rollout path is p=none first (collect reports, confirm all legitimate senders pass), then move to p=quarantine, then p=reject once confident nothing legitimate will be blocked.

When a message arrives, the receiving server: (1) checks SPF by comparing the sending IP against the domain's SPF record, (2) checks DKIM by verifying the cryptographic signature against the published public key, (3) checks DMARC alignment — do the SPF and/or DKIM domains match the visible From address — then (4) applies the DMARC policy based on the combined result. A message can pass SPF but fail DMARC alignment if the SPF-passing domain doesn't match the From address, which is a common source of confusion when troubleshooting.

• Publishing two SPF TXT records instead of merging into one — this makes SPF invalid, not just redundant.
• Exceeding the 10 DNS lookup limit by chaining too many include: mechanisms.
• No DMARC record at all — SPF and DKIM alone don't tell receiving servers what to do on failure, leaving spoofed mail handling entirely up to the receiver's own judgment.
• Jumping straight to p=reject without first monitoring via p=none and reviewing reports — this can silently block legitimate mail from a forgotten sending service.

Check your own records for syntax problems with the SPF / DKIM / DMARC Checker before rolling out changes.