How to Set Up SPF, DKIM and DMARC Step by Step

SPF, DKIM and DMARC are the three DNS records that authenticate your email. Get them right and your mail lands in inboxes; get them wrong (or skip them) and you'll fight the spam folder forever. Gmail and Yahoo now *require* them for bulk senders. This guide sets up all three in the correct order with real values.

The 30-second overview

• SPF lists which servers may send mail for your domain.
• DKIM cryptographically signs each message so it can't be tampered with and proves it came from you.
• DMARC tells receivers what to do when SPF/DKIM fail, and sends you reports.

They work together — DMARC leans on SPF and DKIM — so add them in that order. Deeper background: email DNS explained: SPF, DKIM and DMARC.

Step 1: SPF

SPF is a single TXT record on your root domain listing authorised senders. If you use Google Workspace:

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

For a self-hosted server, authorise its IP:

example.com.  TXT  "v=spf1 ip4:203.0.113.10 ~all"

Combine sources with multiple include: / ip4: terms. Rules that matter:

• One SPF record per domain. Two SPF records = a failure. Merge them.
• ~all = soft fail (mark suspicious); -all = hard fail (reject). Start with ~all.
• Keep DNS lookups under 10 — too many include: terms breaks SPF.

Step 2: DKIM

DKIM publishes a public key in DNS; your mail server signs outgoing mail with the matching private key. The record lives at a selector subdomain:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq...QAB"

Where the key comes from depends on your provider — Google Workspace generates it in the Admin console; a self-hosted server generates its own. Full walkthroughs: how to set up DKIM on a self-hosted mail server and how to verify your domain for email sending.

Step 3: DMARC

Only after SPF and DKIM pass should you add DMARC. It's a TXT record at _dmarc:

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

The policy p escalates as you gain confidence:

• p=none — monitor only, collect reports, break nothing. Start here.
• p=quarantine — send failures to spam.
• p=reject — reject failures outright. The end goal.

The rua= address receives daily aggregate reports (XML) showing who's sending as you — invaluable for spotting spoofing before you tighten the policy.

Step 4: Verify everything

dig example.com TXT +short                 # SPF
dig selector1._domainkey.example.com TXT +short   # DKIM
dig _dmarc.example.com TXT +short          # DMARC

Send a test message to a Gmail account, open Show original, and confirm SPF, DKIM and DMARC all show PASS. Tools like mail-tester.com give a score and flag issues. If any fail, work back through the records — see diagnosing DNS problems with dig and nslookup.

The rollout plan

1. Publish SPF and DKIM.
2. Publish DMARC at p=none and watch reports for a week or two.
3. Once legitimate mail passes cleanly, move to p=quarantine, then p=reject.

Rushing to p=reject before your legitimate senders pass will bounce your own mail. If you're still landing in spam after this, read how to stop your emails going to spam.

Reading a DMARC report

Once DMARC is live at p=none, you'll get daily XML aggregate reports at the rua address. They're dense, so paste them into a free DMARC report viewer. What you're looking for:

• Sources you recognise (your mail provider, marketing tool) passing SPF and DKIM — good.
• Sources you recognise failing — a misconfiguration to fix before you tighten policy.
• **Sources you *don't* recognise sending as you** — either shadow IT (a tool someone signed up for) or outright spoofing.

Only once every legitimate source passes should you escalate from p=none to p=quarantine and then p=reject. Rushing straight to reject is how people bounce their own newsletters.

Common SPF mistakes

SPF is deceptively fiddly. The ones that bite most often:

• Two SPF records. Only one v=spf1 TXT record is allowed per domain. Merge every sender into one line.
• Too many DNS lookups. SPF permits a maximum of 10 DNS lookups; each include: counts. Chains of includes blow past it and SPF returns permerror. Flatten or drop unused includes.
• Ending wrong. ~all (softfail) is right while testing; -all (hardfail) once you're confident. +all authorises the whole internet — never use it.
• Forgetting a sender. Every service that sends *as* your domain (CRM, invoicing, support desk) needs its include:, or its mail fails SPF.

Protect your subdomains too

Spoofers love unused subdomains because a policy on the apex doesn't automatically cover them the way you'd expect for the visible From. Add a subdomain policy to your DMARC record:

_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

Here sp=reject sets the policy for subdomains, and adkim=s/aspf=s require strict alignment. For a subdomain you never send mail from, you can also publish a null MX (example.com. MX 0 ".") to signal it accepts no mail. This closes a spoofing gap most people miss — and it's the finishing touch on the deliverability work in how to stop your emails going to spam.

FAQ

Do I need all three records?

Effectively yes. SPF and DKIM prove legitimacy; DMARC ties them together and is now required by Gmail/Yahoo for bulk senders. Skipping any weakens deliverability.

What order should I set them up in?

SPF and DKIM first, then DMARC at p=none. DMARC depends on the other two passing, so publishing it first just generates failures.

Why is my SPF failing with a "too many lookups" error?

SPF allows a maximum of 10 DNS lookups. Too many include: terms exceeds it. Flatten or reduce includes to stay under the limit.

Can I have two SPF records?

No — only one SPF TXT record per domain. Merge all sources into a single record or SPF fails.

How do I move from p=none to p=reject safely?

Escalate in stages, driven by your DMARC reports rather than a calendar. Start at p=none and watch the aggregate reports for a week or two until every legitimate sending source — your mail provider, marketing tool, invoicing system — shows SPF and/or DKIM passing with proper alignment. When the only failures left are clearly spoofers, move to p=quarantine, optionally with a percentage (pct=25) to ramp gradually, and keep watching. Once quarantine causes no collateral damage to real mail, finish at p=reject. The whole point of the staged approach is to catch a forgotten sender — a CRM or support desk nobody remembered — before a strict policy bounces its mail. Rushing straight to reject is the classic way to block your own newsletters and password resets.

Authenticated email is far easier on managed infrastructure. Let Nxeon handle the hard parts with business email, or run your own stack on a fast VPS.