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.

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, defined in RFC 7489) 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; pct=100"

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).
• pct — the percentage of failing mail the policy applies to, useful for a gradual rollout.

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.

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.

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. 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 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 Marc take it from here

Reaching p=reject is a project, but it doesn't have to be your project. Marc, the DMARC copilot, names every sending source from your reports, generates the exact DNS records to paste, 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 Marc do the heavy lifting.