How to set up SPF, DKIM and DMARC

This is a hands-on setup guide: how to publish SPF, DKIM and DMARC for a domain you send mail from, keep your sending IPs off RBL blocklists, and verify that everything actually works. If you first want the plain-language theory of what each mechanism is, read any general “how email authentication works” primer — here we focus on the records you create, the order you roll them out in, and the mistakes that break real mail.

Step 1 — Publish one SPF record

SPF is a single TXT record on the root of your domain listing the servers allowed to send for it. The rule that trips everyone up: a domain may have only one SPF record. If you use several senders, you merge them into one line with multiple include: mechanisms — you do not publish two SPF records.

A typical record for a domain that sends through Google Workspace plus one marketing tool:

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

The 10-lookup limit. SPF allows at most 10 DNS lookups while it is being evaluated; each include: and a/mx mechanism can cost one or more. Exceed it and SPF returns permerror — treated as a failure. If you stack many providers, drop unused includes or use an SPF-flattening service rather than piling on more.

Start soft, then harden. Publish with ~all for a week or two, confirm no legitimate sender fails, then change the final mechanism to -all.

Step 2 — Turn on DKIM at each sender

DKIM adds a cryptographic signature to every message. You rarely build the key by hand — each sending platform generates it and gives you a TXT (or CNAME) record to publish under a selector. Do this per sender: Google, Microsoft, your ESP and your own server each get their own selector and key.

1. In the sender’s admin panel, enable DKIM / “email authentication”. It shows you a selector (e.g. google, s1) and a public key.
2. Publish it in DNS at <selector>._domainkey.example.com. Providers that use a CNAME let them rotate the key for you — prefer that when offered.
3. Back in the panel, click Start authenticating so the sender begins adding the DKIM-Signature: header. Prefer a 2048-bit key where you can choose.

Because the signature travels inside the message, DKIM survives forwarding (unlike SPF) — which is exactly why the next step leans on it.

Step 3 — Roll out DMARC gradually

DMARC ties SPF and DKIM to the visible From: address and tells receivers what to do on failure. Never start at p=reject — you will bounce your own legitimate mail from a sender you forgot. Roll it out in three stages, watching the reports between each.

The rua= address receives daily XML aggregate reports from receivers. Read them (a free DMARC report viewer is enough at first): each one lists the sending IPs using your domain and whether they passed SPF and DKIM with alignment. Alignment is the catch — a message must not merely pass SPF or DKIM, the passing domain has to match the From: domain. If a legitimate service passes DKIM for its own domain but not yours, fix it by publishing that service’s DKIM under your domain (Step 2) before you move to enforcement.

Step 4 — Keep your sending IPs off RBLs

SPF/DKIM/DMARC prove identity; RBL blocklists (DNSBLs) judge reputation of the sending IP. A perfectly authenticated message still lands in spam if its IP is listed. You do not publish anything for RBLs — you keep clean of them:

• Send only wanted mail. Spam complaints and hitting spam-traps are the fastest way onto a list.
• Warm up new IPs gradually rather than blasting volume on day one.
• Secure every account and script that can send — a single compromised form or password gets the whole IP listed.
• Set valid reverse DNS (PTR) for your sending IP that matches its HELO name.

If you do get listed, most reputable lists (Spamhaus and others) show why and offer self-service delisting once the cause is fixed. Fix first, then request removal — delisting while the problem persists just gets you relisted.

Step 5 — Verify it actually works

Publishing records is not proof. Confirm each layer:

• Check the records exist. Query DNS directly: dig TXT example.com, dig TXT google._domainkey.example.com, dig TXT _dmarc.example.com (or nslookup -type=TXT on Windows).
• Confirm the mail servers you authorized. Use our MX Lookup to see the MX hosts a domain actually publishes — handy for spotting a stale or wrong mail host.
• Read the results on a real message. Send yourself a test message, open its raw source, and paste it into the MIME decoder. Look at the Authentication-Results: header — it states spf=pass, dkim=pass and dmarc=pass (or the exact failure) as the receiver saw it. That is the ground truth.
• Watch the DMARC reports for a couple of weeks before moving from p=none to enforcement.

Common setup mistakes

Once all three records are live, aligned and verified — and your IPs stay off the blocklists — you have closed the door on people spoofing your domain and given your real mail the best possible shot at the inbox. To sanity-check individual addresses on any domain, the email checker on the home page runs the live mailbox checks for you.