How to Read SPF, DKIM, and DMARC Results Without Being an Email Admin

Step-by-step

1. 1

   Get the mental model: three questions, three records

   Each record answers one question a receiving mail server asks. SPF: 'is the server that delivered this message allowed to send mail for this domain?' — it's a DNS list of permitted senders. DKIM: 'was this message signed by the domain and unmodified in transit?' — the sender attaches a cryptographic signature, and the public key to check it lives in DNS. DMARC: 'do SPF or DKIM results actually match the domain the human sees in the From line, and what should I do if not?' — it ties the other two to the visible From address and adds a policy plus reporting. A message can pass SPF and DKIM for some domain and still fail DMARC, because DMARC insists the passing domain aligns with the From domain.

2. 2

   Read a real SPF record token by token

   SPF lives in a TXT record and reads left to right. Take: v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all. The v=spf1 tag identifies it as SPF. ip4: authorizes an IP address or range directly. include: pulls in another domain's SPF record — this is how you authorize Google Workspace, Mailchimp, or your CRM to send for you. The final 'all' term is the default verdict for any server not matched earlier: ~all (softfail) says 'unauthorized senders are suspicious but don't hard-reject', while -all (fail) says 'reject them outright'. Softfail is the cautious rollout choice; -all is the end state once you're sure the list is complete.

3. 3

   Watch the 10-DNS-lookup limit

   The SPF standard caps evaluation at 10 DNS lookups per check; include:, a, mx, and a few other mechanisms each consume one, and nested includes count too. Go over the limit and receivers return a permanent error ('permerror') — which in practice can mean your legitimate mail loses its SPF pass even though every service in the record is genuinely yours. This bites growing companies constantly: each new SaaS tool says 'add our include to your SPF', and the seventh tool silently pushes you over. If a checker reports a lookup count near or above 10, consolidate: remove services you no longer use, and prefer providers' flattened or combined includes where available.

4. 4

   Understand DKIM selectors

   A domain can have many DKIM keys at once, and selectors are how they coexist. The signature header on a message names a selector (s=google, s=k1, s=mail…), and the receiver fetches the public key from DNS at selector._domainkey.yourdomain.com. Each sending service typically uses its own selector, which is why setting up a mailing provider means adding one or two CNAME or TXT records with odd names. When checking DKIM from the outside, you need to know which selector to query — there is no standard way to list all selectors for a domain. Find it in a real message: view the raw headers, locate DKIM-Signature, and read the s= tag.

5. 5

   Decode the DMARC policy line

   DMARC lives in a TXT record at _dmarc.yourdomain.com and looks like: v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com. The p= tag is the request to receivers for mail that fails DMARC: p=none means 'deliver normally but send me reports' — monitoring mode; p=quarantine means 'treat it as suspicious', which usually lands it in spam; p=reject means 'refuse it'. The rua= tag is where aggregate reports go: receivers periodically send XML summaries of who sent mail claiming to be your domain and how it authenticated. A domain sitting at p=none for years isn't 'protected by DMARC' in any enforcement sense — it's only observing. Moving to quarantine or reject is what actually blocks spoofing, and should be done after the reports show legitimate sources all pass.

6. 6

   Recognize the classic failure patterns

   Forwarding breaks SPF: when a message is forwarded, the forwarding server delivers it, and that server isn't in the original domain's SPF list — so SPF fails even though the mail is legitimate. This is precisely why DMARC accepts either SPF or DKIM: a DKIM signature travels inside the message and usually survives forwarding intact, unless the forwarder modifies the content (mailing lists that add footers are notorious for this). The second classic is missing alignment: your bulk-mail provider sends with its own domain in the technical envelope, SPF passes for the provider's domain, but DMARC fails because that domain doesn't match your From domain. The fix is configuring a custom return path and DKIM signing on your own domain in the provider's settings.

7. 7

   Check your domain with the Email Auth Checker

   Open the Email Auth Checker and enter your domain. Read the results in this order: does an SPF record exist, is there exactly one (multiple SPF records are invalid), how does it end (~all or -all), and how many DNS lookups does it use? Does DMARC exist, what is p=, and is a rua= address collecting reports? For DKIM, check the selectors your senders use. You're not aiming for a trophy screenshot — you're building a list of concrete gaps: 'no DMARC record', 'SPF ends in ?all', 'lookup count is 11'. Each of those is a specific, fixable item.