What Is DMARC?

Q: What does DMARC stand for?

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. Each part maps to what it does: authentication because it builds on the SPF and DKIM checks that authenticate mail; reporting because it asks receivers to send aggregate reports of who is sending in your name; and conformance because it enforces conformance between the authenticated domain and the visible From: domain through a rule called alignment. Defined in RFC 7489, it is published as a single DNS record. Despite the reporting mechanism being one of its most useful features, most publishers never point it at a monitored mailbox — only 20.0% of domains (75,571,248) publish any DMARC record at all.

Published 2026-08-21

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 that forges your domain: monitor it, send it to spam, or reject it outright. It is the only one of the three email-authentication standards (SPF, DKIM, DMARC) that protects the domain a human actually reads in the From line, and it is the one most domains skip. The August 2026 defaults.exposed census graded 376,928,750 domains for email authentication and found that 90.7% — 341,945,132 — publish no enforcing DMARC policy, and only 20.0% (75,571,248) publish any DMARC record at all. That gap is why “what is DMARC” is no longer just a definition to look up. For nine domains in ten it is a live, spoofable-right-now exposure.

Most explanations of DMARC stop at the acronym and a sample record. The number that changes the question is the enforcement rate: publishing DMARC and being protected by it are not the same thing, and the whole internet demonstrates the difference at scale. 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 is DMARC and what does it stand for

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is an open standard, defined in RFC 7489, published as a single TXT record in your domain’s public DNS at a fixed location: the _dmarc subdomain (_dmarc.yourbusiness.com). Any mail server on earth can read it, which is the point — and also why an attacker can read it too.

The record does two jobs. First, it states a policy: the instruction a receiving mail server should follow when a message claiming to be from your domain fails authentication. Second, it requests reporting: it names an address that should receive daily aggregate summaries of who is sending mail in your name. The policy is the protection; the reporting is how you discover what to protect before you turn the policy up.

Crucially, DMARC does not authenticate mail by itself. It sits on top of two older standards — SPF and DKIM — and adds the one thing neither of them does alone: it ties the authenticated result to the domain the recipient actually sees. Without that link, a message can pass SPF or DKIM and still be a forgery. DMARC is what closes the gap. For how each control is graded across the whole namespace, see the DMARC policy methodology.

How DMARC works: aligning SPF and DKIM

To understand DMARC you have to understand what it fixes. SPF (RFC 7208) checks that a sending server is authorised to send for a domain. DKIM (RFC 6376) attaches a cryptographic signature proving a message was not altered in transit and came from a domain that holds the key. Both are useful. Both share the same blind spot.

The blind spot is alignment. SPF validates the hidden envelope sender — the Return-Path — not the From: address a person reads. DKIM validates whichever domain signed the message, which need not be your domain at all. An attacker can register a throwaway domain, publish perfectly valid SPF and DKIM for it, and send mail that passes both checks while your brand sits in the visible From line. SPF passes. DKIM passes. The recipient sees your name. Nothing has stopped the forgery.

DMARC’s rule is simple and is the entire reason it exists: the domain that passes SPF or DKIM must align with the domain in the visible From: header. If a message displays your domain but the passing authentication belongs to someone else’s domain, DMARC fails — and your policy decides what happens next. This 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.

Alignment also explains a common trap: a passing SPF result is not a passing DMARC result. Many domains publish SPF and assume they are covered, but SPF alone protects the envelope, not the readable address. We measured how many settle for the weaker SPF configuration 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.

p=none, p=quarantine, p=reject: the three policies explained

The heart of a DMARC record is one tag: p=, the policy. It takes exactly one of three values, and the difference between them is the difference between a decorative record and a protective one.

p=none — monitor only. The receiver is told to do nothing: deliver the forged mail as normal and merely send a report. This is the setting that fools people. A record exists, a checker shows it in green, 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, useful as a temporary listening post, useless as a destination.
p=quarantine — send failing mail to the spam or junk folder. This is real, if partial, protection: forged mail no longer lands in the inbox where it does its damage.
p=reject — refuse failing mail outright, so the forgery never arrives. This is the target state and the only value defaults.exposed counts as fully enforcing.

Only quarantine and reject stop forgery reaching a recipient. p=none is the enforcement rate’s dividing line, and the reason “has a DMARC record” is a misleading measure. A record can be present, valid, and completely non-protective — which is precisely what most published DMARC records are.

Two further tags decide whether even an enforcing policy actually holds. The subdomain tag sp= can quietly exempt every subdomain — a domain can publish p=reject on the parent and sp=none underneath, leaving billing.yourbusiness.com freely spoofable; we found 1.3 million such back doors in DMARC subdomain policy: 1.3 million sp= back doors. The pct= tag applies the policy to only a fraction of mail, so a record can read p=reject while 90% of forgeries pass through. For a full field-by-field walkthrough of a live record, see DMARC Checker: How to Read Your Record.

Why 90.7% of domains can still be spoofed

Look at DMARC across the whole internet and the definition turns into a measurement of exposure. 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 at all.

That 90.7% breaks into two failures. The larger group publishes no DMARC record whatsoever: only 20.0% of domains (75,571,248) publish any DMARC record at all, so four domains in five are not even at the starting line. The second group publishes a record that does nothing — of the domains that do publish DMARC, 53.6% (40,541,896) sit at p=none, monitoring but not enforcing. A record exists; the protection does not.

The result is that only 2.9% of domains (10,902,284) are fully protected across all three of SPF, DKIM and DMARC together — the complete posture that actually stops impersonation. And the exposure runs deeper still: 214,276,774 domains — 56.8% of the graded web — publish neither SPF nor DMARC, so there is not even a partial signal for a receiver to weigh, a profile measured in The Silent Domain.

This is what “can be spoofed” means in practice. A criminal who wants to send invoices, payment-redirect requests, or supplier notices in your name does not need to break anything. They check your DMARC — which, being public, takes seconds — and if it is absent or set to p=none, they simply send. The mail arrives in your customers’ inboxes displaying your exact domain. Exactly how that forgery is constructed is covered in Email Spoofing Explained: Why 90.7% of Domains Can Be Forged.

The encouraging part is how small the last step is for many domains. Millions already publish SPF and DKIM and stop just short of the enforcing DMARC policy that would protect them — roughly 87 million domains that are a single DNS record from safety, quantified in DMARC Gap: 87 Million Domains One Record From Safety.

Do you need DMARC? Google, Yahoo and NIS2 say yes

For years DMARC was optional in practice — recommended, rarely required. That changed. In February 2024, Google and Yahoo began requiring a valid DMARC record for bulk senders delivering to Gmail and Yahoo inboxes, and the requirement has only tightened since. If you send marketing mail, transactional receipts, or newsletters at any volume, “do you need DMARC” already has a commercial answer: without it, your legitimate mail is increasingly filtered or refused by the largest receivers. We tracked where adoption stood two years on in The Google and Yahoo Deadline: Two Years On.

Regulation is moving the same way. The EU’s NIS2 directive pushes essential and important entities toward demonstrable email-security controls, and sector frameworks increasingly name SPF, DKIM and DMARC explicitly as expected baseline hygiene. Cyber-insurance questionnaires now routinely ask whether an enforcing DMARC policy is in place. The direction of travel is one-way: DMARC is shifting from a security nicety to a deliverability and compliance requirement.

There is also the plain risk argument, which needs no regulator. Business email compromise and invoice fraud overwhelmingly rely on impersonation, and an enforcing DMARC policy removes the easiest impersonation vector — the exact-domain forgery — from an attacker’s toolkit. It does not solve look-alike domains or compromised accounts, but it closes the one that costs nothing to close. Against an internet where only 9.3% of domains enforce, having DMARC at p=reject is a genuine differentiator, not a formality. Enforcement is also the gate to benefits that build on top of it — most visibly BIMI, the brand logo in the inbox, which only displays once your DMARC policy enforces.

How to check your DMARC status in 30 seconds

You do not need special access to check any domain’s DMARC, including your own — the record is public. The fastest route is a free scanner that reads it for you and interprets the tags that matter.

Check your domain free at defaults.exposed — enter your domain and it reads your live SPF, DKIM and DMARC records straight from public DNS, then tells you not merely whether a DMARC record exists but whether it actually enforces, whether your subdomains are covered by sp=, and whether your domain can currently be forged. It takes about 30 seconds and needs no account. If the result puts you in the 90.7% with no enforcing policy — or shows a record stuck at p=none — you have found the single highest-leverage fix available to a domain owner.

If you want the gaps closed properly rather than just diagnosed — SPF, DKIM, and an enforcing DMARC policy sequenced so you never break legitimate mail — see how the fix works. The route to enforcement is well-trodden: publish p=none with a monitored rua= address, read the aggregate reports for two to four weeks to bring every legitimate sender into alignment, then tighten to p=quarantine and finally p=reject at pct=100 with a matching sp=reject. Each step is one TXT edit; the work is the listening, which is why starting today matters even if you cannot enforce today. How those reports are consumed is covered in Who Reads the World’s DMARC Reports and the DMARC reporting methodology.

What this means

For business owners, DMARC answers a question with a direct financial edge: can a criminal send email that looks exactly like it came from you? Across the internet the default answer is yes — only 9.3% of domains enforce — and the people defrauded are usually your own customers and suppliers, invoiced in your name. The fix costs nothing in licensing and takes an afternoon of listening followed by a one-line DNS change. It also protects your deliverability, since the largest inbox providers now expect a valid record. Not publishing an enforcing DMARC policy is a decision to stay spoofable and, increasingly, to have your own mail filtered.

For IT and security teams, DMARC is a posture to be measured, not a box to be ticked. “Record present” is not the finding; p=, sp=, pct=, and sender alignment are. A domain sitting at p=none is on the monitoring runway, not protected — and 53.6% of all DMARC publishers are parked exactly there. The job is to read the aggregate reports, align every legitimate sender under SPF or DKIM, and move the policy to p=reject at full percentage with a subdomain policy to match. Done in order, it breaks nothing; skipped, it leaves the organisation in the spoofable 90.7%.

FAQ

What is DMARC? DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is a public DNS TXT record, published at _dmarc.yourdomain.com, that tells receiving mail servers what to do with email that forges your domain: monitor it, quarantine it, or reject it. It builds on SPF and DKIM by requiring that the authenticated domain aligns with the visible From: address, closing the gap those two standards leave open. It is the control that actually stops exact-domain impersonation — yet the August 2026 census found only 9.3% of 376,928,750 graded domains publish an enforcing DMARC policy. You can check any domain’s DMARC free at defaults.exposed.

What does DMARC stand for? DMARC stands for Domain-based Message Authentication, Reporting and Conformance. Each part maps to what it does: authentication because it builds on the SPF and DKIM checks that authenticate mail; reporting because it asks receivers to send aggregate reports of who is sending in your name; and conformance because it enforces conformance between the authenticated domain and the visible From: domain through a rule called alignment. Defined in RFC 7489, it is published as a single DNS record. Despite the reporting mechanism being one of its most useful features, most publishers never point it at a monitored mailbox — only 20.0% of domains (75,571,248) publish any DMARC record at all.

How does DMARC work? DMARC works by adding an alignment rule on top of SPF and DKIM. When a message arrives, the receiver checks whether it passes SPF or DKIM, then checks whether the passing domain matches the domain shown in the From: header. If it matches, DMARC passes. If a message displays your domain but the authentication belongs to someone else’s, DMARC fails, and your published policy (p=none, p=quarantine, or p=reject) decides the outcome. This alignment step is why a message can pass SPF yet fail DMARC, and why SPF alone leaves a domain spoofable. Across the census, 90.7% of domains (341,945,132) publish no enforcing policy to act on that failure.

Do I need DMARC? If you send email from your domain — marketing, invoices, receipts, or newsletters — yes. Since February 2024, Google and Yahoo have required a valid DMARC record for bulk senders, so without one your legitimate mail is increasingly filtered by the largest inbox providers. Regulatory frameworks such as the EU’s NIS2 and most cyber-insurance questionnaires now name DMARC as expected baseline hygiene. Even a domain that never sends mail benefits, because an enforcing policy stops criminals forging it. With only 2.9% of domains (10,902,284) fully protected across SPF, DKIM and DMARC, an enforcing policy is a real differentiator, not a formality.

Is DMARC required? It depends who is asking, but the practical answer is increasingly yes. DMARC is not mandated by a single global law, but the major mailbox providers effectively require it for bulk sending, and regulations like NIS2 push essential and important entities toward demonstrable email-authentication controls. In compliance and insurance contexts an enforcing DMARC policy is now a routine expectation rather than a bonus. Technically nothing forces you to publish one — which is exactly why 90.7% of domains have no enforcing policy — but the cost of skipping it is rising: filtered deliverability, failed audits, and an open door to impersonation of your brand.

Data to cite

“90.7% of domains — 341,945,132 of the 376,928,750 measured in the August 2026 census — have no enforcing DMARC policy and can be spoofed regardless of any record they publish.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Only 9.3% of domains (34,983,618) publish an enforcing DMARC record set to p=quarantine or p=reject.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Just 20.0% of domains (75,571,248) publish any DMARC record at all, meaning four domains in five are not even at the starting line.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Of the domains that publish DMARC, 53.6% (40,541,896) sit at p=none — monitoring only, providing no protection against forgery.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Only 2.9% of domains (10,902,284) are fully protected across SPF, DKIM and DMARC together.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

Knowing what DMARC is only helps once you know what your own domain publishes — and for 90.7% of domains the honest answer is “nothing that enforces.” Most owners have never seen it stated plainly, because the record is invisible until someone reads it.

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 in the right order — 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). What Is DMARC? Why 90.7% of Domains Can Still Be Spoofed. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/what-is-dmarc

Academic: defaults.exposed. (2026, August 21). What Is DMARC? Why 90.7% of Domains Can Still Be Spoofed. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/what-is-dmarc

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 →