DMARC. From Monitor-Only to Reject

What DMARC is, in one paragraph

DMARC (Domain-based Message Authentication, Reporting & Conformance) sits on top of SPF and DKIM. It does three things they don't: (1) it declares a policy for what receivers should do with mail that fails authentication, (2) it requires alignment, the authenticated domain must match the visible From: domain, and (3) it gives you aggregate reports. XML feedback from every major receiver about every sender claiming to be you.

Without DMARC, attackers can spoof your From: ceo@yourcompany.com trivially. SPF and DKIM check different things; nothing ties them to the visible header until DMARC does.

Why every domain that sends email needs DMARC

Since February 2024, Gmail and Yahoo require DMARC (with any policy, including p=none) for any sender doing more than 5,000 messages per day. Microsoft 365 / Outlook followed. The bulk-sender bar effectively says: no DMARC, no inbox.

And the reporting is honestly the bigger deal than the policy. Once rua is pointed at an aggregator, you suddenly see every service sending as your domain, including the ones you forgot you signed up for in 2019.

Alignment is the trickiest concept

Here's where most people get confused. A message has multiple "from" identifiers:

• Envelope-from (Return-Path): what SMTP saw. SPF checks against this.
• DKIM d= tag: what the DKIM signature claims.
• Visible From: header: what your user sees in their inbox.

DMARC says: at least one of {SPF passing} or {DKIM passing} must also use a domain that aligns with the visible From:.

Example: your message has From: alice@example.com. It's sent via SendGrid, which uses Return-Path: bounces@sendgrid.net. SPF passes (SendGrid's IP is in sendgrid.net's SPF) but doesn't align. If DKIM signs with d=sendgrid.net, DKIM also fails alignment. DMARC fails. To fix, either configure a custom Return-Path on your sending domain, or have SendGrid sign with d=example.com (most providers offer this, usually called "domain authentication").

Anatomy of a DMARC record

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com;
    ruf=mailto:dmarc-forensic@example.com; pct=100; adkim=s; aspf=s; fo=1

• v=DMARC1, required version tag.
• p=, policy for the root domain. One of none, quarantine, reject.
• sp=, same, but for subdomains.
• rua=, where to send daily aggregate XML reports (mailto:).
• ruf=, where to send per-failure forensic reports. Most receivers don't send these for privacy reasons. Optional.
• pct=, what percentage of mail to apply the policy to. Use as a ramp dial during rollout.
• adkim=, aspf=, alignment mode. r (relaxed) accepts subdomains as aligned. s (strict) requires exact match. Start with relaxed.
• fo=, failure reporting options. fo=1 means "send a forensic report if any check fails."

The three-phase deployment

Phase 1. Monitor with p=none (weeks 1-4)

Publish:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100

This applies no enforcement, mail keeps flowing. But you immediately start getting daily aggregate reports from Gmail, Outlook, Yahoo, etc. Plug the rua address into a free DMARC report parser (Postmark DMARC Digest is the easiest).

You're looking for: every IP and ESP that's sending as your domain, what their SPF and DKIM status is, and which ones aren't aligning. Make a list of every legitimate sender that isn't passing. Fix them one by one, usually by enabling "domain authentication" or "custom DKIM" in the service.

Phase 2. Soft enforcement with p=quarantine (weeks 4-8)

Once your reports show ≥98% authentication for legitimate senders, flip the policy:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com

Note pct=10, only 10% of failing mail will be quarantined; the other 90% gets the p=none treatment. Ramp the percentage up over a week or two: 10 → 25 → 50 → 100.

Watch your reports daily during this phase. If aligned percentages drop, pause the ramp.

Phase 3. Full enforcement with p=reject (week 8+)

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r

Reject is the goal. Anything claiming to be you that can't prove it gets bounced. This is what shuts down spoofing.

Pro move: keep adkim=r and aspf=r (relaxed) for at least a year. Strict alignment is rarely necessary and breaks edge cases.

Aggregate vs forensic reports

Aggregate (rua): daily XML summary. One row per IP+SPF result+DKIM result. Anonymized, no message content, no recipient info. This is what you actually want.

Forensic (ruf): per-failure copy of the failing message (often redacted). Most receivers (Google, Yahoo) refuse to send these for privacy reasons. Microsoft and a few others still do. Marginally useful, often missing.

Common mistakes

• Skipping phase 1. Going straight to p=reject without reports. Real mail dies silently for weeks.
• Pointing rua at a personal email. You'll get 50+ XML attachments per day. Use an aggregator address.
• Forgetting subdomain policy. If you publish p=reject without sp=, subdomains inherit reject. Often fine, sometimes catastrophic, e.g. for transactional subdomains that weren't part of your audit.
• Setting strict alignment (adkim=s) early. Almost always breaks something. Relaxed is correct for the first year.
• Ignoring reports. The policy is half the value. Without reading reports you'll never catch the slow drift as new services are added without authentication.

Monitoring DMARC long-term

The two things that go wrong in stable DMARC deployments:

• Someone publishes a second _dmarc record (during a DNS migration or a misguided "consolidation"). DMARC requires exactly one, multiple records make the entire policy invalid.
• A new sending service gets added, isn't authenticated, and suddenly your reports show 20% of mail failing. Without continuous monitoring you only notice when customers complain about missed mail.

DomainsDoc watches your DMARC record (and SPF, and DKIM, and the rest) hourly. When the record changes, when policy weakens, when alignment configuration shifts, you get an alert before it becomes a deliverability incident.