SPF, DKIM and DMARC — checked from outside, and read without touching your site

Everything on this page is answered by asking your domain's authoritative nameservers for records. No request is sent to your website at all. There is nothing to rate-limit, nothing to log, nothing a WAF can see and nothing that can be affected by anything happening on your origin.

That makes the DNS and email layer the natural first thing to check for somebody who is nervous about scanning a live site, and it is also the layer with the highest ratio of real findings to noise: a large share of domains have at least one of the three email-authentication records missing, misconfigured, or present and enforcing nothing.

Email authentication asks one question: did this message really come from the domain it claims? Three mechanisms answer parts of it, and they are complements rather than alternatives.

SPF — which servers may send as you

A DNS record listing the hosts permitted to send mail for your domain. It is evaluated against the envelope sender, not the visible From address, which is the detail most SPF guides get wrong. It authorises senders; it does not prove the message is unmodified.

DKIM — that the message was not changed in transit

A private key signs the outgoing headers and body; the public key is published in DNS under a selector. A receiving server that can verify the signature knows the message left the holder of that key and was not altered after it did. It survives forwarding, which SPF does not.

DMARC — what to do when they disagree

A record telling receivers what to do with a message that fails SPF and DKIM. This is the record that turns the other two into an enforcement decision, and by a wide margin the most common state of all: left at p=none by somebody who read the setup guide, added the rua address as instructed, and never came back to it.

The part people get wrong, and the reason a working SPF plus a working DKIM still fails: both checks must align. Alignment is the requirement that the domain in the check matches the domain in the visible From. A message whose SPF passes for spf.protection.example.net and whose From is [email protected] fails alignment and gets no SPF credit. DMARC requires at least one of the two to align and pass.

SPF DNS-002 DNS-018 EML-002 — whether a record exists, what it authorises, and how it ends. A policy finishing in all with no preceding qualifier authorises every server on the internet. A lookup count approaching the ten-query limit is reported as a risk rather than a failure, because a record that is close to the limit now can break when a vendor is added.

DKIM DNS-005 EML-009 EML-010 — whether key material is published, at which selector, and at what key size. A revoked key is detectable: an p= tag with no value is the standard way to publish a revocation, and it is a positive thing to find.

DMARC DNS-004 DNS-020 EML-004 — whether the record exists, whether it aligns strictly or loosely, where reports go, and — the finding that matters — whether the policy is none, quarantine or reject. A policy of none collects reports and enforces nothing.

Mail routing DNS-006 DNSX-003 DNS-024 — whether MX records exist, and whether the hostnames they point at actually resolve. An MX pointing at a name that no longer resolves is mail that fails silently rather than loudly.

Transport for mail DNS-010 EML-008 EML-012 — MTA-STS and TLS-RPT. These are the DNS-published companion to DMARC that tells receivers to insist on TLS when delivering your mail to them.

Delegation hygiene DNX-012 DNX-013 — a domain delegated to a single nameserver, or an SOA primary that is not in the NS set. Neither is an attack, and both are single points of failure.

Dangling and wildcard records DNS-013 DNX-014 DNX-015 SUB-004 — a CNAME or subdomain pointing at a hosting provider that no longer claims it. This is the DNS record equivalent of a subdomain takeover, and it is the finding in this layer most worth acting on promptly: the name resolves, and somebody else may be able to claim it.

CAA DNS-007 DNX-005 — which certificate authorities may issue for your domain. Absent, it permits any of them.

DNSSEC DNS-008 DNSX-002 — whether the zone is signed with a validated chain of trust, which is what stops a resolver accepting a forged answer.

Zone transfer DNSX-001 — whether an authoritative nameserver answers AXFR to somebody who asked. A zone transfer hands over every record in the zone.

Internal name disclosure DNSX-009 DNSX-007 — an internal hostname or address in a public record, or a TXT record naming a third-party service you use. Neither is a vulnerability; both map your infrastructure for whoever is reading.