DMARC, SPF and DKIM checker

What the three records do, in the order a receiver reads them

SPF is a list, published in DNS, of the servers allowed to send mail using your domain in the envelope sender. A receiving server takes the address the sending machine claimed, looks up your SPF record, and checks whether the machine it is talking to is on the list. It proves something about the route, not about the message, and it breaks whenever mail is forwarded, because the forwarder is not on your list.

DKIM is a cryptographic signature over the message itself. Your sending platform signs outgoing mail with a private key and publishes the matching public key in DNS under a selector, and a receiver fetches that key and verifies that the headers and body it received are the ones that were signed. It survives forwarding, which is exactly where SPF fails, and the two are complementary rather than alternatives.

DMARC is the policy that makes the other two mean something. It says what a receiver should do with mail that claims to be from your domain and passes neither check in a way that lines up with the domain in the visible From address — that alignment requirement is the part that matters, because SPF and DKIM on their own can both pass for a message whose visible sender is forged. DMARC also asks for aggregate reports, which is the only feedback most senders ever get about who is sending as them.

Since early 2024 the two largest consumer mailbox providers have required anyone sending bulk mail to their users to publish all three: SPF, DKIM, and a DMARC record on the sending domain. The bar is a record existing, not a strict policy, which is why so many domains publish p=none and stop there.

What this tool checks in an SPF record

First, whether there is exactly one. A domain publishing two records starting v=spf1 is a permanent error by the specification, and the correct behaviour for a receiver is to fail the check outright rather than to pick one. This is the single most common way a domain breaks SPF for itself: a second sending platform is added, its record is pasted in alongside the existing one, and everything quietly starts failing. Two providers means one record with both of their include mechanisms in it.

Second, the lookup count. Every include, a, mx, ptr, exists and redirect mechanism in your record costs a DNS lookup, and the specification caps the total at ten, counting recursively through everything your includes pull in. Past ten a receiver returns a permanent error, which is treated as a failure, and the record that was working last month stops working because a provider added an include inside their own. This tool counts the mechanisms in the record it can see and warns as the number approaches the limit; it does not resolve your includes, so the true recursive total can be higher than the figure shown here.

Third, the final qualifier. A record ending -all asserts that anything not on the list is forged; ~all says it is probably forged but asks the receiver not to reject on that alone. Both are usable, and with DMARC in place the difference matters less than it used to, because the DMARC policy is what decides the outcome. What is worth flagging is +all, which authorises the entire internet to send as you and is almost always a mistake, and a record with no all mechanism at all, which is a record that declines to say anything about the servers it did not list. The ptr mechanism is also flagged: it has been deprecated for years, it is slow, and receivers are entitled to ignore it.

What this tool checks in a DMARC record

The record lives at _dmarc under your domain and must begin with the tag v=DMARC1 — a record with that tag somewhere in the middle is invalid and is ignored entirely. The tool reads the policy tag p, which is the whole point of the record: none means "tell me what is happening and deliver it anyway", quarantine means "treat failures as suspicious", and reject means "do not accept mail that fails". A domain that sends no mail at all should publish p=reject, which is the cheapest anti-impersonation measure available to anybody who owns a domain.

p=none is the right place to start and the wrong place to stay. Its purpose is to collect aggregate reports for a few weeks so you can find the legitimate senders you had forgotten about, fix their authentication, and then tighten the policy. A domain that has been on p=none for three years is a domain whose DMARC record protects nobody: it satisfies the bulk-sender requirement to have a record and it has never once caused a forged message to be refused.

Which is why the rua tag is checked. Without an address for aggregate reports there is no feedback loop, nothing tells you who is sending as you, and there is no evidence on which to ever move off p=none. The tool also reports pct when it is present and below 100 — a policy applied to a fraction of mail, which is a legitimate way to roll out a change and a strange thing to leave in place indefinitely — and the subdomain policy sp when it is set, since a strict policy on the parent with nothing on the subdomains leaves the obvious gap open.

What a DKIM lookup can and cannot tell you

DKIM keys are not discoverable. The public key sits at selector._domainkey under your domain, and the selector is an arbitrary string chosen by whoever set the key up, so there is no way to enumerate the keys on a domain and no way for this tool to find yours without being told. Your sending platform names the selector in its setup instructions, and a signed message you have received carries it in the s= tag of its DKIM-Signature header — which is the quickest way to find out what is actually being used in practice.

Given a selector, the checks are modest and worth having. Is there a record at all, does it start with v=DKIM1, and does it carry a p= tag with a key in it? A record whose p= tag is present but empty is a revoked key, which is a deliberate act and a genuine problem if it happens to be the selector your live mail is being signed with. Records longer than a single DNS string arrive in chunks and are joined back together here before being read, which is the mistake that makes a perfectly valid 2048-bit key look malformed.

What this cannot do is verify a signature. That requires a message: the headers, the body, the canonicalisation, the hash. A published key tells you the key is there and syntactically sound, and nothing whatsoever about whether your platform is signing correctly with it. The only test for that is to send a message to an address you control and read the Authentication-Results header on what arrives.

Nothing you type here is kept. The domain and the selector are used to build the DNS queries and then discarded: they are written to no log, no table and no analytics event, and the endpoint is rate-limited by network address so it cannot be used to enumerate anything at volume. The records themselves are public — anybody can look them up — which is precisely why there is no reason to keep a record of who looked.