Check the record your DNS actually returns
Enter the domain from the visible From header, without https:// or the _dmarc prefix. For example.com, the live lookup requests TXT at _dmarc.example.com. The result keeps resolver statuses beside the records, so a timeout cannot masquerade as a clean negative answer. The default example uses a public domain; its result belongs to that domain, not to your sending setup.
To review a draft, paste its TXT value into the optional field. That input is inspected in this browser and replaces the live lookup. Clear the pasted field before checking a published change. The result explicitly labels this mode, because a plausible draft is not proof that DNS contains it. Copy JSON or download the report to keep the evidence you saw.
Three examples you can reproduce
These are hypothetical inputs, not observations of an operating mail system. They illustrate different questions rather than prescribing records to copy into production.
| Pasted input or lookup outcome | What this checker should show | Useful next step |
|---|---|---|
v=DMARC1; p=none; rua=mailto:[email protected] | Monitoring preference and a report destination request | Verify the reporting mailbox and inspect actual reports |
v=DMARC1; p=reject; t=y; pct=25 | Test-mode handling of quarantine under RFC 9989; pct marked historical | Check receiver support and real traffic before tightening |
| One resolver times out and the other has no TXT answer | Unknown, with partial evidence | Retry; do not add a second record to repair an unproven absence |
A query that returns two distinct usable DMARC records does not select the first one as authoritative. Check the records at each resolver, including the TTL and current DNS provider configuration. During a change, different cached responses can disagree even when each resolver sees one record. Preserve that distinction before deleting or replacing anything.
Read the tags without turning them into a delivery score
The current protocol reference is RFC 9989. The version must be first and its value must be DMARC1. In an otherwise usable record, an absent p defaults to none. The inspector explains p, sp, np, alignment and reporting tags, flags repeated or unsupported syntax for review, and withholds a single interpretation when it cannot safely provide one. It is a limited inspector rather than a full receiver implementation.
DMARC needs an aligned SPF pass or an aligned DKIM pass. Seeing both DNS records is not the same as establishing either result for a message. A reporting destination requests reports; this page does not confirm ownership, external destination authorisation or receipt. Policy discovery for organisational domains and public suffixes is outside this exact-name lookup.
Investigate a surprising result
Save the raw result and the name you checked. Compare it with your DNS dashboard, then compare one real received message with sender logs. Look at its visible From domain, envelope domain, signing domain and Authentication-Results together. Remove recipient addresses and other private content before sharing evidence with anyone.
The mail DNS preflight puts neighbouring observations in one report. The SPF checker reads the top-level sending formula, while the DKIM checker lets you investigate a selector. Use the DMARC policy guide to plan a controlled rollout. None of these DNS tools sends a test email or verifies inbox placement; Gmail’s sender guidelines also cover requirements beyond authentication.