Email Authentication Checker: SPF, DKIM and DMARC for Website Owners

Three DNS records decide whether a stranger can send email that appears to come from your domain. SPF, DKIM and DMARC are not a mail-server topic — they are a domain topic. If you own the domain, you own the records, whether or not you ever send from it. This guide covers what each does, the exact syntax, what changed when DMARC became a Standards-Track RFC in May 2026, and where automated checking hits a hard wall.

Why this matters even if the domain never sends mail

A domain with no mailbox is not a domain nobody can spoof — it is a domain nobody has told the world not to spoof. Without a published policy, a receiving server cannot distinguish your invoice notification from a phishing message forged in your name. You usually find out when a customer complains.

For a domain that genuinely sends nothing, the fix takes ten minutes. RFC 7505 defines the null MX — one MX record with preference 0 and . as the exchange — announcing that the domain accepts no mail. Pair it with v=spf1 -all, which the same RFC recommends as an explicit declaration that it sends none either, then add DMARC with p=reject.

SPF: which servers may send for your domain

SPF, defined in RFC 7208, is a list of the IP addresses and hostnames authorised to send mail for your domain. It is a plain DNS TXT record:

The record starts with v=spf1, lists mechanisms, and ends with an all mechanism covering everything not matched. Four qualifiers exist: + pass, - fail, ~ softfail, ? neutral. In practice you will see ~all (accept but mark) and -all (hard fail). Start at ~all; finish at -all.

Three details trip people up regularly:

1. TXT only. RFC 7208 states that SPF records "MUST be published as a DNS TXT (type 16) Resource Record (RR) only." The dedicated SPF RR type 99 was discontinued. If your DNS panel offers an "SPF record" type, ignore it.
2. One record per domain. The RFC is explicit that a domain "MUST NOT have multiple records that would cause an authorization check to select more than one record." Two TXT records both starting v=spf1 is a permanent error, not a merge — and that is what happens when someone onboards a vendor by adding a record instead of editing one.
3. Ten DNS lookups, hard limit. Every include, a, mx, ptr, exists and redirect costs a lookup, and RFC 7208 says implementations "MUST limit the total number of those terms to 10." Exceed it and evaluation fails, so your legitimate mail stops being authenticated. Because include is recursive, three vendors can quietly consume all ten. The RFC also recommends limiting "void lookups" to two.

That limit is the most common SPF failure we see, and it is invisible in the raw record — you have to resolve the whole tree to count it.

DKIM: a signature the receiver can verify

SPF authorises servers. DKIM, defined in RFC 6376, authenticates the message. The sender signs selected headers and the body with a private key and puts the result in a DKIM-Signature header. The receiver fetches the matching public key from DNS and verifies it.

The key lives at a location built from two tags in the signature: the domain (d=) and the selector (s=). RFC 6376 spells it out — given d=example.com and s=foo.bar, "the DNS query will be for foo.bar._domainkey.example.com." The record is TXT, and p= holds the base64 public key. An empty p= means the key was revoked, which is a deliberate signal rather than a broken record.

Here is the part that matters for any checker: the selector is arbitrary, and DNS gives you no way to list it. You cannot enumerate _domainkey. You can only guess names and see which answer. Providers use predictable defaults — Google Workspace typically google, Microsoft 365 selector1 and selector2, Mailchimp k1, plus generic default, s1, s2, mail and dkim — but an organisation can use s202607 or anything else, and no list will find it.

DMARC: the policy that ties the two together

DMARC does two things SPF and DKIM cannot. It defines alignment — the domain in the visible From: header must match the domain SPF or DKIM authenticated, otherwise a spoofer passes SPF for their own domain while showing yours. And it tells receivers what to do when nothing aligns. The record lives at _dmarc.example.com:

As of May 2026 the specification is RFC 9989, which obsoletes the informational RFC 7489 and RFC 9091 and puts DMARC on the Standards Track for the first time. Reporting split into RFC 9990 (aggregate) and RFC 9991 (failure). Records still start with v=DMARC1, so nothing breaks — but three things changed. The pct percentage-rollout tag was removed, with the new t tag covering test mode instead. The Public Suffix List is out, replaced by a DNS tree walk for organisational domain discovery. And the valid tag set is now v, p, sp, np, rua, ruf, adkim, aspf, t, fo and psd — np, the policy for non-existent subdomains, being the one most people have never set and probably should.

On policy, RFC 9989 is cautious: p=none is monitoring mode, and p=reject should only be adopted once you understand the interoperability problems it creates, mailing lists in particular.

The mistakes we see most

1. No DMARC record at all. SPF and DKIM without DMARC means no alignment requirement and no reports. The majority case on small business domains.
2. p=none forever. Monitoring mode is a phase, not a destination. A domain sitting on p=none for three years is instructing receivers to do nothing.
3. SPF over ten lookups, or two SPF records. Both silent, both break the mail you care about.
4. DKIM configured at the provider but never published in DNS. The provider shows a green tick for its own side; the record was never added.
5. Subdomains left open. Policy on the organisational domain, nothing on mail.example.com or on non-existent subdomains. sp and np exist for this.

If you send in volume this is a gate, not a best practice. Since 1 February 2024, Google requires bulk senders — 5,000 or more messages a day to personal Gmail accounts — to publish SPF, DKIM and DMARC, align From: with SPF or DKIM, offer one-click unsubscribe, and keep spam complaints below 0.30%.

What hostingchecker.org checks — and the DKIM blind spot

Our email authentication probe is a DNS-only assessment. It reads the SPF TXT record and reports the all qualifier; reads the DMARC record at _dmarc and reports the policy and whether aggregate reporting (rua) is configured; then probes nine common DKIM selectors — default, google, selector1, selector2, s1, s2, k1, mail and dkim — stopping once two answer. Those inputs are weighted into a 0–100 score and a grade from A to F, cached for twelve hours.

That is useful for spotting a missing DMARC record, a wide-open ~all, or a domain with no DKIM anywhere. It is not an audit. Here is why.

Limitations and false positives

1. "No DKIM found" means "not at these nine selectors". It does not mean the domain has no DKIM. A custom or rotating selector is invisible to any external checker. Treat a DKIM miss as a prompt to look, not as a finding.
2. We do not count SPF lookups recursively. Reading the record tells you the syntax is valid. It does not tell you the include tree stays under ten lookups — the failure mode that actually breaks mail.
3. A published policy is not an enforced outcome, and alignment cannot be tested from DNS. DMARC describes what you asked receivers to do. Whether they honour it, and whether your real mail aligns, can only be answered by aggregate reports. That is what rua is for.
4. Results are cached for twelve hours, and split-horizon DNS or a stale resolver can hand us a different record than your recipients' mail servers see.
5. A grade is a heuristic. A domain with p=reject and a broken SPF tree scores well and delivers badly. The grade rewards presence and strictness, not correctness under load.

A rollout path that does not break your mail

1. Inventory every system that sends as your domain — marketing platform, CRM, billing, transactional relay, contact form, office mail server.
2. Publish or fix SPF for that inventory. Keep ~all while you work, and count the include tree against the ten-lookup limit.
3. Enable DKIM signing at each sender and publish every selector each one gives you.
4. Publish v=DMARC1; p=none; rua=mailto:... and leave it for two to four weeks. It changes nothing about delivery and starts the reports flowing.
5. Read the aggregate reports and find the senders you forgot. There will be some.
6. Move to p=quarantine, then p=reject, once reports show only legitimate mail aligning.
7. Set sp and np, then tighten SPF to -all last, after DKIM signs everywhere.

Steps 4 and 5 are the ones people skip, and skipping them is how a p=reject rollout takes down a payroll notification.

Summary

SPF says which servers may send, DKIM proves a message was not forged in transit, and DMARC requires the two to line up with the address the recipient sees. The records are cheap; the discipline is in the rollout order and in reading reports before you enforce. If your records were written against the 2015 spec, RFC 9989 is worth a re-read.

Also worth running on the same domain: a security headers check, and hosting detection if you are auditing infrastructure you did not set up.

Check your site — run your domain through hostingchecker.org to see the SPF qualifier, the DMARC policy and which common DKIM selectors resolve, then verify the rest by hand.