Short answer: A DMARC check reads TXT at _dmarc.domain and reports policy and common tags. It cannot inspect private reports or guarantee a recipient action. Use it with SPF and DKIM evidence before changing mail policy. This page gives a bounded public observation for DMARC Checker, not a universal promise about every user, provider or future request.
What it measures
The tool constructs _dmarc plus a validated domain, reads public TXT and reports p, sp, pct, rua and alignment fields. It does not fetch report destinations or process private reports. Read the form status and result together. A missing or unavailable upstream response is different from a clean result, and the submitted input must remain attached to the evidence.
Protocol and standards
RFC 7489 defines DMARC policy publication, identifier alignment and reporting across SPF and DKIM. The standard distinguishes requested policy from receiver discretion. The linked primary references explain the terminology and normative boundaries. Implementations, caches, trust stores, resolver behavior and operator policy can still affect a live observation, so standards should guide interpretation rather than replace it.
Inputs and validation
Enter the organizational domain, not a mailbox, URL or private report. For subdomains, check parent policy and sp behavior documented by the mail administrator. Use only the public value requested by the form. Remove credentials, fragments, private addresses and unrelated paths. Validation protects the upstream request and prevents private material from entering a diagnostic workflow.
Outputs and evidence
The result shows public DMARC TXT and a bounded interpretation. A syntax warning differs from receiver rejection; inspect the full record and alignment sources. Preserve the input, status and check time when sharing the result. Empty, unavailable and positive responses have different meanings. Do not combine rows from separate checks without keeping their names, protocols and timestamps visible.
Worked example
If example.com publishes v=DMARC1; p=quarantine; pct=100, the observation is a policy request, not proof that every receiver will quarantine or that alignment passes. This is an explanatory example, not a claim that the same value exists for another domain or endpoint. Re-run after a controlled change with equivalent inputs so the difference can be attributed safely.
How to interpret the result safely
Check the exact From domain and aligned SPF or DKIM before changing policy. Policy changes should follow staged evidence and authorized report review. Alignment is evaluated against the visible From domain: relaxed alignment can share an organizational domain, while strict alignment requires an exact domain match. SPF alignment follows the authenticated MAIL FROM identity; DKIM alignment follows the d= signing domain. The pct tag describes sampling requested by the policy publisher, while rua identifies aggregate report destinations subject to receiver validation. A rollout can move from p=none to quarantine or reject only after authorized operators review representative reports, correct legitimate senders, and confirm forwarding paths. Never treat a published rua address as proof that reports were received. First ask whether the tool measured the question you actually have. Then compare an important conclusion with an independent source such as provider configuration, a real message, an authoritative registry, a browser observation or an operator log.
Limitations and upstream behavior
Receiver implementation, authentication, alignment, forwarding, sampling, reports and DNS caching can change outcomes beyond a TXT snapshot. Network location, cache state, rotation, rate limits and policy can change public results. Use the upstream operator documentation for remediation or account action. This tool reports uncertainty instead of inventing a value.
Troubleshooting checklist
- Verify _dmarc.domain exactly.
- Inspect aligned SPF and DKIM from a real message.
- Keep private reports out of this form.
Key takeaways
- The tool constructs _dmarc plus a validated domain, reads public TXT and reports p, sp, pct, rua and alignment fields. It does not fetch report destinations or process private reports.
- Check the exact From domain and aligned SPF or DKIM before changing policy. Policy changes should follow staged evidence and authorized report review. Alignment is evaluated against the visible From domain: relaxed alignment can share an organizational domain, while strict alignment requires an exact domain match. SPF alignment follows the authenticated MAIL FROM identity; DKIM alignment follows the d= signing domain. The pct tag describes sampling requested by the policy publisher, while rua identifies aggregate report destinations subject to receiver validation. A rollout can move from p=none to quarantine or reject only after authorized operators review representative reports, correct legitimate senders, and confirm forwarding paths. Never treat a published rua address as proof that reports were received.
- Receiver implementation, authentication, alignment, forwarding, sampling, reports and DNS caching can change outcomes beyond a TXT snapshot.
FAQ
Does DMARC replace SPF and DKIM?
No. It uses their results and alignment.
What does p=reject request?
It requests rejection subject to receiver policy and evaluation.
Why is the record at _dmarc?
That label locates policy for the visible From domain.
Can this tool read reports?
No. It reads public TXT only.
Sources
Primary references used for this guide: