SPF & DMARC Checker

Type the domain and press Check. The tool reads the SPF record and expands every include and redirect, reads the DMARC record at _dmarc.yourdomain, probes a set of well-known DKIM selectors, and resolves the MX hosts. Each record gets its own verdict, and MTA-STS, TLS-RPT and BIMI are checked in the same pass.

RFC 7208 allows at most ten terms that cause a DNS query during evaluation: include, a, mx, ptr, exists and the redirect modifier. Includes count recursively, so a handful of providers can quietly push the total past ten. Evaluation stops at the first mechanism that matches, so that total is a worst case rather than a verdict on every message: a sender whose path reaches beyond the tenth lookup gets a permanent error — counted as an SPF failure under DMARC — while one that matches earlier still passes. That is why an over-budget record looks perfectly normal and fails only for some senders.

Start by removing includes for providers you no longer send through — that is usually enough. Where a provider publishes stable address ranges, replace the include with ip4 and ip6 mechanisms, which cost nothing against the budget. Moving some mail to a subdomain with its own SPF record splits the budget in two. Flattening an include into literal addresses works but has to be maintained, since the provider can change its ranges without warning.

-all is a hard fail: a server not on the list is not authorised, and receivers may reject the message. ~all is a soft fail: unauthorised, but deliver it and mark it. ~all is the sensible setting while you are still finding stray senders; -all is where you want to end up. ?all is neutral and asserts nothing, so a record ending there does about as much as no record at all.

Because DNS has no way to list the selectors a domain publishes. A DKIM key lives at selector._domainkey.yourdomain, and without knowing the selector name there is nothing to query. This tool probes the selectors the major providers use, but anything custom — including the random selectors Amazon SES issues — has to be supplied. Take it from the s= tag in the DKIM-Signature header of any message from the domain and add it to the selectors field.

p=none means monitor only: receivers apply no action and simply send reports. It is the right place to start, but it protects nothing, so it is a staging post rather than a destination. p=quarantine tells receivers to treat failing mail as suspicious, usually landing it in spam. p=reject refuses it outright. The usual path is none until the reports look clean, then quarantine, then reject.

The most common cause is a missing authorisation record. If your rua address is on a different domain from the one being reported on — a monitoring vendor, for instance — that domain has to publish a record at yourdomain._report._dmarc.theirdomain confirming it accepts them. Without it, conforming reporters drop the reports without telling anyone, which looks exactly like no reports being sent. This tool checks that record for every external address.

No. A web page cannot open an SMTP connection — port 25 is out of reach from a browser — so the MX section checks configuration only. It confirms the records exist, reads their preferences, resolves each target, and flags the usual faults: a target with no address record, a CNAME where a hostname is required, or a bare IP address. Whether a server answers on the other end needs a tool that can talk SMTP.

SPF passing is not the same as DMARC passing. DMARC also requires alignment: the domain that passed SPF has to match the From address a recipient sees. Mail sent through a provider often passes SPF for the provider’s own domain while the From header shows yours, which fails alignment. DKIM signing with your domain fixes it, since DKIM alignment is checked independently. Reputation, content and list hygiene sit outside authentication entirely.

MTA-STS tells sending servers to require TLS when delivering to you, closing the downgrade attack that plain opportunistic TLS leaves open. TLS-RPT asks them to report when that fails. BIMI publishes a logo for receivers that display one, and requires DMARC at enforcement first. All three are optional, and not publishing them is entirely normal.

Yes, and it is worth doing for any subdomain that sends mail, since SPF and DKIM are looked up at the exact name. DMARC differs: receivers fall back to the organisational domain’s record when a subdomain has none, applying its sp tag. This tool reads the exact name you enter, so an empty DMARC result on a subdomain often means the parent’s policy is what applies.

They answer different questions. The DNS lookup tool shows you records — any type, any resolver, with a delegation trace. This one judges a specific set of them: it expands the SPF chain rather than printing one line, counts it against the limit, and reads DMARC and DKIM against the rules that govern them. Use that one to see what is published, this one to find out whether it is correct.