What is DMARC?

In a nutshell

DMARC stands for Domain-based Message Authentication, Reporting and Conformance and is a DNS-based protocol that builds on SPF and DKIM. While SPF and DKIM only make it verifiable whether an email comes from an authorized sender, DMARC tells the receiving mail server what to do with forged messages: let them through, move them to spam, or reject them outright. On top of that, DMARC sends you daily reports showing which IPs are sending mail in your name — both legitimate and illegitimate.

Why do I need DMARC?

Without DMARC, any server out there can send mail under your domain name — for instance, phishing messages that look like they come from your accounting department. Recipients have almost no way to spot the fraud. DMARC closes that gap: emails that fail SPF and DKIM are dropped or flagged as spam. At the same time, the aggregate reports tell you whether your domain is being abused as a spoofing target.

Major providers like Google and Yahoo have required a DMARC configuration since 2024 for bulk senders (more than 5,000 messages per day) — otherwise the messages land straight in the spam folder.

Anatomy of a DMARC record

DMARC is published as a TXT record on the subdomain _dmarc.example.com. A complete entry looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; sp=quarantine; pct=100; adkim=s; aspf=s

The most important tags:

• v=DMARC1 — version identifier, always first.
• p=... — policy for the main domain. Three values are possible: none (report only), quarantine (move to spam), or reject (refuse).
• rua=mailto:... — address for the daily aggregate reports (XML files).
• ruf=mailto:... — forensic reports for individual failed messages.
• sp=... — policy for subdomains; useful when no mail is sent from subdomains.
• pct=... — percentage of messages the policy is applied to (migration: pct=10, 50, 100).
• adkim=s/r, aspf=s/r — strict (s) or relaxed (r) alignment check.

Rolling out DMARC step by step

The recommendation is not to jump straight to p=reject. Otherwise you risk blocking legitimate mail (e.g. from newsletter platforms, CRM, or accounting tools) that you haven't yet covered in SPF/DKIM. Instead, go in phases:

1. Phase 1: Observe. Set p=none with active rua reports. Collect 2–4 weeks of data and identify every legitimate sender.
2. Phase 2: Catch up SPF and DKIM. Add all the IP ranges and mail providers you discovered to your SPF record, and make sure every sender produces DKIM signatures.
3. Phase 3: Test run. Switch to p=quarantine; pct=10. Watch for two weeks.
4. Phase 4: Full rollout. Bump pct to 50, then 100. After another two weeks, move to p=reject.

Common pitfalls

• Multiple DMARC records: Only one DMARC record per domain. Several TXT entries with v=DMARC1 render DMARC ineffective.
• Jumping straight to p=reject: Spend a few weeks at p=none first, otherwise you'll kill legitimate mail.
• Wrong rua address: If reports go to a different domain, that domain needs a DMARC authorization record (example.com._report._dmarc.other.com).
• SPF DNS lookup limit: SPF may cause at most 10 DNS lookups — if it exceeds that, SPF fails and so does DMARC.