Free, no accountEvery tag explainedRated, with a copy-paste fixMade in Montréal

DMARC record checker: read the policy, tag by tag

A DMARC record is nine tags of dense syntax that decide whether anyone can send mail as your domain. This checker reads each one back in plain English, rates the policy from Weak to Excellent, flags the two things most records get wrong, and hands you a copy-paste record for the next step toward p=reject.

_dmarc TXT
p=
sp=
pct=
adkim= / aspf=
rua=
ruf=
fo= / ri=

/100Rated, with fixes

0Accounts needed

FreeNo limits, no card

DMARC record checker

The live lookup needs JavaScript, because it queries DNS from your browser. Enable JavaScript to check a domain, or read the guide below to interpret a record you already have.

Quick answer

What is a DMARC record?

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is a TXT record at _dmarc.<domain> that does two things: it tells receiving servers what to do with mail claiming to be from your domain that fails SPF and DKIM alignment, and it asks them to send you reports about every source sending as you.

DMARC needs SPF or DKIM to align. It adds nothing on its own; it decides what happens when neither authenticated identity matches the visible From domain.
p=none protects nothing. It is a monitoring stage. Roughly two-thirds of published DMARC records never move past it.
rua= is the tag that earns its keep. Aggregate reports name every IP sending as your domain, including the ones you forgot about.
Either check passing is enough. SPF breaks on forwarding, DKIM survives it, and DMARC passes if either aligns. That is why you publish both.
Subdomains inherit unless told otherwise. sp= overrides the policy for subdomains; leaving it unset means they follow p=.

How the rating works

A score, a band, and the exact change to make

Every lookup returns a score out of 100 and a band. The policy sets the ceiling, p=none cannot score above Low, because monitoring is not protection, and deductions follow for the things that hollow out a policy: no reporting address, a partial pct, a subdomain policy weaker than the domain's, or enforcement with no SPF behind it. Under the band is a numbered list of findings and, where one can be written, a copy-paste record for the next step up.

Rating bands
Rating	What it means	Typical cause
Excellent	`p=reject` at 100% with aggregate reporting on and subdomains covered.	A finished rollout with an owner.'
Strong	`p=quarantine` with reporting, or reject with one gap left.	A rollout in its final phase.
Normal	Enforcing, but with a partial `pct` or a loose `sp`.	A ramp that was paused.
Low	`p=none` with reporting on. Monitoring works; nothing is prevented.	Where the majority of DMARC records stop.
Weak	`p=none` and no `rua`, or a record with no `p` tag at all.	A record published to satisfy a checklist.
Missing	Nothing at `_dmarc`.	Anyone can spoof the domain with no visibility to the owner.

“Aggressive by design” is not a failure

p=reject is flagged as aggressive by design, and strict alignment (adkim=s, aspf=s) with reject more so. That combination is the strongest anti-spoofing posture available and exactly right for a bank, a payments brand, or any domain sending only from infrastructure it controls. It is the wrong choice when departments, resellers or SaaS platforms send from subdomains, because strict alignment refuses mail that relaxed alignment would pass. The tool names the trade-off and leaves the decision to you.

Two ways to read the same result

For a domain owner, the findings are an ordered rollout plan: publish, report, fix alignment, ramp, enforce. For an analyst, a DMARC record is unusually revealing, the policy states how spoofable the domain is, the rua address shows whether reports leave the organisation and to which processor, and the combination of the two separates a managed programme from a compliance checkbox. The intelligence panel states the spoofability verdict and the maturity read side by side.

Reference

Every DMARC tag, and what it changes

Only v and p are required. The defaults on everything else are sensible, which means most records need far fewer tags than they carry.

DMARC record tags
Tag	Values	Default	What it does
`v`	`DMARC1`	required	Version. Must be the first tag.
`p`	`none`, `quarantine`, `reject`	required	What receivers do with failing mail from the domain itself.
`sp`	same three	inherits `p`	Policy for subdomains. Set it explicitly if subdomains should differ.
`pct`	1–100	`100`	Share of failing mail the policy applies to. A ramp, not a permanent setting.
`adkim`	`r`, `s`	`r`	DKIM alignment. Relaxed lets a subdomain align; strict requires an exact match.
`aspf`	`r`, `s`	`r`	SPF alignment, same distinction.
`rua`	`mailto:` list	none	Where daily aggregate XML reports go. The most valuable tag in the record.
`ruf`	`mailto:` list	none	Forensic per-message reports. Few receivers send them; they carry personal data.
`fo`	`0`, `1`, `d`, `s`	`0`	When forensic reports are generated. `fo=1` is the useful setting.
`ri`	seconds	`86400`	Requested aggregate reporting interval. Daily is what receivers honour.

Recommended records

The rollout, as four records to copy

Each is a single TXT record at _dmarc.example.com. Move between them deliberately, reading aggregate reports at every stage.

Stage 1, start here

Safe to publish today

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Changes nothing about delivery and begins the reporting that every later step depends on. Use a mailbox or a processor you will actually read; aggregate reports are daily XML and there will be more of them than you expect.

Stage 2, filter

After two to four weeks of clean reports

v=DMARC1; p=quarantine; rua=mailto:[email protected]; fo=1

Failing mail goes to spam rather than the inbox. If your volume is very large, ramp with pct=25 and raise it, then remove the tag once you are at 100.

Stage 3, enforce

The goal state

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; fo=1

Setting sp=reject explicitly matters: attackers routinely spoof invented subdomains because the subdomain policy is so often left loose. Keep reading the reports, because every new SaaS tool that sends for you is a new alignment problem.

Strict alignment

Deliberately aggressive

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]; fo=1

The strongest posture available, and correct for a bank, a payments brand, or any domain that sends only from infrastructure it controls. It is the wrong choice when departments, resellers or SaaS platforms send from subdomains, because strict alignment refuses mail that relaxed alignment would pass.

A domain that sends no mail

Recommended, and usually missing

MX      0 .
TXT     v=spf1 -all
TXT     _dmarc   v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; fo=1

Publish this on every parked domain and brand-defensive registration you own. They are the easiest to abuse because no legitimate mail flows through them and nobody notices when someone else's does.

A third-party rua address names the processor reading your reports, and the same is true of any domain you look up. The fingerprint reference decodes the common ones.

The concept that matters

Alignment: why passing SPF is not enough

SPF authenticates the envelope sender. DKIM authenticates the signing domain. Neither is the address your recipient sees. DMARC's contribution is to insist that an authenticated domain aligns with the visible From domain, which is what closes the spoofing gap.

DMARC alignment outcomes
Visible From	Authenticated domain	Relaxed	Strict
`example.com`	`example.com`	aligns	aligns
`example.com`	`mail.example.com`	aligns	fails
`example.com`	`bounces.provider.net`	fails	fails
`news.example.com`	`example.com`	aligns	fails

The third row is the common surprise: a marketing platform that passes SPF on its own bounce domain gives you no DMARC alignment at all. Fixing it means either a custom return-path on your domain or a DKIM signature with d=example.com.

Playbook

Getting to p=reject without losing mail

Publish SPF and DKIM first. DMARC with neither in place fails everything you send the moment you enforce.
Start at p=none with rua=. This changes nothing about delivery and starts the reports that make every later step safe.
Read the reports for two to four weeks. Expect to find senders you did not know about: an invoicing tool, a monitoring alert, an old form handler.
Fix alignment, not just authentication. Give each legitimate platform a DKIM signature on your domain or a custom return-path.
Move to p=quarantine. Use pct= to ramp if the volume is large, then raise it to 100.
Go to p=reject, and keep reading reports. Every new SaaS tool that sends on your behalf is a new alignment problem.

Why the ramp matters

Enforcement is not reversible in practice: mail rejected at p=reject is gone, and the sender sees a bounce. The reporting phase exists so the list of things that break is discovered from a report rather than from a colleague whose invoices stopped arriving.

FAQ

DMARC questions, answered

How does the DMARC rating work, and why is p=reject called aggressive?

Each lookup returns a score out of 100 and a band from Missing through Weak, Low, Normal and Strong to Excellent. The policy sets the ceiling: p=none cannot score above Low, because monitoring prevents nothing. Deductions follow for a missing rua reporting address, a pct below 100 while enforcing, an sp policy weaker than p, and enforcement with no SPF record behind it. p=reject is labelled aggressive by design rather than penalised, and strict alignment with reject more so: that combination is the strongest anti-spoofing posture available and correct for a bank or payments brand, but it refuses mail from subdomain senders that relaxed alignment would pass. The tool names the trade-off and leaves the decision to you.

What is a DMARC record?

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is a DNS TXT record at _dmarc.<domain> that tells receiving servers what to do with mail claiming to be from your domain when it fails both SPF and DKIM alignment, and asks them to send you aggregate reports about every source sending as your domain.

What is the difference between p=none, p=quarantine and p=reject?

p=none means take no action: failing mail is delivered normally and you only collect reports. p=quarantine asks receivers to treat failing mail as suspicious, usually placing it in spam. p=reject asks them to refuse it outright at the SMTP transaction. Only quarantine and reject actually prevent someone spoofing your domain; p=none is a monitoring stage.

What is DMARC alignment?

Alignment is the requirement that an authenticated domain match the domain in the visible From header. SPF authenticates the envelope sender and DKIM authenticates the signing d= domain, neither of which the recipient sees. DMARC passes only when at least one of them aligns with the From domain: relaxed alignment (the default) accepts a subdomain, strict alignment requires an exact match.

Do I need both SPF and DKIM for DMARC?

DMARC passes if either one aligns, so strictly you need one. In practice publish both: SPF fails whenever a message is forwarded, while DKIM signatures survive forwarding. Domains relying on SPF alone see legitimate forwarded mail fail DMARC.

What are rua and ruf?

rua is the address for aggregate reports: daily XML summaries of authentication results grouped by sending source, with no message content. ruf is for forensic reports, which are per-message and can contain headers and recipient data; few receivers send them, and they carry privacy obligations. Set rua always; ruf is optional.

Why is my own mail failing DMARC?

Almost always alignment rather than authentication. A marketing platform, helpdesk or invoicing tool sends on your behalf and passes SPF on its own bounce domain, which does not align with your From domain. The fix is a DKIM signature with d= set to your domain, or a custom return-path on your domain. Aggregate reports name exactly which source is failing.

Does DMARC stop phishing?

It stops one specific and common technique: mail that puts your exact domain in the From header. It does not stop lookalike domains, display-name spoofing, compromised accounts, or attacks from free mail providers. p=reject is a necessary control, not a complete defence.

Does this DMARC checker store the domains I look up?

No. The lookup runs in your browser: the domain is sent to a public DNS-over-HTTPS resolver (Cloudflare, with Google as a fallback) to obtain the answer, and nothing is logged on our side. Your last five lookups are kept in your browser's local storage only, on your own device.

Key terms

Glossary

DMARC: RFC 7489. A policy record at _dmarc.<domain> stating how receivers should treat mail that fails SPF and DKIM alignment, and where to send reports.
Alignment: The requirement that an SPF- or DKIM-authenticated domain match the visible From domain. Relaxed (r) accepts subdomains; strict (s) requires an exact match.
Policy (p=): none monitors, quarantine filters, reject refuses. The only tag besides v that is required.
Subdomain policy (sp=): An override applying to subdomains. Unset, subdomains follow p=.
Aggregate report (rua): A daily XML summary of authentication results per sending source. Contains no message content.
Forensic report (ruf): A per-message failure report that may include headers and recipient data. Rarely sent, privacy-sensitive.
Organisational domain: The registrable domain (example.com) whose DMARC policy applies to subdomains with no record of their own.
pct=: The percentage of failing mail the policy applies to. Intended as a temporary ramp during rollout.

Sources & methodology

How this tool gets its answers

Lookups run from your browser over DNS-over-HTTPS against Cloudflare's resolver at cloudflare-dns.com, falling back to Google's at dns.google. The tool queries TXT on _dmarc.<domain>, selects the record beginning v=DMARC1, and parses each tag, applying RFC 7489 defaults where a tag is absent. It also queries TXT on the domain itself to report whether SPF is published, since DMARC needs SPF or DKIM to align.

One limitation: the tool reads the record at the exact domain you enter. It does not walk up to the organisational domain, so a subdomain that inherits its parent's policy shows as having no record of its own, which is correct, but means you should also check the parent. Tag definitions, defaults and alignment rules cite RFC 7489; SPF is RFC 7208 and DKIM RFC 6376. We publish no invented ratings, review counts or certifications.

A policy is only as good as the mail behind it.

DMARC decides what happens when SPF and DKIM fail. Check that both are published and aligned, then verify the addresses you are sending to.

Verify an email address → Run the full MX & TLS check