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

Email was designed in an era of trust. Nothing in the original protocol stops a sender from writing any address in the From: field — including yours. That single gap is why phishing, business email compromise, and brand impersonation still work decades later. DMARC is the standard that closes it. This guide explains what DMARC is, how it works, and how to use it to actually protect your domain — not just monitor it forever.

The problem DMARC solves

When a mail server receives a message, the address a human sees — the From: header — is just text the sender chose. An attacker can put billing@your-company.com there and send a convincing invoice from their own server. Without authentication, the receiving server has no reliable way to know the message didn't come from you. This is the exact mechanism behind most wire-transfer fraud: an email that looks like it came from a manager or a supplier, with nothing technical to separate it from the real thing.

SPF and DKIM were the first answers. SPF lets you publish which servers may send for your domain; DKIM attaches a cryptographic signature receivers can verify. Both are necessary — but neither, on its own, protects the address the user actually reads. SPF checks the hidden envelope sender; DKIM proves a signature exists but doesn't require it to match your visible domain. An attacker can pass SPF and DKIM for their own domain while still displaying yours in the From: field.

What DMARC actually is

DMARC (Domain-based Message Authentication, Reporting and Conformance), originally defined in RFC 7489 and modernized in 2026 by DMARCbis (RFC 9989), is a short policy you publish in your DNS. It does three things:

1. Ties SPF and DKIM to the visible domain. A message passes DMARC only if it is validated by SPF or DKIM and the authenticated domain matches the domain in the From: header. That matching rule is called alignment, and it is the whole point of DMARC.
2. Tells receivers what to do with mail that fails. You choose a policy: do nothing, send to spam, or reject outright.
3. Sends you reports. Receivers email you daily summaries of every source sending in your name — the data you need to fix things safely.

Read the full mechanics on our DMARC reference page.

The key idea: alignment

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

What a DMARC record looks like

A DMARC record is a single DNS TXT entry published at _dmarc.your-domain.com:

_dmarc.your-domain.com.  IN TXT
  "v=DMARC1; p=none; rua=mailto:reports@your-domain.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 your subdomains (usually set to match p).

The three policies

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

• p=none — observe only. Nothing changes for delivery; you just collect reports. This is where you start, 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 your name simply does not get delivered.

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

How DMARC reporting works

Because you can't enforce a policy without knowing who legitimately sends for you, DMARC includes a feedback channel. Receivers like Google, Microsoft and Yahoo send aggregate reports (XML) to your rua= address every day, summarizing how mail claiming to be from you performed: which IPs sent it, how much, and whether it passed SPF, DKIM and alignment. These reports are the map you use to find and fix every legitimate sender before you tighten the policy. 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. Reassure yourself right away: this is not a breaking change. Records still start with v=DMARC1, and you don't have to change anything 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"). To ramp up, you now lean 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: your current record stays valid, but it's a good moment to drop a now-useless pct and set np=reject on your 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. Tighten the policy before each of those is authenticated and aligned, and you risk sending your 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. You inventory every sender from the aggregate reports, bring each into SPF/DKIM alignment, then ramp the policy through quarantine to reject while watching the reports stay clean. We lay out the full sequence in how to get to p=reject without breaking email.

Check where your domain stands

You don't have to guess. Run a free, instant check of your domain's DMARC, SPF and DKIM posture with our domain analyzer — it shows your current policy, alignment, and a clear grade. You can also browse the DMARC Observatory to see 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, your domain must have exactly one _dmarc TXT record. A second one makes the policy ambiguous, and receivers may ignore both — leaving you unprotected while you believe you're covered. Merge everything into a single record.
• Jumping straight to p=reject. Enforcing before every legitimate sender is aligned is the fastest way to send your own invoices, receipts and password resets into the void. Ramp through none and quarantine first, watching the reports at each step.
• Ignoring the subdomain policy. The sp tag controls subdomains, and with DMARCbis the np tag now covers non-existent subdomains too. If you enforce on your root domain but leave sp loose, attackers simply spoof news.your-domain.com or mail.your-domain.com instead. Set sp (and np) 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 how exposed you are.
• Publishing without a rua address. Without aggregate reports you're flying blind: you can never safely tighten the policy because you can't see who legitimately sends for you. Always include a rua.
• Forgetting parked domains. Domains you own but don't send from are favorite spoofing targets precisely because nobody watches them. Publish a strict p=reject record 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 gives you instead of guesswork.

Let Thomas take it from here

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

Analyze your domain for free → or create an account and let Thomas do the heavy lifting.