DMARC Inspector

DMARC Inspector sends the domain you enter to the OmniKitly service, which resolves the TXT records at _dmarc followed by that name — the one place a DMARC record is ever published. The record that comes back is then analysed in the page itself. The first line gives the policy on its own and what it does to failing mail; a table lists every tag as published with what that tag means; and rows are added for the defaults a record leaves out, so an absent sp shows as inherited from p and unset alignment shows as relaxed. Findings and Notes follow underneath, and the raw lookup — the exact name queried, every TXT string found at it and the service's own summary — stays downloadable as dmarc-yourdomain.json.

The policy tag is the whole point of the record, and its three values are nowhere near equivalent. A policy of none changes nothing about delivery: mail failing the check arrives exactly as it did before, and the record buys reports and nothing else. Quarantine asks receivers to file that mail as spam. p=reject asks them to refuse it during the SMTP conversation, and it is the only setting that actually stops a stranger sending as the domain. A record can carry every optional tag, look thoroughly considered, and still be doing nothing, because monitoring is where most rollouts stop and quietly stay.

Four things limit what a result can settle. The query is made against exactly the name you type and never climbs to the organisational domain, so asking about mail.example.com reports nothing even when example.com publishes a record its subdomains inherit. A resolver failure is not distinguished from an absent record — a timeout, a server failure and a domain publishing nothing all end at the same "No DMARC record published" note. When two DMARC records sit at the same name, a state receivers treat as having no usable policy at all, only the first is analysed and the second shows up solely in the downloaded JSON. And where aggregate reports go to an outside domain, the report names the authorisation record that domain must publish (yourdomain.example._report._dmarc.theirdomain) without ever querying it, so that check is left with you.

Whatever the input field says, this page can only run a hostname. The label reads "DMARC record — or a domain to look it up", the placeholder offers both, and Load sample fills the box with a complete record — but sending that record returns "That is not a valid hostname" from the service, because semicolons, spaces and equals signs are not a host name. The record parser those controls point at is real, and is exactly what analyses the record once the lookup has fetched it; it simply cannot be reached by pasting. Typing _dmarc.example.com out in full fails the same check, since an underscore is not accepted in the name you submit and the label is prepended for you anyway. The domain travels over an encrypted connection as a job setting, is stored alongside the job record, and goes when the JSON does at the end of the retention window — six hours after the run unless that default has been changed.

Enforcement is only ever as good as the alignment underneath it, and the analysis says so where the record asks for strict. With adkim=s or aspf=s, a signature or an envelope domain that merely shares the organisational domain no longer counts, so mail from a subdomain or from a sender that rewrites the return path fails DMARC while SPF and DKIM both report a pass. That combination, read next to quarantine or reject, is the usual explanation for a campaign disappearing into spam the week a record was tightened.

Secure server processing. This operation requires temporary server processing.