DMARC Record Checker
Understand the policy receivers find for your domain and where authentication reports are requested.
Enter the domain in the visible From address. We inspect _dmarc and, when needed, perform a bounded DNS tree walk for an inherited policy.
No registration required. Checks run on our server using Google Public DNS. Our DNS cache lasts up to five minutes; upstream DNS caches can delay changes further. No email test allowance is used.
How to use DMARC Record Checker
- Take the domain from the visible
Fromaddress in a message, or from the sending identity configured in your mail platform. - Enter just that domain. For
newsletter@news.example.com, enternews.example.com, not the full address or_dmarc.news.example.com. - Select Check DMARC. Domain is required and there are no optional fields. The tool checks the requested name and may discover an inherited policy through its bounded DNS tree walk.
- Read the discovered policy name, tag checks and reporting authorization findings. Configure report collection and review legitimate senders before changing enforcement.
What this tool checks
The checker uses Google Public DNS to discover a recognizable v=DMARC1 TXT policy. Its discovery process follows a bounded DNS tree walk, with up to eight iterations; receivers using older public-suffix-list discovery can select differently.
- The selected policy’s tags, including
p,sp,np,aspf,adkim,t,psd, failure reporting options, and supported legacy numeric fields. - The requested policy for the input:
pfor a direct record, orspfalling back topfor an inherited record. Other subdomain settings are displayed as configuration. - The syntax of
mailto:destinations inruaandruf, and external report authorization in DNS, subject to a five-external-destination cap and overall DNS limits. - Optional report settings, alignment modes, test mode, legacy tags and unknown extensions, so they are not confused with message authentication results.
It does not send reports, verify ownership of a report mailbox or evaluate SPF/DKIM alignment on an email. A policy discovery Pass means a record was selected; read Tag syntax and the other findings before relying on it.
Understanding your results
Monitoring with p=none is a valid rollout stage. Review authentication and reports before enforcement. Alignment modes are settings, not proof that a message passes.
| Finding | Meaning & likely cause | Next action |
|---|---|---|
| Pass: policy discovery / tag syntax | A direct or inherited record was found, or the inspected tags are valid. These are separate findings. | Check the displayed policy domain and all tag errors, especially when testing a subdomain. |
| Fail: policy not published | No recognizable DMARC record was found in the bounded discovery walk. | Confirm the input and publish a single TXT policy at its _dmarc name after configuring authentication. |
| Fail: duplicate policy / tag / report URI | Duplicate records, an invalid policy value or an unsupported reporting destination was found. | Correct the named field. Use a valid mailto: destination for reporting in this checker. |
| Info: p=none / optional reports | Monitoring is requested, or rua/ruf is absent. Missing reporting destinations do not by themselves invalidate DMARC. | Set up reports if needed; review authentication coverage before requesting quarantine or rejection. |
| Pass: quarantine / reject | The record requests enforcement. Receivers still apply their own handling. | Review legitimate traffic and alignment; this is not evidence that an email passes DMARC. |
| Warning: external authorization / test mode | The report destination has no matching authorization, or t=y requests test mode. | Ask the reporting provider to publish the named authorization; review whether test mode is intentional. |
| Unknown: discovery / DNS / destination cap | The resolver could not complete a query, or additional external destinations were skipped. | Retry technical errors or inspect skipped authorizations separately. Unknown does not establish that a record is missing. |
| Info: alignment / legacy / extension | These rows explain published settings, including strict versus relaxed alignment and historic tags. | Use them to interpret the policy; evaluate a real message separately for authentication. |
What is DMARC and why does it matter?
Domain-based Message Authentication, Reporting and Conformance (DMARC) connects email authentication to the domain in the visible From address. Alignment means that an authenticated SPF or DKIM domain matches the From domain under the policy’s strict or relaxed rules. A DMARC policy tells receivers what handling is requested for failing mail and where reports may be sent.
Use this tool to review a new policy, investigate a subdomain’s inherited settings or diagnose missing report authorization. It cannot prove that your legitimate services align. Review their SPF policies and DKIM selector keys, then compare the actual message identities.
Frequently asked questions
Should I enter From, Return-Path or my website domain?
Use the domain in the visible From address. Return-Path is relevant to SPF and may belong to a different service. A website domain is relevant only if it is also the From domain you are investigating.
Why does the result show a parent domain?
When the exact name has no recognized policy, the bounded discovery walk may find an inherited policy. Read the selected lookup name and the effective policy. A receiver using a different discovery method may not make the same selection.
Do missing rua or ruf tags make my policy invalid?
No. They are optional reporting destinations. Without rua, the record does not request aggregate reports at a mailbox. Without ruf, it does not request failure reports there. The tool does not test whether any configured destination actually receives reports.
Why are reports to another domain not authorized?
External collection can require an authorization TXT record controlled by the reporting destination. The result gives the exact name to discuss with that provider. After a change, allow DNS caches to expire; this service caches eligible DNS answers for up to five minutes, in addition to upstream caching.
Why can SPF and DKIM pass while DMARC fails?
Passing authentication can identify domains unrelated to the visible From domain. DMARC needs an aligned passing identity. The SPF and DKIM pass, but DMARC fails guide walks through this mismatch; this DNS lookup does not check a message’s alignment.
Should I switch directly from none to reject?
Review reports and verify alignment for all legitimate sending services first. A valid reject record requests rejection of failing mail; it does not establish that your current mail is ready for that change.