SPF vs DKIM vs DMARC explained: what each record does

SPF, DKIM and DMARC are three DNS records that let a receiving mail server decide whether a message that claims to come from your domain really does. They are not alternatives: each one answers a different question, and DMARC only works on top of the other two.

SPF: who may send

SPF is a list of the servers and services allowed to send mail for your domain, published as one TXT record:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Each include: adds a provider’s servers; -all says everything else fails (~all says soft fail). The rules that catch people out:

• One SPF record per domain. Two v=spf1 records make SPF fail for every message. Add a new provider to the existing record instead of publishing a second one.
• At most 10 DNS lookups. Every include, a, mx and redirect counts, including the ones inside providers’ records. Past 10, SPF returns an error. Remove providers you no longer use before adding new ones.
• It checks the bounce address. SPF on its own says nothing about the From address the reader sees, which is why DMARC exists.

DKIM: a signature on every message

With DKIM, the sending service signs each message with a private key and adds a DKIM-Signature header naming the domain (d=) and a selector (s=). The receiver fetches the public key from DNS and verifies the signature:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh…"

You rarely write this record yourself: your email provider generates the key pair and tells you what to publish, often as a CNAME pointing at their own record so they can rotate keys. Each service that sends for you needs its own DKIM set-up. The selector is chosen by the sender and cannot be listed from outside, which is why DKIM checkers, ours included, ask you for it.

DMARC: the policy that ties them together

DMARC adds the rule that matters for spoofing: a message passes only if SPF or DKIM passes for the domain in the From address (called alignment). It also tells receivers what to do with mail that fails, and where to send reports:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

• p=none: deliver as normal and send reports. A monitoring mode for the start.
• p=quarantine: treat failing mail as suspicious, usually the spam folder.
• p=reject: refuse failing mail. This is what actually stops someone sending as your domain.

Since February 2024, Google and Yahoo require bulk senders (5,000 or more messages a day to Gmail) to have SPF, DKIM and a DMARC record (at least p=none), so most domains now have one. Many have stayed at p=none ever since, which protects nobody; we wrote about that separately.

The order to set them up

1. List every service that sends as your domain: your mailboxes, newsletter tool, CRM, help desk, invoicing, website contact forms.
2. SPF: one record that includes all of them, ending in ~all while you check, -all once you are sure.
3. DKIM: turn it on in each service and publish the records it gives you.
4. DMARC at p=none with a rua address, and read the reports for a few weeks to find senders you missed.
5. Move to p=quarantine, then p=reject, once legitimate mail passes.
6. Keep checking. A new tool added by another team, a provider changing its include, or someone deleting a record during a DNS migration breaks this quietly. Nothing bounces; your mail just starts going to spam, or spoofed mail starts getting through.

Check yours

The SPF, DKIM and DMARC checker reads all three records for a domain and explains each problem it finds. The SPF checker, DKIM checker and DMARC checker look at one record each. To be told when a record changes or the DMARC policy drops below the level you chose, add SPF, DKIM and DMARC monitoring; it is on the free plan.