Most domain owners who’ve set up SPF and DKIM believe they’re protected from email spoofing. They’re not — not fully. SPF and DKIM check the envelope and the signature. DMARC is the policy that protects the From: address users actually see. Without it, phishing attacks using your domain’s name can sail through SPF and DKIM checks.
The Problem DMARC Solves
Email authentication has a gap. SPF checks the MAIL FROM address (invisible to users). DKIM signs the message with a key tied to the d= domain (also invisible). Neither is required to match the From: header your recipients see.
From: ceo@your-company.com ← what user sees (unprotected by SPF/DKIM alone)
Return-Path: evil@spam.net ← where SPF checks (can pass)
DKIM-Signature: d=spam.net ← where DKIM checks (can pass)This email passes SPF and DKIM while completely forging your executive’s address. DMARC closes this gap with identifier alignment.
DMARC Identifier Alignment
DMARC requires that either:
- The SPF envelope sender domain aligns with the
From:domain, OR - The DKIM
d=domain aligns with theFrom:domain
From: user@example.com
SPF alignment: MAIL FROM domain = example.com → aligned ✓
DKIM alignment: DKIM d=example.com → aligned ✓
Relaxed: mail.example.com aligns with example.com ✓
Strict: only exact domain match: example.com = example.com ✓If neither SPF nor DKIM passes with alignment, DMARC applies the policy from your DNS record.
The DMARC DNS Record
DMARC is published as a TXT record at _dmarc.yourdomain.com:
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100; adkim=r; aspf=r"Tag Reference
| Tag | Values | Meaning |
|---|---|---|
v=DMARC1 | — | Version (required, must be first) |
p= | none, quarantine, reject | Policy for failing messages |
rua= | mailto:addr | Aggregate report destination |
ruf= | mailto:addr | Forensic report destination |
pct= | 1–100 | Percentage of messages policy applies to (default 100) |
adkim= | r (relaxed), s (strict) | DKIM alignment mode |
aspf= | r (relaxed), s (strict) | SPF alignment mode |
sp= | none, quarantine, reject | Subdomain policy (inherits p= if omitted) |
fo= | 0, 1, d, s | Forensic report options |
Policy Levels
p=none → Monitor. Deliver all email. Send reports. (start here)
p=quarantine → Suspect. Route failing email to spam/junk.
p=reject → Block. Reject failing email at server. (end goal)Deployment Roadmap
Phase 1: Monitor (Week 1–4)
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Collect reports. Parse them (see tools below). Identify every sending source. Verify each one passes SPF or DKIM alignment.
Phase 2: Quarantine with Low Percentage (Week 4–8)
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com"Apply policy to 10% of failing messages. Monitor for legitimate email being quarantined. Increase pct gradually.
Phase 3: Full Quarantine (Week 8–12)
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com"Phase 4: Reject (Week 12+)
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"Never skip the monitoring phase. Jumping straight to p=reject blocks legitimate email from services you forgot to configure.
Reading DMARC Reports
Aggregate reports (rua) are XML files emailed daily. Raw XML is unreadable. Use:
| Tool | Type | Cost |
|---|---|---|
| Google Postmaster Tools | Web dashboard | Free |
| Dmarcian | SaaS parser | Free tier + paid |
| Valimail Monitor | SaaS | Free tier |
| Postmark DMARC | Simple summary emails | Free |
| parsedmarc | Self-hosted | Open source |
A typical report entry in readable form:
Source IP: 74.125.130.27 (Google)
Count: 1,523 messages
SPF result: pass (aligned)
DKIM result: pass (aligned)
Disposition: noneLook for sources where disposition=quarantine or disposition=reject on messages that should be legitimate — those are services you need to fix before moving to a stricter policy.
DMARC for Subdomains
The sp= tag controls subdomain policy. If omitted, subdomains inherit p=:
; Protect both root domain and all subdomains
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"
; Stricter subdomains while root is still in quarantine
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc@example.com"Subdomains can also have their own _dmarc.subdomain.example.com records that override the parent policy.
Non-Sending Domains
Domains that never send email are prime spoofing targets. Protect them with a strict DMARC policy:
; For domains that send no email
_dmarc.parked-domain.com. TXT "v=DMARC1; p=reject"
parked-domain.com. TXT "v=spf1 -all"Pair with SPF -all and no MX records for maximum protection.
DMARC and Google/Yahoo Sender Requirements
Since February 2024, Google and Yahoo require bulk senders (>5,000 emails/day to Gmail) to have:
- Valid SPF record
- Valid DKIM record
- DMARC record with at least
p=none
Meeting only p=none satisfies their requirement, but p=reject is the actual protection goal.
Common Mistakes
| Mistake | Problem | Fix |
|---|---|---|
Jumping to p=reject | Blocks legitimate email | Monitor with p=none first |
No rua= address | No visibility into sources | Always set rua= |
| Strict alignment before all sources pass | Legitimate email fails | Use relaxed alignment while onboarding |
| DMARC on root but not subdomains | Subdomains still spoofable | Add sp=reject or per-subdomain records |
| Forgetting forwarding lists | Forwarded email fails | Use ARC, configure list servers to re-sign |
| Ignoring reports | Gaps in coverage go undetected | Review aggregate reports weekly during rollout |
Verification
# Check DMARC record
dig TXT _dmarc.example.com +short
# Send test email and check headers (Gmail → View original)
# Look for:
# Authentication-Results: dmarc=pass action=none header.from=example.comSPF + DKIM + DMARC together form a complete email authentication system. Each layer is necessary; none is sufficient alone.
Common Questions
What is the difference between DMARC p=none, p=quarantine, and p=reject?
p=none means monitor only — emails that fail DMARC are delivered normally, but reports are sent to your rua address. p=quarantine means failing emails are sent to spam/junk. p=reject means failing emails are rejected outright — not delivered at all. Most organizations start at p=none, analyze reports for weeks, then graduate to p=quarantine and finally p=reject.
What is DMARC alignment?
DMARC alignment requires that the domain in the From: header matches either the SPF envelope sender domain or the DKIM signing domain. Strict alignment requires an exact match. Relaxed alignment (default) allows organizational domain matching — subdomain.example.com aligns with example.com. A message passes DMARC if it passes SPF alignment OR DKIM alignment (not necessarily both).
Will DMARC break my email if I set p=reject too quickly?
Yes, if you haven't fully inventoried all your sending sources. If a legitimate service sends email on your behalf and doesn't pass SPF or DKIM alignment, p=reject will block those emails. This is why the p=none monitoring phase is critical — use rua reports to identify all sending sources and ensure each passes authentication before moving to reject.
What is a DMARC aggregate report (rua)?
DMARC aggregate reports are XML files sent daily by receiving mail servers (Gmail, Outlook, Yahoo, etc.) to your rua email address. They contain: sending IP addresses, message counts, SPF/DKIM pass/fail for each source, disposition applied. You need a report parser (Google Postmaster Tools, Postmark DMARC, Dmarcian, Valimail) to make them readable.
Do I need DMARC if I already have SPF and DKIM?
Yes. SPF checks the envelope sender. DKIM signs the message. Neither by itself protects the From: header — the address users actually see. DMARC is what ties SPF/DKIM results to the From: header and specifies what happens when they don't match. Without DMARC, a spoofed From: address can pass SPF/DKIM checks on the envelope while the visible sender address is forged.