SPF, DKIM and DMARC: how to read the results, and what to fix first

The short version

None of the three is about your copy. All three are about whether a server has a reason to trust the envelope the copy travels in — which is why they are checked before anything else when replies stop arriving.

SPF: who may send

SPF is a single TXT record at the root of your domain. Receivers check the sending server's IP against it: a match returns a pass, a mismatch returns the qualifier on the all mechanism. The qualifiers are not decoration — they are the whole point:

Two rules cause most SPF failures in the wild. First, only one SPF record may exist: if two TXT records start with v=spf1, receivers may ignore both. It happens when two services each add "their" record — a registrar here, a marketing tool there. Second, SPF has a limit of 10 DNS lookups per evaluation; mechanisms like include, a, mx, exists and redirect each cost one, and a record that exceeds the limit fails with permerror regardless of how correct it looks. The deprecated ptr mechanism is best replaced with an include.

What good looks like: one record, the senders you actually use, a lookup count with headroom, and an all that matches your stage — ~all while you finish, -all when you are done.

DKIM: the signature

DKIM is what survives forwarding. The sending server signs each message with a private key; the matching public key is published in DNS at a selector — an arbitrary label chosen by whoever signs. That freedom is the source of most DKIM confusion: there is no standard selector to look up, so "no record found" usually means "the right selector was not tried", not "DKIM is missing".

Common selectors by provider, worth trying in the checker:

Three failure modes are worth knowing. A record with an empty key (v=DKIM1; p=) is not a working DKIM record — it is a placeholder, sometimes published as a wildcard to stop people from testing against a domain they do not own. example.com does exactly this: every common selector resolves to v=DKIM1; p=, and a checker that only looks for "a DKIM record" will wrongly call it a pass. A CNAME-based setup (common with hosted providers) points the selector at the provider's key; following the CNAME is what makes the check real. And a rotated key — providers rotate selectors on their own schedule — means the selector that worked last year may be retired; if signatures suddenly fail, check the current selector before anything else.

What good looks like: a key with an actual p= value, at the selector your provider signs with, verified by following the chain (TXT or CNAME) to a non-empty key.

DMARC: what to do with failures

DMARC is the instruction layer: it tells receivers what to do when a message claiming to be from your domain fails SPF or DKIM, and it requires those results to be aligned — the domain that passed must match the visible From domain, not just some domain in the path. It also gives you reporting: rua addresses receive aggregate reports of who is sending as you, every day.

The mistake to avoid is jumping to p=reject because a tutorial says so. Enforcing before every legitimate sender — invoices, password resets, your CRM, the tool a team member connected two years ago — passes alignment means those messages start failing. The ladder exists for a reason: none → quarantine → reject, each step taken after the reports justify it.

The order to fix them in

The three records depend on each other in one direction: DMARC interprets SPF and DKIM, so fixing them out of order means enforcing a policy over results you have not corrected yet. The sequence that works:

1. SPF first. It is the fastest to fix — merge duplicates, remove +all, count lookups, choose the right all — and it is the record most often broken by accident.
2. DKIM second. The work is identifying the selector your provider actually signs with and publishing a real key. Nothing to enforce yet; just make signing possible.
3. DMARC third. Start at p=none with rua. Read the reports for a couple of weeks. Move to quarantine, then reject, only when the reports show every legitimate sender aligned.
4. Then re-check. Run the checker after each change — remember DNS changes take minutes to hours to appear depending on TTL — and again after any new tool starts sending as your domain.

One more habit: whenever a new service starts sending as you (a support desk, a billing tool, a campaign platform), add its sender to SPF and its selector to DKIM before tightening DMARC further. Most "DMARC broke my email" incidents are this, in reverse.

Reading the checker's statuses

The checker reports each record as PASS, REVIEW or FIX, with the findings spelled out. The distinctions matter more than the colors:

• SPF PASS — one record, a sane lookup count, an all that matches reality. REVIEW — technically valid but soft: ~all while you could harden, or a deprecated mechanism. FIX — missing, duplicated, +all, or over the lookup limit.
• DKIM PASS — a non-empty key found (directly or through a CNAME). REVIEW — no key at the common selectors: usually just the selector question. FIX — empty keys found, i.e. placeholders rather than signing keys.
• DMARC PASS — an enforcing policy with reporting. REVIEW — p=none, or missing rua: monitoring states that are correct at the start and incomplete at the end. FIX — missing or duplicated record.

A normal early state for a new domain reads SPF PASS · DKIM REVIEW · DMARC REVIEW: the foundation is there, the provider selector needs confirming, and DMARC is in its monitoring phase. That is not a failure — it is a to-do list in the right order.

FAQ

This guide is part of the TOM blog. Run the free SPF, DKIM and DMARC checker. Related reading: the 12 cold email frameworks, verification colors explained and 12 cold email software alternatives compared.