Skip to content
fixyour.page

DMARC Checker

Check a DMARC record and see what its policy actually does.

Your data stays in your browser
Enter a domain to check its DMARC policy. Queries go straight from your browser to Cloudflare's public DNS resolver, never to our servers.

Related Tools

SPF Checker

Check a domain's SPF record. Follows every include and counts the 10-lookup limit.

Use tool →

DKIM Checker

Look up and validate DKIM records by selector. Key type, size, and testing flags.

Use tool →

MX Record Lookup

Look up MX records for any domain. See mail servers, priorities, and misconfigurations.

Use tool →

Email Header Analyzer

Parse raw email or message headers to trace delivery path, authentication, and delays.

Use tool →

How to Check a DMARC Record

Type a domain and hit Check. The tool queries the TXT record at _dmarc.yourdomain.com over DNS-over-HTTPS, straight from your browser, and breaks the record down tag by tag in plain English. You get the policy, how much mail it covers, where the reports go, and a checklist of everything receivers actually enforce, with RFC 7489 references where it matters.

Two checks here that most lookup tools skip. If you check a subdomain and nothing's published there, we fall back to the organizational domain, the same discovery receivers do (RFC 7489 §6.6.3). And if your reports go to a third-party address, we verify the receiving domain has authorized them. An unauthorized external rua address means receivers silently skip sending reports, which is why some domains publish a perfect record and never see a single one.

How DMARC Ties SPF and DKIM Together

SPF and DKIM each verify something, but neither one checks the From address your recipient actually sees. SPF validates the envelope sender. DKIM validates whatever domain signed the message. A spoofer can pass both while putting your domain in the From header. DMARC closes that gap with alignment: the domain that passed SPF or DKIM has to match the From domain. One aligned pass is enough.

That's why mail through third-party platforms sometimes fails DMARC while passing SPF. The platform's bounce domain passes SPF, but it doesn't align with your From domain. The fix is a DKIM signature from your own domain, which is exactly what the platform's "domain authentication" setup gives you. Test the other two legs with our SPF Checker and DKIM Checker.

Rolling Out DMARC Without Breaking Your Mail

Start at p=none with a rua address. Nothing changes for your mail, but reports start arriving, and they'll show every server sending as your domain, including the ones you forgot about. Fix the legitimate senders that fail. Usually it's a missing DKIM signature or an SPF include that never got added.

When the reports look clean, move to p=quarantine; pct=25. A quarter of failing mail goes to spam, so a mistake stings instead of burns. Ramp pct to 100, then switch to p=reject. Two warnings from the field: pct does nothing while you're still on p=none, and a domain that sits at p=none forever is advertising that spoofing it works. Starting from zero? Our SPF & DKIM Generator builds all three records.

What does p=none actually do? +
Nothing, to the mail itself. p=none tells receivers to deliver everything normally and send you aggregate reports about what would have failed. It's the rollout stage: publish it, watch the reports for a few weeks, fix your legitimate senders, then move to quarantine. A domain that's been on p=none for three years isn't monitoring anymore, it's stalled.
What's the difference between quarantine and reject? +
quarantine asks receivers to treat failing mail with suspicion, which in practice means the spam folder. reject asks them to refuse it during the SMTP conversation, so the sender gets a bounce. reject is the end goal, but quarantine is the safer middle step: a misconfigured legitimate sender lands in spam instead of disappearing without a trace.
What are rua reports and do I need them? +
Aggregate reports: XML files that receivers like Google and Microsoft send (usually daily) listing every source that sent mail as your domain and whether it passed SPF and DKIM. Yes, you need them. They're how you find spoofers and the forgotten marketing platform still sending as you. The raw XML is rough reading, so most people feed them to a report parser.
Why is my DMARC record being ignored? +
Four usual suspects. Multiple DMARC records at _dmarc, receivers discard all of them (RFC 7489 §6.6.3). v=DMARC1 isn't the first tag, which makes the record invalid. A typo in a tag name, receivers skip tags they don't recognize, so a misspelled p means no policy at all. Or the record sits at the wrong name: DMARC only works at _dmarc.yourdomain.com, not at the root.
↑ Back to top