A DMARC checker that follows the 2026 rules
This DMARC checker finds the Domain-based Message Authentication, Reporting and Conformance policy that receivers apply to a domain, validates every tag, and checks that your report addresses will actually receive reports. It follows RFC 9989, the standards-track DMARC published in May 2026 that replaced RFC 7489 (March 2015), while still explaining how older receivers read tags such as pct.
Instead of a public-suffix list, the checker uses the RFC 9989 DNS tree walk: it queries _dmarc at the domain and each parent, never more than eight names, and shows which record was used and why. A short email authentication score combines MX, SPF and DMARC, a rollout plan shows your next step from none to reject, and a generator writes a new record. Only DNS queries leave your browser.
How to use the DMARC Record Checker
- Type a domain or an email address and press “Check DMARC”.
- Read the verdict and the policy meter (none, quarantine, reject), then the email authentication summary.
- Open “Policy discovery” to see every _dmarc name queried and which record applies — useful for subdomains.
- Work through the checks and the report-address table; unauthorized external addresses are flagged with the exact record to add.
- Switch to “Generate a record”, choose the policy and report addresses, and copy the host and value into your DNS.
DMARC Record Checker features
RFC 9989 tree walk
Policy discovery without a public-suffix list: parents are queried in order, names with eight or more labels jump to the seven right-most labels, and psd= stops the walk.
Every tag validated
p, sp, np, t, psd, adkim, aspf, fo, rua and ruf are checked; pct, rf and ri are explained as historic, and unknown tags are listed.
Report authorization
For each rua/ruf address at another organization, the checker queries yourdomain._report._dmarc.their-domain as RFC 9990 §4 requires.
Score and rollout plan
MX 2, SPF 3 and DMARC 5 points, with the next step from monitoring to enforcement highlighted.
Generator
Builds a record with sp, np, t=y, rua, ruf, fo and strict alignment, and lists any authorization records your report service must publish.
Worked example: which record applies to a subdomain?
Check a.b.shop.example.com when only _dmarc.example.com exists with v=DMARC1; p=quarantine; sp=reject; rua=mailto:agg@example.com. The checker queries _dmarc.a.b.shop.example.com, _dmarc.b.shop.example.com, _dmarc.shop.example.com, _dmarc.example.com and _dmarc.com — five queries — and reports “Inherited from example.com”: the organizational domain’s sp=reject applies, because the subdomain exists. For a name with ten labels the second query jumps straight to the seven right-most labels, so the walk stops at eight queries.
If the record also sends reports to reports@ext-reports.example, a different organization, receivers first look for a TXT record v=DMARC1 at example.com._report._dmarc.ext-reports.example. When it is missing, the checker marks that address “NOT authorized”: receivers drop those reports.
What changed in RFC 9989 (May 2026)
Aggregate and failure reporting moved to RFC 9990 and RFC 9991, also published in May 2026. Many receivers still run RFC 7489 code, which is why the checker explains both readings of a record.
| Tag | RFC 7489 (2015) | RFC 9989 (2026) |
|---|---|---|
| pct | 0–100, share of failing mail | Removed; ignored as unknown |
| t | — | y = apply one level less (replaces pct=0) |
| np | Only in RFC 9091 | Policy for non-existent subdomains |
| psd | — | Marks public suffix domains |
| rf, ri | Report format, interval | Removed |
| Organizational domain | Public-suffix list | DNS tree walk, at most 8 queries |
DMARC Record Checker FAQ
What does a DMARC checker look for?
It finds the DMARC record that applies to the domain, checks that it starts with v=DMARC1 and has a valid policy, validates the other tags, and confirms that report addresses can receive reports. This one also scores SPF and MX and suggests your next step.
Is p=none enough for Gmail, Yahoo and Outlook.com?
Yes for the bulk-sender rules: since February 2024 Google and Yahoo require bulk senders to publish DMARC with at least p=none, plus SPF and DKIM, and Outlook.com applies the same rule to senders of more than 5,000 messages a day from 5 May 2025. But p=none does not stop spoofing — plan to reach quarantine or reject.
Should I still use pct?
No. RFC 9989 removed pct because receivers applied values between 0 and 100 inconsistently. Use t=y for a dry run of a stricter policy, then remove it. Older receivers that still honour pct read a missing tag as 100.
Why are my DMARC reports not arriving?
Check that rua uses mailto: and a valid address. If the address is at another organization, that organization must publish v=DMARC1 at yourdomain._report._dmarc.theirdomain — the checker tests this for you. Reports usually arrive once a day.
Do subdomains need their own DMARC record?
No. Without one, the organizational domain’s record applies, using sp= for existing subdomains and np= for names that do not exist. Publish a separate record only when a subdomain needs a different policy.
Is this DMARC checker private?
It sends only DNS queries — the _dmarc names and record types — to Google Public DNS over HTTPS, with Cloudflare as a fallback. Nothing else leaves your browser. For individual records, use the DNS Lookup; to test an address list, the Email Validator.