Enter a domain to fetch its live DMARC record and validate it against RFC 9989 — the current standard that replaced RFC 7489. You get the effective policy, subdomain and alignment behavior, report destinations, and prioritized fixes.
Enter a domain to look up its published DMARC policy, reporting addresses, and alignment settings.
We query public DNS for _dmarc records and report-authorization records on your behalf. The domain you enter is used only to run the lookup; check results are not stored.
First _dmarc.yourdomain.com is queried. If it has no DMARC record, the checker performs the bounded tree walk to your organizational domain — the same discovery receivers perform.
Every current tag (p, sp, np, t, psd, adkim, aspf, rua, ruf, fo) is validated, defaults are applied, and removed tags like pct are flagged as legacy instead of being honored.
Each rua/ruf destination is checked for a valid mailto URI. Destinations outside your organizational domain are tested for the external authorization record receivers require.
The result distinguishes a missing record, an invalid record, an inherited policy, and monitoring versus enforcing policies — with findings ordered by severity. Unknown answers are never counted as passes.
Build a correct RFC 9989 DMARC record with reporting addresses, then publish it as one TXT record.
Open toolVerify the SPF record your DMARC alignment depends on, including nested includes and the 10-lookup limit.
Open toolInspect the DKIM public key for a selector and confirm the signature side of DMARC alignment.
Open toolCheck the BIMI record that displays your logo in supporting inboxes once DMARC enforcement is in place.
Open toolA DMARC record is a single TXT record published at _dmarc.yourdomain.com that tells receiving mail servers how to handle messages that fail SPF and DKIM alignment for your domain, and where to send reports about that mail. It is defined by RFC 9989, which replaced the older RFC 7489.
RFC 9989 defines a bounded tree walk: when a subdomain has no _dmarc record of its own, receivers inherit the policy published at the organizational domain. This checker follows the same rule, so a result marked "inherited" is exactly what receivers will apply.
No. p=none is a monitoring policy: receivers report failures but deliver the mail anyway, so spoofed messages still reach inboxes. It is the right first step while you discover legitimate senders, but protection only starts at p=quarantine or p=reject.
RFC 9989 removed pct (along with ri and rf). Enforcement now applies to all failing mail; partial rollouts are expressed by moving between none, quarantine and reject instead. If your record still contains pct, it is ignored by current receivers and can be deleted.
When a report address lives in a different organizational domain, that domain must explicitly opt in by publishing v=DMARC1 at <your-domain>._report._dmarc.<their-domain>. Without that authorization record, receivers drop the reports. This checker verifies the authorization for every external destination in your record.
No. DMARC stops exact-domain spoofing and proves your authentication posture, but inbox placement also depends on sender reputation, engagement, and content. Treat DMARC as required hygiene, not a deliverability guarantee.
Automate Sales Outreach & Get Booked!
Start Free Trial(14 Day Free Trial, No CC Required)