Free DMARC Record Checker
Look up the DMARC record for any domain, see every tag explained and find out whether the policy actually protects your brand. No account needed.
Free, with no sign-up. Fair-use limits apply. To enforce them we keep the domain you enter and a scrambled form of your IP address for 30 days, as described in our privacy policy.
What DMARC is for
DMARC builds on SPF and DKIM. It tells receiving mail servers what to do with a message that claims to come from your domain but fails authentication, and it asks them to send you reports about what they see. Without it, anyone can put your domain in the From line of a message, and you will probably never know. With it, you can move from watching to blocking, one careful step at a time.
Major mailbox providers now expect a DMARC record from anyone who sends email in volume, and a missing or weak one is one of the most common findings on a domain review. This free checker reads your record and explains it.
Who should care
Any domain that sends email needs DMARC, but it matters just as much for domains that never send. A parked or retired domain with no policy is an attractive name for fraudsters to imitate, because there is nothing to stop them. Publishing a simple reject policy on domains that do not send mail is one of the cheapest protections available, and this checker will confirm it is in place.
How to use the checker
Enter your domain and press Check DMARC. The tool looks for a record at _dmarc.yourdomain. If there is none it also checks the organisational domain, because a subdomain inherits the policy of its parent, and it tells you which record applies. You then get every tag laid out with a plain-English explanation and a list of findings.
Understanding the policy
The p tag is the heart of the record. A policy of none means monitor only: receivers take no action but you still get reports. Quarantine asks receivers to treat failing mail as suspicious, usually by delivering it to spam. Reject asks them to refuse it outright. Most organisations start at none, study the reports until every legitimate sender is authenticated, then tighten to quarantine and finally reject.
Other tags refine the behaviour, and the checker explains each one it finds:
- The pct tag applies the policy to only a percentage of mail, useful for a gradual rollout.
- The sp tag sets a different policy for subdomains.
- The adkim and aspf tags choose strict or relaxed alignment for DKIM and SPF.
- The rua tag lists where aggregate reports are sent, and ruf where forensic reports go.
Checks that catch real mistakes
The checker flags a policy that is still at none, a pct value below 100, an invalid or missing rua address, and syntax errors that would make receivers ignore the whole record. It also checks something people often forget: when your reports are sent to an address on a different domain, that other domain must publish a record authorising it. Without that, the reports are silently discarded and you are running blind.
It is also worth checking your SPF record and DKIM key, because DMARC passes only when at least one of them passes and lines up with the visible From domain.
Moving from monitoring to protection
Publishing a record at p=none is safe, and the reports it produces show every service sending as your domain, including the ones you forgot about, such as the newsletter tool someone set up two years ago. Fix each legitimate sender first, then raise the policy. Moving too fast is the classic way to block your own invoices.
An SEO Web Data account helps with the routine that follows. It includes a DMARC report analyser that reads the XML reports for you and shows who is sending mail as your domain and what is passing, a DMARC generator that builds a correct record, and a weekly watchlist that alerts you if the record is changed or removed. More than seventy domain tools sit alongside your site audits and rank tracking, and every plan starts with a free trial.
Frequently asked questions
Do I need DMARC if I already have SPF and DKIM?
Yes. SPF and DKIM authenticate a message, but only DMARC tells receivers what to do when authentication fails and sends you the reports.
Will p=reject stop my legitimate email?
Only if a genuine sender is not authenticated. That is why you monitor at p=none first and fix every legitimate source before tightening.
Why did the checker use a different domain?
If the exact name has no record, receivers fall back to the organisational domain, and the checker follows the same rule.
How often should I review my DMARC record?
Whenever you add or remove an email service, and at least a few times a year. A watchlist can do it for you.
More free tools
See all free domain tools, or read how the email authentication tools work inside the dashboard.