What is DMARC, and how does it stop email spoofing?

The key idea: alignment

Alignment is what makes DMARC stronger than SPF and DKIM combined. An attacker who controls evil.com illustrates it. They can configure perfect SPF and DKIM for evil.com — so their mail passes those checks. But when they forge From: billing@example-company.com, DMARC asks a harder question: does the authenticated domain match the From: domain? For the attacker it does not (evil.com ≠ example-company.com), so DMARC fails and the published policy applies. That is the protection SPF and DKIM alone never delivered. For the deeper version, our guide on how SPF, DKIM and DMARC work together takes it further.

What a DMARC record looks like

A DMARC record is a single DNS TXT entry published at _dmarc.example.com:

_dmarc.example.com.  IN TXT
  "v=DMARC1; p=none; rua=mailto:reports@example.com; adkim=s; aspf=s"

The tags that matter most:

• p — the policy: none, quarantine, or reject.
• rua — the address that receives daily aggregate reports (the feedback loop).
• adkim / aspf — how strict alignment must be: s (strict) or r (relaxed).
• sp — the policy for subdomains (usually set to match p).

The three policies

DMARC enforcement is a ladder, and the rung selected changes what receivers do with unauthenticated mail:

• p=none — observe only. Nothing changes for delivery; the reports simply accumulate. This is the starting rung, and unfortunately where most domains stay forever.
• p=quarantine — unauthenticated mail goes to the spam folder. A real, if soft, defense.
• p=reject — unauthenticated mail is refused at the door. This is the goal: spoofed mail in the domain's name simply does not get delivered.

Only p=reject actually stops spoofing. Monitoring at p=none protects no one — it merely measures the exposure. Our DMARC Observatory bears this out: across most sectors we analyze, the majority of domains are stuck at p=none — visible, but unprotected.

What DMARC guarantees — and what it doesn't

Seen from the executive floor, DMARC boils down to one precise promise: once a domain reaches p=reject, nobody can deliver an email displaying that exact domain in the From: field without authorization. That is a strong guarantee — it protects customers, suppliers and employees from fake invoices and fraudulent payment requests sent "in the company's name" — but it has a perimeter, and knowing that perimeter is what keeps the guarantee from turning into a false sense of security.

DMARC does not block lookalike domains: an attacker who registers example-company-billing.com, or swaps an "l" for a "1", sails past the check entirely, because they are spoofing a domain they genuinely own. It does not stop display-name deception — "Chief Executive" in front of an ordinary webmail address — nor mail sent from a compromised legitimate mailbox, which authenticates flawlessly because it really does come from the company's own infrastructure. And it does not filter inbound phishing arriving from other people's domains: it is their DMARC that protects the recipient's inbox, just as the recipient's protects theirs. We map these neighboring techniques in our overview of email spoofing. DMARC is an indispensable building block, not a total shield: it locks down one exact identity, and leaves the remaining vectors to awareness training and inbound filtering.

How DMARC reporting works

Because no policy can be enforced without knowing who legitimately sends for the domain, DMARC includes a feedback channel. Receivers like Google, Microsoft and Yahoo send aggregate reports (XML) to the rua= address every day, summarizing how mail claiming to come from the domain performed: which IPs sent it, how much, and whether it passed SPF, DKIM and alignment. These reports are the map for finding and fixing every legitimate sender before the policy tightens. We cover them in detail in reading DMARC aggregate reports.

DMARC is evolving: what DMARCbis changes (2026)

In May 2026 the IETF published DMARCbis — the modernized version of the standard, split across three RFCs: 9989 (the protocol itself), 9990 (aggregate reporting) and 9991 (failure reporting). Together they replace the original RFC 7489 and move DMARC onto the standards track (Proposed Standard) for the first time. One reassurance up front: this is not a breaking change. Records still start with v=DMARC1, and nothing has to change for an existing setup to stay protected. Here's what actually moves:

• The pct tag is gone. Percentage-based rollout proved unreliable and has been removed, replaced by a binary testing mode: the t tag (t=y signals "I'm experimenting, don't enforce strictly yet"). Ramping up now leans on subdomain policies and report observation rather than a percentage.
• Two new subdomain tags. np sets the policy for non-existent subdomains — a classic spoofing target, precisely because nobody watches them — and psd marks public suffix domains (registries).
• The DNS Tree Walk replaces the Public Suffix List. To determine the "organizational domain," DMARCbis queries DNS step by step (up to 8 lookups) instead of depending on an externally maintained list — more robust and more predictable.

Everything else — p, sp, rua, ruf, adkim, aspf, fo — keeps exactly the same meaning. In practice: an existing record stays valid, but it's a good moment to drop a now-useless pct and set np=reject on the phantom subdomains.

Why most domains get stuck at p=none

Publishing p=none is easy; moving past it is where teams stall. The reason is fear: enterprises send mail from far more places than they realize — the marketing platform, the CRM, the billing system, the help desk, that one app a team set up two years ago. Tightening the policy before each of those is authenticated and aligned risks routing the company's own legitimate mail to spam. So the record sits at p=none, monitoring forever, while spoofers keep operating freely.

The way out is not bravery; it's method. Every sender gets inventoried from the aggregate reports and brought into SPF/DKIM alignment one by one, then the policy ramps through quarantine to reject while the reports stay clean. We lay out the full sequence in how to get to p=reject without breaking email.

DMARC in a compliance program

For anyone wearing the CISO or DPO hat, DMARC has a second life beyond the purely technical one: it shows up in nearly every file that has to be defended. Cyber-insurance questionnaires and vendor security assessments increasingly ask, in so many words, which DMARC policy a company publishes — and a p=none does not read well there. The major consumer mailbox providers now require DMARC from bulk senders, which turns a former recommendation into a hard deliverability precondition. Several governments have made it mandatory for their own agencies — a clear sign the standard left "nice to have" territory long ago. And within an ISO 27001-style security management system, an enforced DMARC policy concretely documents a control against impersonation fraud, while the aggregate reports provide a verifiable, continuous record that the control actually operates over time — exactly the kind of evidence an auditor likes to see.

The compliance angle has one great virtue: it attaches a deadline to a project that engineering priorities alone tend to let drift indefinitely. A good way to put the urgency on paper is to check, in black and white, whether a domain can be spoofed today — and attach the result to the file.

Where the domain stands today

Guesswork is unnecessary. A free, instant check of a domain's DMARC, SPF and DKIM posture runs through our domain analyzer — it surfaces the current policy, the alignment, and a clear grade. The DMARC Observatory shows how entire sectors compare.

Common DMARC mistakes to avoid

Even teams that publish DMARC often trip on the same details, and each one quietly undermines the protection:

• Two DMARC records. Like SPF, a domain must have exactly one _dmarc TXT record. A second one makes the policy ambiguous, and receivers may ignore both — leaving the domain unprotected behind a belief that it is covered. Everything merges into a single record.
• Jumping straight to p=reject. Enforcing before every legitimate sender is aligned is the fastest way to send a company's own invoices, receipts and password resets into the void. The ramp goes through none and quarantine first, with the reports watched at each step.
• Ignoring the subdomain policy. The sp tag controls subdomains, and with DMARCbis the np tag now covers non-existent subdomains too. Enforcement on the root domain with a loose sp simply moves the attacker to news.example.com or mail.example.com instead. sp (and np) are set deliberately, usually to match p.
• Treating p=none as the finish line. Monitoring is the start, not the destination. A record that never moves past none protects no one — it merely documents the exposure.
• Publishing without a rua address. Without aggregate reports the whole thing flies blind: the policy can never tighten safely, because nothing shows who legitimately sends for the domain. A rua always belongs in the record.
• Forgetting parked domains. Domains a company owns but never sends from are favorite spoofing targets precisely because nobody watches them. A strict p=reject record belongs on every parked domain.

None of these are hard to fix; they're mostly a matter of patience and good data — exactly what a guided, report-driven process supplies in place of guesswork.

Thomas takes it from here

Reaching p=reject is a project, but it doesn't have to be an in-house one. Thomas, the virtual CISO, names every sending source from the reports, generates the exact DNS records to paste (DMARCbis tags included), scores readiness on rolling data, and calls the precise moment it's safe to tighten — all the way from p=none to p=reject, without blocking a single legitimate email.

Free DMARC analysis of a domain or an account, and Thomas does the heavy lifting.