DMARC Checker

A DMARC checker reads the TXT record at _dmarc.yourdomain.com and tells you what receivers will do with mail that fails authentication. It shows the policy, the alignment modes, the report addresses, and whether the record is enforcing anything at all or only watching.

What DMARC adds on top of SPF and DKIM

SPF authorises the envelope sender. DKIM signs the message with a key published under a signing domain. Neither one has any opinion about the From: address your recipient actually reads — which is why, on their own, they do not stop spoofing. DMARC (RFC 7489) closes that gap with two rules: the authenticated domain must align with the visible From: domain, and the domain owner gets to state a policy for what happens when nothing aligns.

A message passes DMARC when at least one of these is true: SPF passed *and* the MAIL FROM domain aligns with the From: domain, or DKIM verified *and* the signature's d= domain aligns with the From: domain. One is enough. This is the single most useful fact about DMARC in day-to-day troubleshooting — a message that fails SPF entirely, because a mailing list re-sent it from its own servers, still passes DMARC if the DKIM signature survived intact.

Alignment: relaxed vs strict

Alignment is a comparison between two domain names. aspf controls it for SPF, adkim for DKIM, and both default to relaxed (r) when the tag is absent.

From: domain	Authenticated domain	Relaxed (r)	Strict (s)
example.com	example.com	Aligned	Aligned
example.com	mail.example.com	Aligned	Not aligned
news.example.com	example.com	Aligned	Not aligned
example.com	example.net	Not aligned	Not aligned
example.com	sendgrid.net	Not aligned	Not aligned

Read the full explanation of dmarc checker results ↓

Relaxed alignment succeeds when both names share the same organisational domain — the registrable domain determined from the Public Suffix List, so example.co.uk and mail.example.co.uk align but example.co.uk and other.co.uk do not. Strict alignment demands the two names be identical, label for label.

Strict alignment is the most common self-inflicted DMARC wound. SendGrid, Mailgun, Amazon SES and Microsoft 365 routinely sign with a subdomain or bounce from one; those streams are aligned under relaxed and fail under strict. Unless you control every sending path yourself, leave adkim and aspf at the default r.

Note what alignment does not require: your ESP's own domain never has to match anything. When SendGrid sends for you with d=example.com because you completed their DKIM setup, the signature aligns and DMARC passes — even though the connecting IP, the envelope sender, and the sending infrastructure all belong to SendGrid. That is the whole point of ESP DKIM delegation, and it is why "set up branded/custom DKIM at your provider" is the single highest-value fix for a failing domain.

Reading the policy

Tag	Effect	When to use it
`p=none`	Receivers act on nothing; you still get aggregate reports.	Weeks 1–4 of a rollout, while you find every legitimate sender.
`p=quarantine`	Failing mail goes to the spam folder.	The safe middle step once reports show only known sources failing.
`p=reject`	Failing mail is refused, usually at SMTP time with a bounce.	The end state. This is what actually stops domain spoofing.
`sp=`	Overrides the policy for subdomains only.	Rarely. Absent, subdomains inherit `p`, which is normally correct.
`pct=`	Applies the policy to a percentage of failing mail.	A temporary ramp during the move to quarantine. Remove it afterwards.
`rua=`	Where daily aggregate XML reports are sent.	Always. Without it you are enforcing blind.
`ruf=`	Where per-message failure reports are sent.	Optional and largely obsolete — most large receivers stopped sending them.

p=none is worth being blunt about: it enforces nothing. Gmail, Yahoo and Outlook will keep delivering spoofed mail that fails DMARC, exactly as they did before you published the record. It satisfies the bulk-sender requirement and it turns on the reporting you need, but a domain that has sat at p=none for two years is not protected — it is monitored.

What Google, Yahoo and Microsoft actually require

From 1 February 2024, Google and Yahoo require every sender delivering 5,000 or more messages per day to their users to publish SPF, DKIM and a DMARC record with at least p=none, to have the From: domain align with either SPF or DKIM, to keep the Postmaster Tools spam rate under 0.3%, to offer one-click unsubscribe (RFC 8058) on marketing mail, and to publish valid forward and reverse DNS for their sending IPs. Below that volume, Gmail still requires at least one of SPF or DKIM on every message.

Microsoft applied the same bar to Outlook.com, Hotmail and Live from May 2025 for senders above 5,000 messages a day, initially routing non-compliant mail to the Junk folder rather than rejecting it. The practical takeaway is the same at all three: a valid, aligned DMARC record is now the entry ticket to the inbox at consumer mailbox providers, not an optional hardening step. Bounces reading 550 5.7.26 (Gmail, unauthenticated) and 550 5.7.15 (Microsoft, access denied) are the receiving side of these rules.

Common findings and their fixes

No record found. Nothing at _dmarc.example.com. Publish a starter record — the DMARC generator builds one — and check the name: many panels append the domain automatically, so entering the full _dmarc.example.com creates _dmarc.example.com.example.com.
Two DMARC records. RFC 7489 §6.6.3 makes receivers ignore DMARC for the domain entirely when more than one record is found. You are worse off than with none. Delete all but one.
Record on the wrong host. DMARC lives only at _dmarc, never on the bare domain. A v=DMARC1 string in the root TXT records does nothing.
`p=none` with no `rua`. The record is valid and completely inert: no enforcement and no visibility. Add an aggregate report address.
External `rua` without authorisation. If reports go to a different organisational domain, that domain must publish example.com._report._dmarc.reporter.com containing v=DMARC1. Without it, receivers refuse to send your reports there (RFC 7489 §7.1). The checker above verifies this with a live query.
Legitimate mail failing after moving to `p=reject`. Read the aggregate reports before blaming DMARC: the failing source is nearly always a forgotten SaaS tool, an internal application relay, or a mailing list. Fix the alignment for that source, do not weaken the policy.

Check it from the command line

# The DMARC record itself
dig +short TXT _dmarc.example.com

# Prove there is exactly one — two lines means DMARC is ignored entirely
dig +short TXT _dmarc.example.com | grep -c DMARC1

# The subdomain policy that actually applies to mail.example.com
dig +short TXT _dmarc.mail.example.com

# External report authorisation, when rua points at another org's domain
dig +short TXT example.com._report._dmarc.reporter.com

# Query an authoritative nameserver directly, bypassing every cache
dig @$(dig +short NS example.com | head -1) TXT _dmarc.example.com +noall +answer

DMARC is an ordinary TXT record on the _dmarc label.

Fix the inputs before tightening the policy

DMARC does not authenticate anything itself — it only decides what to do when SPF and DKIM fail to align. If mail is failing, the fault is upstream. Confirm the SPF record is inside the ten-lookup limit, confirm DKIM is signing with an aligned d=, and use the email header analyzer on a real failing message to see exactly which of the two broke and why.

DMARC Record Generator

Create a DMARC record with a safe rollout policy

Frequently asked questions

Does p=none protect my domain?

No. p=none is monitoring only: receivers report failures to you but deliver the mail exactly as they would have without a DMARC record. It meets the Google and Yahoo bulk-sender requirement and it switches on aggregate reporting, but spoofed mail using your domain still reaches inboxes until you move to quarantine or reject.

What is the difference between relaxed and strict alignment?

Relaxed (r, the default) treats two names as aligned when they share an organisational domain, so mail.example.com aligns with example.com. Strict (s) requires the names to be identical. Strict breaks most third-party senders, which sign or bounce from a subdomain, so relaxed is almost always the right choice.

Can a message pass DMARC while failing SPF?

Yes, and it happens constantly. DMARC passes if either SPF or DKIM passes *and* aligns. Forwarding and mailing lists routinely break SPF while leaving the DKIM signature intact, so an aligned DKIM signature carries the message through on its own.

Why do my DMARC reports never arrive?

Three usual causes: no rua tag is published; the reports are going to a mailbox nobody reads because raw aggregate reports are gzipped XML; or the report address is on a different organisational domain that has not published the _report._dmarc authorisation record, so receivers refuse to send them. The checker above tests that last case directly.

Do subdomains need their own DMARC record?

Not usually. If a subdomain has no _dmarc record of its own, receivers fall back to the parent organisational domain policy, using sp= if present and p= otherwise. Publish a subdomain record only when that subdomain genuinely needs a different policy.

What does pct= actually do?

It applies the stated policy to that percentage of failing messages and downgrades the rest to the next weaker policy — pct=25 with p=reject rejects a quarter and quarantines the remainder. It is a rollout ramp, not a permanent setting; leaving it below 100 permanently means most spoofed mail is never acted on.

Will p=reject break my mailing lists?

It can. Lists that modify the subject or append a footer break the DKIM signature, and they re-send from their own servers so SPF fails too — the message then fails DMARC and is rejected. Well-maintained lists work around this with From: rewriting (ARC or the list address in From:). Check your reports for list traffic before enforcing.

How long should I stay at each policy level?

Roughly four weeks at p=none while you identify every sender, four weeks at p=quarantine ramping pct from 25 to 100, then p=reject. Do not move on a schedule alone — move when the aggregate reports show no legitimate source failing alignment.