DMARC Checker Explained

Q: What does a good DMARC record look like?

A fully enforcing record reads roughly v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; sp=reject; pct=100. The parts that matter for protection are p=reject (refuse forged mail), sp=reject (apply the same to subdomains), and pct=100 (cover all mail, not a sample). A record missing these — especially one at p=none — is published but not protective.

Q: Why does my DMARC checker show a record but say I can still be spoofed?

Almost always because your policy is p=none, which tells receiving servers to take no action on forged mail — only to report it. A record at p=none is valid and will show as "found," but it provides no more spoofing protection than having no record at all. Moving to p=quarantine and then p=reject is what converts a monitored domain into a protected one. The August 2026 census found only 9.3% of domains reach an enforcing policy.

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

p=none is monitor-only: forged mail is delivered as normal and merely reported. p=quarantine sends failing mail to the spam/junk folder. p=reject refuses failing mail outright so it never arrives. Only quarantine and reject stop forgery reaching a recipient; defaults.exposed counts only these two as enforcing. p=none is a useful first step while you confirm legitimate senders, not a finished state.

Q: Will publishing DMARC break my legitimate email?

Not if you sequence it. Starting at p=none changes nothing about delivery while collecting the aggregate reports that show which of your services need aligning. Only after those reports confirm your legitimate senders pass do you tighten to quarantine and then reject. Domains that break mail almost always jumped straight to p=reject without the listening phase.

Published 2026-08-21

A DMARC checker looks up the DMARC record your domain publishes in public DNS, parses it, and tells you one thing that matters above all others: whether a receiving mail server has been instructed to reject email that forges your domain. The catch is that publishing a DMARC record and being protected by one are not the same thing — and most checkers stop at “a record exists.” The August 2026 defaults.exposed census graded 376,928,750 domains and found that only 9.3% — 34,983,618 — publish an enforcing policy. The other 90.7% either publish no DMARC at all or publish a record that a checker will show in green while it quietly does nothing. This guide explains how to read every field of a DMARC record, how to tell a real policy from a decorative one, and how to check your own domain for free.

If you have run a DMARC checker and seen a record come back, the natural conclusion is “we’re covered.” That conclusion is wrong far more often than it is right. A DMARC record can be present, syntactically valid, and still leave your domain exactly as spoofable as a domain with no record at all — because the field that decides enforcement is a single tag most checkers under-explain. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.

What a DMARC Checker Actually Tells You

DMARC — Domain-based Message Authentication, Reporting and Conformance (RFC 7489) — is a public DNS record that tells the world’s mail servers what to do with email claiming to be from your domain that fails authentication. A checker does three things:

Looks up the record. DMARC lives at a fixed location: a TXT record on the _dmarc subdomain of your domain (_dmarc.yourbusiness.com). The checker queries public DNS for it — no access to your systems required, which is exactly why an attacker can see your posture too.
Parses the tags. A DMARC record is a semicolon-separated list of tags. The checker breaks them apart and reports what each one says.
Interprets the policy. This is where checkers differ wildly. A good checker tells you whether the policy actually stops forgery. A weak one tells you a record exists and colours it green.

The single most important output is the policy tag (p=). Everything else — reporting addresses, alignment modes, percentages — modifies or observes; the p= tag is the instruction. Get that one wrong and the rest is decoration. For how defaults.exposed grades this specific tag across the whole internet, see the DMARC policy methodology.

How to Read a DMARC Record, Tag by Tag

Here is a fully enforcing record. Every tag in it does a job:

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

v=DMARC1 — the version tag. It must be exactly this, and it must be first. If it is missing or misspelled, the record is invalid and receivers ignore it entirely — which means a typo here silently downgrades you to no protection, even though a naive checker may still show the text of the record.

p= — the policy. This is the field that decides everything. It takes one of three values:

p=none — monitor only. The receiver is told to do nothing: deliver the forged mail as normal, just send a report. This is the setting that fools people. A checker shows a valid record, the owner assumes protection, and yet a domain at p=none can be spoofed exactly as freely as a domain with no DMARC at all. It is a keep-the-lights-on-and-watch policy, not a protective one.
p=quarantine — send failing mail to spam/junk. This is real, if partial, protection: forged mail is no longer delivered to the inbox.
p=reject — refuse failing mail outright. The forgery never arrives. This is the target state, and the only value defaults.exposed counts as fully enforcing.

sp= — the subdomain policy. If present, it overrides p= for subdomains. This is the most dangerous field a checker can gloss over: a domain can publish p=reject on the parent and sp=none underneath, leaving every subdomain — billing.yourbusiness.com, mail.yourbusiness.com — freely spoofable. Attackers know this. The census found 1.3 million domains carrying exactly this kind of subdomain back door; we measured it in DMARC subdomain policy: 1.3 million sp= back doors.

pct= — the percentage. This tag applies the policy to only a fraction of mail. pct=100 (or omitted, which defaults to 100) means the policy covers everything. Anything less — pct=10 — means 90% of forged mail sails through untouched while the record still reads as p=reject. It is the quietest way to look protected while being mostly exposed; 476,000 domains use it to water down enforcement, quantified in the pct tag report.

rua= and ruf= — the reporting addresses. rua receives aggregate reports (daily XML summaries of who is sending as you); ruf receives forensic/failure reports. These do not affect enforcement, but they are how you discover what is being sent in your name before you tighten the policy. Most domains that bother to publish DMARC never point these anywhere useful — we looked at who actually collects them in Who Reads the World’s DMARC Reports.

adkim= and aspf= — alignment modes. These control how strictly the authenticated domain must match the visible From domain: s (strict) or r (relaxed, the default). Alignment is the mechanism that makes DMARC meaningful — it is why a message can pass SPF or DKIM and still fail DMARC. Which brings us to the trap.

The Trap: “SPF Passes” Is Not “DMARC Passes”

The commonest misreading a DMARC checker exposes is the belief that a passing SPF or DKIM result means the domain is protected. It does not. DMARC requires that the domain which passes authentication is aligned with the domain in the From: header the recipient actually sees.

An attacker can send mail that passes SPF for their own throwaway domain while displaying your domain in the From field. SPF passes — for the wrong domain. DMARC is the only one of the three checks that closes this gap, because it insists the passing domain and the visible domain match. That is why a domain needs SPF or DKIM and an enforcing DMARC policy on top: the first two prove a domain authenticated; DMARC proves it was your domain.

This is also why a checker should never report SPF and DKIM in isolation. A domain can publish a perfect SPF record and still be spoofable, because SPF alone protects the invisible envelope, not the From address a human reads. We measured how many domains settle for the weaker SPF setting instead of enforcing alignment in SPF hard-fail vs soft-fail: why 82 million domains use the weaker setting. For the building blocks, see the methodology pages for SPF and DKIM.

What the Census Found: Published ≠ Enforcing

Run a checker across the whole internet and the gap between “has a record” and “is protected” becomes a chasm.

Of the 376,928,750 domains graded in the August 2026 census, only 34,983,618 — 9.3% — publish an enforcing DMARC policy (p=quarantine or p=reject). The remaining 90.7% (341,945,132) have no enforcing policy: most publish no DMARC record at all, and a large share of the rest publish p=none — a record that a basic checker reports as present while it does nothing to stop forgery.

Worse, 214,276,774 domains — 56.8% of the graded web — publish neither SPF nor DMARC, so there is not even a partial posture for a checker to read; the profile is measured in The Silent Domain. And of the domains that publish SPF and DKIM but stop short of an enforcing DMARC — the ones a single record edit would protect — there are roughly 87 million, quantified in DMARC Gap: 87 Million Domains One Record From Safety.

The lesson for anyone reading their own DMARC record: the green tick that says “record found” is the beginning of the check, not the end. The question is never do I have a record — it is does my record say reject, at pct=100, with sp=reject, and do my legitimate senders actually align. On the whole internet, fewer than one domain in ten can answer yes.

How to Fix a Weak DMARC Record

If your checker shows p=none, an over-broad sp=, or a pct below 100, the path to enforcement is well-trodden and low-risk when done in order:

Publish p=none with rua= pointing to a mailbox you monitor. If you have no record at all, this is step one — it breaks nothing and starts the flow of aggregate reports. This is the only stage at which p=none is the correct answer: as a temporary listening post, not a destination. See how reports are consumed in Who Reads the World’s DMARC Reports.
Read the reports and fix alignment. Over two to four weeks the rua reports reveal every service sending as you — your mail platform, your CRM, your invoicing tool, your newsletter provider. Bring each into SPF and DKIM so legitimate mail aligns.
Move to p=quarantine. Once legitimate senders align, tighten the policy. Forged mail now goes to spam. This alone removes most of your impersonation exposure.
Move to p=reject, pct=100, sp=reject. The destination. Forged mail is refused; subdomains inherit the protection; the policy covers all mail, not a sample.

Each step is a single DNS TXT edit. The work is not the editing — it is the listening in step 2, which is why starting today matters even if you cannot enforce today. The full grading logic for each stage is documented in the DMARC policy and DMARC reporting methodology.

What This Means

For business owners, a DMARC checker answers a question with a direct financial edge: can a criminal send email that looks exactly like it came from you? At a 9.3% enforcement rate across the internet, the default answer for most domains is yes — and the people defrauded are usually your own customers and suppliers, invoiced in your name. The fix is free and takes an afternoon of listening followed by a one-line DNS change. Not checking is a decision to stay spoofable.

For IT and security teams, the checker output is a to-do list, not a status light. “Record present” is not the finding; p=, sp=, pct=, and alignment are. A domain sitting at p=none is on the monitoring runway, not protected — and a stakeholder who has seen a green checker result may believe otherwise. Reading the record correctly, and moving it to p=reject at full percentage with a matching subdomain policy, is the whole job.

FAQ

What is a DMARC checker? A DMARC checker is a tool that looks up the DMARC record your domain publishes at _dmarc.yourdomain.com in public DNS, parses its tags, and reports what they mean — most importantly whether the policy is enforcing (p=quarantine or p=reject) or merely present (p=none or absent). Because DMARC records are public, a checker needs no access to your systems; it sees exactly what a receiving mail server, or an attacker assessing whether you can be spoofed, would see.

What does a good DMARC record look like? A fully enforcing record reads roughly v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; pct=100. The parts that matter for protection are p=reject (refuse forged mail), sp=reject (apply the same to subdomains), and pct=100 (cover all mail, not a sample). A record missing these — especially one at p=none — is published but not protective.

Why does my DMARC checker show a record but say I can still be spoofed? Almost always because your policy is p=none, which tells receiving servers to take no action on forged mail — only to report it. A record at p=none is valid and will show as “found,” but it provides no more spoofing protection than having no record at all. Moving to p=quarantine and then p=reject is what converts a monitored domain into a protected one. The August 2026 census found only 9.3% of domains reach an enforcing policy.

Is having a DMARC record enough to stop spoofing? No — three things must all be true. The policy must be enforcing (p=quarantine or p=reject); it must cover subdomains (sp=) and all mail (pct=100); and your legitimate senders must be aligned under SPF or DKIM so they are not caught by the policy. A record that is present but set to p=none, or that exempts subdomains, leaves the domain spoofable.

What is the difference between p=none, p=quarantine, and p=reject? p=none is monitor-only: forged mail is delivered as normal and merely reported. p=quarantine sends failing mail to the spam/junk folder. p=reject refuses failing mail outright so it never arrives. Only quarantine and reject stop forgery reaching a recipient; defaults.exposed counts only these two as enforcing. p=none is a useful first step while you confirm legitimate senders, not a finished state.

How do I check my domain’s DMARC for free? Enter your domain into a free scanner such as defaults.exposed. It reads your published SPF, DKIM, and DMARC records straight from public DNS and tells you not just whether a DMARC record exists but whether it enforces, whether subdomains are covered, and whether your setup can be spoofed. It takes about 30 seconds and needs no account.

Will publishing DMARC break my legitimate email? Not if you sequence it. Starting at p=none changes nothing about delivery while collecting the aggregate reports that show which of your services need aligning. Only after those reports confirm your legitimate senders pass do you tighten to quarantine and then reject. Domains that break mail almost always jumped straight to p=reject without the listening phase.

Data to cite

“Only 9.3% of graded domains — 34,983,618 of the 376,928,750 measured in the August 2026 census — publish an enforcing DMARC policy; the other 90.7% can be spoofed regardless of whether a checker shows a record.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“341,945,132 domains — 90.7% of the graded web — have no enforcing DMARC policy, meaning a DMARC checker will frequently report a record that does nothing to stop forgery.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“214,276,774 domains — 56.8% of the graded web — publish neither SPF nor DMARC, leaving no email-authentication posture at all for a checker to read.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Roughly 87 million domains publish SPF and DKIM but stop short of an enforcing DMARC policy — one DNS record from protection.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“A DMARC record can be present and valid yet non-protective: at p=none it monitors but does not stop forged mail, which is why enforcement rate, not record presence, is the meaningful measure.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

A DMARC checker is only useful if it answers the real question — not “do I have a record” but “can I be spoofed.” For 90.7% of domains the honest answer is yes, and most owners have never seen it stated plainly, because a record showed up green somewhere and the check stopped there.

Check your domain free at defaults.exposed — it reads your live SPF, DKIM, and DMARC records from public DNS and tells you instantly whether your policy actually enforces, whether your subdomains are covered, and whether your domain can be forged. Takes 30 seconds. No account needed. If you want the gaps closed properly — SPF, DKIM, and an enforcing DMARC policy done right — see how the fix works.

Read the flagship census report: The State of Domain Security 2026 →

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 376,928,750 domains graded from 432,127,908 scanned. All figures are counts of graded domains. References: RFC 7489 (DMARC), RFC 7208 (SPF), RFC 6376 (DKIM).

How to cite this report

Press / blog: defaults.exposed (2026). DMARC Checker: How to Read Your Record — and Why Only 9.3% of Domains Actually Enforce It. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/dmarc-checker-explained

Academic: defaults.exposed. (2026, August 21). DMARC Checker: How to Read Your Record. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/dmarc-checker-explained

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=376,928,750 graded domains)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,750 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →