Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Enforce domain-aligned email authentication with a DMARC policy that instructs receivers how to handle unauthenticated mail and generates aggregate feedback reports.

What it is

DMARC (RFC 7489) binds SPF and DKIM authentication directly to the domain name displayed to end users in the visible From: header field (RFC 5322). It provides domain owners with two essential capabilities:

Policy Enforcement: Instructs receiving mail servers what action to take (none, quarantine, reject) when incoming messages fail both SPF alignment and DKIM alignment.
Reporting Telemetry: Instructs receiving mailbox providers to send daily XML aggregate reports (rua) and failure reports (ruf) detailing every IP address attempting to send email as your domain.

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:[email protected]; aspf=r; adkim=r;"

Why it matters

Mandatory for Inbox Placement: Major email service providers (Google, Yahoo, Microsoft, Apple) strictly require a valid DMARC record for domain reputation scoring. Senders without DMARC face aggressive spam filtering and outright message rejection.
Eliminates Direct Domain Spoofing: Without a DMARC policy of p=reject or p=quarantine, attackers can easily forge your exact domain in the visible From: header. DMARC at enforcement (p=reject) guarantees that unauthenticated spoofed messages are blocked before reaching users’ inboxes.
Complete Sending Visibility: DMARC aggregate reports (rua) provide comprehensive visibility across all legitimate and shadow sending services (transactional gateways, marketing tools, support desks, ERP platforms) as well as active phishing campaigns targeting your brand.

How to implement

1. Understand DMARC Identifier Alignment. For DMARC to pass, at least one underlying authentication mechanism (SPF or DKIM) must achieve Identifier Alignment with the RFC 5322 From: header domain:

Mechanism	Alignment Rule	Relaxed Mode (`r`)	Strict Mode (`s`)
SPF Alignment	RFC 5321 `MAIL FROM` domain matches RFC 5322 `From:` domain	Subdomains match organizational domain (`mail.example.com` matches `example.com`)	Exact FQDN match only (`example.com` matches `example.com`)
DKIM Alignment	DKIM `d=` signing domain matches RFC 5322 `From:` domain	Subdomains match organizational domain (`d=mail.example.com` matches `example.com`)	Exact FQDN match only (`d=example.com` matches `example.com`)

2. Follow a staged deployment rollout. Never publish p=reject on day one without monitoring. Follow the standard staged rollout lifecycle:

Phase 1: Discovery & Monitoring (p=none) Publish a monitoring-only policy to collect aggregate data via rua without impacting email deliverability:
```
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
```
Phase 2: Gradual Quarantine Rollout (p=quarantine) After aligning all legitimate sending sources, transition unauthenticated mail into spam/junk folders using percentage ramping:
```
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"
```
Increase pct= from 25 to 50, 75, and 100 as reporting data confirms zero false positives.

Phase 3: Full Rejection & Enforcement (p=reject) Block all unauthorized mail at the gateway level:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:[email protected]"

3. Configure Subdomain Policies (sp=). If you send email exclusively from subdomains (e.g., news.example.com), protect your apex domain with sp=reject to block attackers from spoofing root or nonexistent subdomains.

Common mistakes

Leaving DMARC indefinitely at p=none: A policy of p=none is a diagnostic tool, not an enforcement mechanism. It provides zero protection against domain spoofing.
Syntax Errors in Tag Delimiters: Omitting semicolons between tags, using invalid case, or placing the record at example.com instead of _dmarc.example.com.
Failing to Authorize External Reporting Domains: If reporting addresses (rua=mailto:[email protected]) use a different domain than the sender domain, the recipient domain must publish an external authorization record at example.com._report._dmarc.dmarc-collector.com per RFC 7489 §7.1.
Relying Solely on SPF for DMARC: Forwarded emails break SPF IP validation. If DKIM is not configured and aligned, legitimate forwarded messages will fail DMARC and be rejected.

Verification

1. Query the live DMARC record using dig:

dig +short TXT _dmarc.example.com

2. Verify DMARC evaluation in delivered headers:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=202608;
       spf=pass (google.com: domain of [email protected] designates 198.51.100.10 as permitted sender);
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

3. Analyze daily RUA XML reports: Ensure that aggregate report processors show 100% compliant pass rates across all production sending streams before advancing policy levels.