What Is DMARC? How to Protect Your Domain from Spoofing

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS-published policy that tells receiving mail servers what to do when a message claiming to come from your domain fails SPF or DKIM checks. It requires at least one of those two protocols to be aligned with the visible From address, and it's defined in RFC 7489.

It is also the only open standard that closes the door on someone spoofing your exact domain. Publishing the record is the easy part; the reason most domains never get further than monitoring mode is that enforcement requires you to find and fix every legitimate sender you forgot about, and that work is unglamorous.

What is DMARC?

DMARC is a TXT record at _dmarc.yourdomain.com that does three things. It tells receivers to check whether SPF and DKIM are aligned with the From header, it publishes a policy for what should happen when alignment fails, and it asks receivers to send back reports about what they're seeing. No magic, no third-party dependency.

The spec was developed by a coalition of large senders and mailbox providers, PayPal, Google, Microsoft, and Bank of America among them, before being published as an RFC in 2015. DMARC.org maintains the public deployment guide.

A few things DMARC is not. It's not an encryption protocol (that's TLS). It doesn't sign the message body (that's DKIM's job). It doesn't verify the path the message took (that's SPF). DMARC sits on top of those two, acts as the referee, and publishes the rulebook; the SPF vs DKIM vs DMARC breakdown covers the division of labor if the three still blur together.

A check runs in three steps at the receiver. It evaluates SPF and DKIM as normal, then checks identifier alignment (does the domain that passed match the domain in the visible From header?), then consults your policy if neither aligned.

Alignment is where most first deployments go wrong. SPF authenticates the Return-Path; DKIM authenticates the d= tag in the signature. Neither is what your recipient sees. DMARC's demand is that at least one of the authenticated domains lines up with the From: header your user reads in Gmail. That can be strict (exact match) or relaxed (same organizational domain), controlled by two tags:

• aspf=s or aspf=r: strict vs relaxed SPF alignment (default is relaxed)
• adkim=s or adkim=r: strict vs relaxed DKIM alignment (default is relaxed)

In relaxed mode, mail.mailneo.co aligns with mailneo.co. In strict mode it doesn't. Stay on relaxed unless you're a bank locking down every subdomain.

What a DMARC record looks like

A DMARC record is a plain TXT record published at _dmarc.yourdomain.com. Here's a realistic one for a sender who's past the monitoring phase but not fully at reject yet:

_dmarc.mailneo.co.  IN  TXT  "v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@mailneo.co; ruf=mailto:dmarc-forensics@mailneo.co; sp=reject; adkim=r; aspf=r; fo=1"

Tag by tag:

• v=DMARC1: version; always this exact string
• p=quarantine: the policy for the main domain (send failing mail to spam)
• pct=50: apply the policy to 50% of failing messages; the other 50% are treated as p=none
• rua=mailto:...: aggregate report address (daily XML rollups)
• ruf=mailto:...: forensic report address (per-message failure reports)
• sp=reject: policy for subdomains, stricter than the main domain here
• adkim=r / aspf=r: relaxed alignment for both
• fo=1: generate a forensic report if any authentication mechanism fails

You don't have to memorize every tag. Our free DMARC generator will build a valid record from your answers, the DMARC glossary entry is a tag-by-tag reference, and the DNS record entry explains how to publish it at your registrar.

The three policies: none, quarantine, reject

The p= tag has exactly three possible values. Each tells receivers to do something different when a message fails alignment, and each has a different appropriate audience. Pick wrong and you'll either publish a record that does nothing (p=none forever) or nuke your own legitimate mail (p=reject on day one).

Rolling out DMARC without breaking your own mail

Never jump straight to p=reject. I watched one team do that (not a Mailneo customer, a friend's startup) and they wiped out their own billing emails for two days because a transactional provider they'd forgotten about wasn't in their SPF record. Staged rollout exists for a reason.

The canonical ramp runs like this. Publish p=none for at least two to four weeks and collect aggregate reports until you can name every IP and domain sending as you. Fix authentication for each legitimate source: add it to SPF, set up DKIM signing, re-check alignment. Move to p=quarantine; pct=10 and watch for a week; if nothing legitimate is getting quarantined, step through pct=25, pct=50, pct=100. Then repeat the same ramp at p=reject.

The pct= tag is what makes this safe. Receivers apply the policy to a random subset of failing messages and fall back to the next-weakest policy for the rest, so pct=10 at p=reject means 10% get rejected and 90% get quarantined. It's a pressure valve, and skipping it is the single most common way teams turn a security improvement into an outage.

The reports are the instrument that makes the ramp possible. Once you publish rua=mailto:you@example.com, mailbox providers start sending daily XML files listing every IP that sent mail claiming to be from your domain, whether it passed or failed SPF and DKIM, and whether it was aligned. Those aggregate reports are the ones you'll actually use.

Forensic reports (the ruf tag) are per-message redacted copies of failing messages, and they're much rarer now; most providers stopped sending them for privacy reasons years ago. Publishing a ruf= tag doesn't hurt, but don't build a process around data that may never arrive.

Raw XML is unreadable and nobody is going to parse envelope elements by hand, so forward your rua= address to a reporting tool that renders it as a dashboard. Pair that with Google Postmaster Tools if Gmail is a meaningful share of your volume, since it shows you the reputation side of the same story.

Why Google and Yahoo made DMARC table stakes

In February 2024, Google and Yahoo rolled out joint bulk-sender requirements (Google's sender guidelines, Yahoo's postmaster announcement). If you send more than 5,000 messages a day to Gmail or Yahoo users, you need a DMARC record at minimum p=none, one-click unsubscribe, and a spam complaint rate under 0.3%.

That changed the math overnight. DMARC went from best practice to gate, and complaint rate went from a soft target to a hard operating constraint; our spam complaint rate calculator will tell you how many complaints a given send can absorb before you cross the line.

The 5,000/day threshold is easier to hit than teams expect. A B2B newsletter with 20,000 subscribers clears it on send day; a SaaS with 50,000 users sending password resets can blow through it on a normal Tuesday. Check your volume to Gmail and Yahoo specifically, and read the full email deliverability guide if authentication is only one of several things you're behind on.

What DMARC doesn't cover

Two questions come up once a domain reaches enforcement, and both are about the edges of what the standard promises.

How is DMARC different from BIMI?

DMARC is authentication policy; BIMI is a logo standard that sits on top of it. You can't publish BIMI without being at p=quarantine or p=reject first. BIMI shows your brand logo in Gmail, Yahoo, and Apple Mail; DMARC is the foundation that makes BIMI possible, which is why the logo is usually the reward at the end of an enforcement project rather than a separate one.

Is DMARC enough to stop all phishing?

No. DMARC stops exact-domain spoofing, meaning mail that claims to be from @yourdomain.com. It does nothing against lookalike domains (yourd0main.com, your-domain.com) or display-name spoofing, where the attacker writes your company name in the From display and sends from a Gmail address. For those you need user training, an anti-phishing gateway, and domain monitoring. DMARC closes one specific attack vector, and it closes it cleanly; treating it as a complete anti-phishing program is how security teams end up surprised.