SPF, DKIM and DMARC Explained: Set Them Up Without Breaking Email

SPF, DKIM and DMARC are three DNS records that decide two things: whether the email you send reaches the inbox, and whether someone else can send email that looks like it comes from you. Gmail, Yahoo and Outlook.com now require all three from anyone who sends in bulk, and messages without them are more likely to end up in spam for everyone else.

The records are short, but they’re easy to get subtly wrong, and they break without warning when a new tool starts sending for you. This guide explains what each one does, how to set them up in the right order and how to keep them working.

How they fit together

Every email has two sender addresses. The envelope sender, used by mail servers to return bounces, and the From address the recipient sees. Fraud relies on the gap between them: anyone can write any From address. The three records close that gap.

• SPF (Sender Policy Framework) lists the servers allowed to send mail for your domain.
• DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message, which receivers verify against a public key in your DNS.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) ties them to the visible From address and tells receivers what to do with mail that fails.

SPF: who may send

An SPF record is a TXT record on your domain. It lists the services and servers that send mail for you and ends with what to do with everything else:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.25 ~all"

• include: adds another domain’s SPF record, the usual way to allow a mail service.
• ip4: and ip6: allow specific addresses, such as your own mail server.
• ~all (soft fail) or -all (fail) says what happens to everyone not listed. Never use +all, which allows the whole internet.

Two rules catch most domains out:

1. One record only. A domain must have exactly one SPF record. With two, receivers return a permanent error and SPF fails for every message. When a new service tells you to “add this SPF record”, add its include to the record you have instead.
2. At most 10 DNS lookups. Every include, a, mx and redirect costs a lookup, and includes inside includes count too. Past 10, SPF fails. A record with Google Workspace, a newsletter tool, a CRM and a helpdesk can cross the limit without anyone noticing.

SPF has a weakness: it checks the envelope sender, not the From address the recipient sees, and it breaks when mail is forwarded. That’s why it isn’t enough on its own.

DKIM: a signature on every message

With DKIM, your mail service signs each message with a private key. The public key lives in DNS, under a name called a selector:

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."

The receiver reads the selector from the message’s DKIM-Signature header, looks up the key and checks that the message hasn’t changed on the way. A DKIM signature survives forwarding, which makes it the more reliable of the two.

Each service that sends for you needs its own DKIM setup, usually in its admin settings under “authentication” or “verified domain”. Use 2048-bit keys where the service offers them; 1024-bit keys still work but are the minimum, and shorter ones are rejected. When a service rotates its keys, the new selector has to be in your DNS before it’s used, or signatures fail.

DMARC: tie it to the From address

DMARC is a TXT record at _dmarc on your domain:

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

It does two things SPF and DKIM can’t do alone.

First, it requires alignment. A message passes DMARC only when SPF or DKIM passes for the same domain as the visible From address. A newsletter sent through a service that signs with its own domain passes DKIM, but not for your domain, so it fails DMARC. That’s why each service needs to sign with your domain.

Second, it sets a policy for mail that fails:

• p=none: deliver it as usual. Nothing changes, but receivers can send you reports.
• p=quarantine: put it in spam.
• p=reject: refuse it.

The rua tag asks receivers to send daily aggregate reports to an address you choose. They list which servers sent mail as your domain and whether it passed, which is how you find senders you forgot about.

Set them up in the right order

Moving straight to p=reject is the classic way to stop your own invoices or password resets from arriving. Do it in steps:

1. List everything that sends as your domain. Your mailbox provider, newsletter tool, CRM, helpdesk, booking system, e-commerce platform, website contact form and any server that sends notifications.
2. Set up DKIM for each of them with your own domain, following each service’s instructions.
3. Build one SPF record with the services that need it, under 10 lookups, ending in ~all.
4. Publish DMARC with p=none and a rua address, and leave it for two to four weeks.
5. Fix every legitimate sender that fails, usually a service still signing with its own domain.
6. Move to p=quarantine, optionally with pct=25 to start with a quarter of the failing mail, then to p=reject once nothing legitimate fails.

Domains that never send email deserve protection too, since they’re easy to spoof. Give them a record that says so:

example.org.         TXT  "v=spf1 -all"
_dmarc.example.org.  TXT  "v=DMARC1; p=reject"

Mistakes that quietly break email

• A second SPF record added for a new service, instead of an include in the first.
• An SPF record that grew past 10 lookups when one more tool was added.
• A newsletter or CRM sending with its own DKIM domain, so DMARC fails despite a valid signature.
• A DKIM key rotated at the provider but never published in DNS.
• A DMARC record with a typo, such as p=rejected, which receivers ignore.
• Moving to p=reject before checking that every sender passes.
• A changed MX record or a mail server that lands on a blocklist, which hurts delivery regardless of the records.

None of these produce an error you’d see. Mail simply starts going to spam, and you hear about it weeks later when a customer says they never got the invoice.

Check your records

You can check your domain right now with our free SPF, DKIM and DMARC checker. It reads the records from DNS, counts SPF’s lookups, looks for DKIM keys at common selectors and explains what to fix, with the record to paste.

Records that are right today break when someone adds a service next month. Uptimecheck’s email authentication monitoring checks SPF, DKIM and DMARC on your domain monitors twice a day, explains each problem in plain words, gives you the DNS record that fixes it and alerts you only when a new problem appears. It also looks up the mail servers you run yourself on blocklists, so a listing doesn’t go unnoticed. Add it to the domain monitoring that already tells you before the domain itself expires.

Checklist

1. List every service that sends email as your domain.
2. Set up DKIM with your own domain in each of them, 2048-bit where possible.
3. Keep one SPF record, under 10 lookups, ending in ~all or -all.
4. Publish DMARC at p=none with a report address.
5. Fix every legitimate sender that fails alignment.
6. Move to p=quarantine, then p=reject.
7. Protect domains that don’t send with v=spf1 -all and p=reject.
8. Check the records regularly, and every time a new tool starts sending for you.