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.

Phishing is still the number-one action variety in confirmed breaches, appearing in roughly 36% of data breaches analyzed by the Verizon 2024 Data Breach Investigations Report. DMARC is the only open standard that lets you close the door on attackers spoofing your exact domain; yet according to Valimail's 2024 Email Fraud Landscape report, only about 33% of domains with a DMARC record have an enforcement policy (p=quarantine or p=reject). The rest are publishing monitoring-only records and hoping for the best.

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. That's it. No magic, no third-party dependency.

The standard was published in 2015 as RFC 7489 by a working group that included PayPal, Google, Microsoft, and Bank of America (companies that were, unsurprisingly, getting impersonated in phishing attacks constantly). DMARC.org maintains the public spec and a deployment guide; bookmark it if you run email infrastructure.

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.

How does DMARC work?

A DMARC check happens in three steps at the receiving server. First, the receiver evaluates SPF and DKIM as normal. Second, it checks identifier alignment: does the domain that passed SPF or DKIM match the domain in the visible From header? Third, if neither is aligned, the receiver consults your DMARC policy and either delivers, quarantines, or rejects the message.

Alignment is the subtle part; it's also where most DMARC deployments go wrong the first time. SPF authenticates the Return-Path (envelope sender); DKIM authenticates the d= tag in the signature. Neither of those is what your recipient actually sees. DMARC says: for a message to be trusted, at least one of those authenticated domains has to line up with the From: header your user reads in Gmail. That alignment can be strict (exact match) or relaxed (same organizational domain).

You control alignment mode with 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. Most senders should stay on relaxed; strict is useful if you're a bank and you want to lock down every subdomain.

What does a DMARC record look 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, what's going on:

• 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 based on your answers, and the DNS record glossary entry explains how to publish it at your registrar.

The three DMARC 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).

Policy	What receivers do	Who should use it
p=none	Deliver the message normally; just send you aggregate reports. No enforcement.	Everyone on day one. You're in monitor-only mode; use this to find out who's sending as you before you start blocking.
p=quarantine	Route failing messages to spam/junk. Recipient can still fish them out.	Senders with a clean report history who want softer enforcement, or who still have one legitimate source they haven't fully authenticated.
p=reject	Refuse the message at SMTP. It bounces; the recipient never sees anything.	Anyone serious about anti-spoofing, and anyone sending >5,000 messages/day to Gmail or Yahoo per their 2024 rules.

[ORIGINAL DATA: percentage of Mailneo customer domains currently at p=reject vs p=quarantine vs p=none, pulled from our DMARC monitoring feature]

How should you deploy DMARC?

Never jump straight to p=reject. I've 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 forgot about wasn't in their SPF record. Staged rollout exists for a reason.

The canonical rollout looks like this:

1. Publish p=none for at least 2–4 weeks. Collect aggregate reports. Find every IP and domain sending as you.
2. Fix authentication for each legitimate source. Add them to SPF. Set up DKIM signing. Re-check alignment.
3. Move to p=quarantine; pct=10. Watch reports for a week. If nothing legitimate is being quarantined, bump to pct=25, then pct=50, then pct=100.
4. Move to p=reject; pct=10. Same ramp. You're now rejecting a small fraction of failing mail. Watch for complaints.
5. Full p=reject. You're done. Spoofers get bounced; your domain is locked.

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. pct=10 at p=reject means 10% get rejected, 90% get quarantined. It gives you a pressure valve.

[MY EXPERIENCE: describe moving a Mailneo customer from p=none to p=reject, how long the monitoring period lasted, and what unexpected legitimate source we caught in the aggregate reports]

DMARC reports: rua vs ruf, and what they actually contain

DMARC's feedback loop is where it earns its keep. Once you publish rua=mailto:you@example.com, mailbox providers start sending you daily XML files listing every IP that sent mail claiming to be from your domain, whether it passed or failed SPF/DKIM, and whether it was aligned.

Two report types:

• Aggregate reports (the rua tag) are daily XML summaries; one per reporting provider (Google, Yahoo, Microsoft, Mail.ru, etc.). These are what you'll actually use. They tell you which IPs are sending and whether they're authenticated.
• Forensic reports (the ruf tag) are per-message redacted copies of failing messages. Much rarer. Most providers don't send them for privacy reasons; Google stopped years ago. Publishing a ruf= tag doesn't hurt, but don't expect a flood of forensic data.

Raw XML is unreadable; nobody is going to sit there parsing envelope elements by hand. Tools like Dmarcian, Postmark's DMARC Digests, Valimail, or EasyDMARC turn the XML into human dashboards. Pick one and forward your rua= address to it.

[SCREENSHOT: parsed DMARC aggregate report inside a reporting tool like Dmarcian or Postmark DMARC Digests, showing authenticated vs failing sources]

Why Google and Yahoo's 2024 bulk sender rules made DMARC mandatory

In February 2024, Google and Yahoo rolled out their joint bulk-sender requirements (covered on the Google Security Blog and Yahoo's postmaster announcement). The short version: if you send more than 5,000 messages per day to Gmail or Yahoo users, you now need a DMARC record (at minimum p=none), one-click unsubscribe, and spam complaint rates under 0.3%.

That rule changed the math overnight. Before February 2024, DMARC was a best practice. After February 2024, it was a gate; bulk senders without a DMARC record started getting their mail rate-limited or rejected. Google reported that in the first six months after enforcement kicked in, spam in inboxes dropped 65% for users seeing messages from authenticated senders (per the Gmail security team).

If you're reading this and you haven't published a DMARC record, the 5,000/day threshold is easy to underestimate. A modest B2B newsletter with 20,000 subscribers sending weekly hits it on send day. A SaaS with 50,000 users sending password-reset emails can blow through it on a normal Tuesday. Check your volume to Gmail and Yahoo specifically; those are the domains that enforce.

Key takeaways

• DMARC is a DNS-based policy (RFC 7489, 2015) that tells receivers what to do when SPF or DKIM alignment fails; it doesn't authenticate anything on its own.
• Only about 33% of domains with a DMARC record are actually enforcing (Valimail, 2024); the rest are monitoring-only.
• Google and Yahoo's February 2024 bulk sender rules require DMARC for any sender doing more than 5,000 messages/day to their users.
• The three policies are p=none (monitor), p=quarantine (route to spam), and p=reject (bounce); always stage rollout from none to reject over weeks, not hours.
• Aggregate reports (rua=) are what you'll actually use; forensic reports (ruf=) are mostly historical at this point.

Frequently asked questions

Do I need SPF and DKIM before I can publish DMARC?

You need at least one of them. DMARC checks whether SPF or DKIM is aligned with the From header; if neither protocol is set up, every message will fail DMARC. In practice, set up both. SPF is 15 minutes of work; DKIM depends on your ESP but is usually just publishing a provided public key.

What's the difference between DMARC alignment and SPF passing?

SPF can pass while DMARC still fails. SPF authenticates the envelope sender (the Return-Path), but your recipient sees the From: header. If those two domains don't match organizationally, SPF passes but DMARC alignment fails. That's why forwarded mail and many third-party senders break DMARC; they pass SPF on their own domain, not yours.

Will publishing p=reject block legitimate mail?

Only if you have legitimate senders that aren't authenticated. That's the entire point of the monitoring period at p=none. If you've watched aggregate reports for 4+ weeks, fixed every legitimate source, and ramped through p=quarantine with pct= values, reaching p=reject is usually a non-event. The damage happens when teams skip the ramp.

How is DMARC different from BIMI?

DMARC is authentication policy; BIMI is a logo standard that sits on top of DMARC. 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.

Is DMARC enough to stop all phishing?

No. DMARC stops exact-domain spoofing (mail that claims to be from @yourdomain.com). It does nothing against lookalike domains (yourd0main.com, your-domain.com) or display-name spoofing. For those, you need user training, anti-phishing gateways, and domain monitoring. DMARC closes one specific attack vector, and it closes it cleanly.

Related resources

• DMARC generator. Build a valid DMARC record in under a minute.
• DMARC glossary entry. Tag-by-tag reference.
• Email authentication overview. How SPF, DKIM, and DMARC fit together.
• SPF vs DKIM vs DMARC. What each one actually does.
• How to set up SPF, DKIM, and DMARC. The full walkthrough.
• Email deliverability guide. The cluster pillar.