DMARC Checker
Check any domain's DMARC policy. It explains every tag in plain English, follows the RFC 9989 tree walk that receivers use for subdomains, flags the legacy pct tag, and makes sure your report addresses will actually receive reports.
DMARC Checker
How this lookup works. When you press Check DMARC, your browser sends the question over encrypted DNS-over-HTTPS to Cloudflare's public resolver (1.1.1.1), or to Google Public DNS (8.8.8.8) if you choose it below. The request goes straight from your device to them. It doesn't pass through ToolFeather: we have no server in the path, so we never see or store the names you look up. Requests are sent without cookies or a referrer. Each resolver has its own privacy policy: Cloudflare · Google.
Results appear here.
Queries your browser sent (0)
These are the exact requests, each one a link. Open one to see the raw JSON answer from the resolver.
Live lookup: your browser asks Cloudflare or Google DNS directly. Nothing passes through ToolFeather.
Scratchpad auto-saved
How it works — in four simple steps
No signup and nothing to install — it all runs in your browser.
Enter your From: domain
A subdomain works too.
Check DMARC
The tool queries _dmarc and walks up if it needs to.
Read the verdict
Effective policy, subdomain policies and report addresses.
Act on the checks
Fix errors, then tighten the policy step by step.
p=none only watches. Spoofed mail is still delivered until you reach quarantine or reject.
Features
RFC 9989 aware
Knows np, t and psd, flags pct/rf/ri as removed, and applies the new rules for missing or invalid policies.
DNS tree walk
Finds the policy for any subdomain the way receivers do, and shows each query and the organisational domain.
Every tag explained
A table of every tag, plus the defaults that apply when a tag is left out.
Report authorisation
Checks that rua/ruf addresses at another domain have published their _report._dmarc authorisation.
Roll-out advice
Clear next steps from none to quarantine to reject, with the testing-mode and subdomain pitfalls.
About the DMARC Checker
DMARC links SPF and DKIM to the address people actually see in the From: line. A message passes DMARC when SPF or DKIM passes and the domain it checked matches the From: domain ("alignment"). The domain owner publishes a TXT record at _dmarc.example.com saying what receivers should do with mail that fails: p=none (just report), p=quarantine (spam folder) or p=reject (refuse). It's the one control that actually stops other people sending mail that claims to come from your domain.
DMARC was rewritten in 2026. RFC 9989 replaces RFC 7489, with reporting split into RFC 9990 (aggregate) and RFC 9991 (failure). It removes the pct, rf and ri tags, adds np for non-existent subdomains, t for testing mode and psd for public suffixes, and replaces the Public Suffix List with a DNS tree walk. For mail.example.com a receiver checks _dmarc.mail.example.com and, if there's nothing there, walks up label by label (at most eight queries) to find the organisational domain's record. Then it applies sp or np, depending on whether the subdomain exists. Existing RFC 7489 records keep working.
The checker runs that walk from your browser and shows each query. Then it checks the details that quietly break DMARC: duplicate records (all of them get ignored), p=none left on for years, pct below 100 (updated receivers ignore it), weaker subdomain policies, and report addresses at another domain. A third-party report address only receives reports if that domain publishes an authorisation record at yourdomain._report._dmarc.theirdomain, and the checker looks that up too.