Updated 8 hours ago
Here's a disturbing fact about email authentication: a message can pass SPF. It can pass DKIM. And it can still be lying about who it's from.
SPF validates the envelope sender—the return address used during transmission. DKIM validates a cryptographic signature. But neither requires those checks to match the From address that users actually see. An attacker can send email that passes every authentication check while displaying "From: your-bank.com" in the recipient's inbox.
DMARC closes this gap.
What DMARC Actually Does
DMARC adds three things that SPF and DKIM lack:
Alignment. Either SPF or DKIM must pass, AND the authenticated domain must match the visible From header. No more hiding behind valid signatures for the wrong domain.
Policy. Domain owners tell the world what to do with messages that fail: monitor them, quarantine them, or reject them outright.
Visibility. Receiving servers send reports back to domain owners showing every message claiming to be from their domain—who sent it, where it came from, whether it passed or failed.
SPF and DKIM answer "is this real?" DMARC answers "is this really from who it says it's from?"—and tells the world what to do when the answer is no.
Alignment: The Core Concept
A message passes DMARC when authentication and identity agree:
SPF alignment: The envelope sender domain matches the From header domain, and SPF passes.
DKIM alignment: A valid DKIM signature's domain (d=) matches the From header domain, and DKIM passes.
Only one needs to succeed. But that one must align.
Relaxed vs. strict alignment:
- Relaxed (default): Organizational domains match. mail.example.com aligns with example.com.
- Strict: Exact match required. mail.example.com does NOT align with example.com.
Most deployments use relaxed alignment because it accommodates subdomains without sacrificing security.
The DMARC Record
DMARC policies live in DNS as TXT records at _dmarc.yourdomain.com:
v=DMARC1 — Version identifier (required, must be first)
p= — Policy for failures:
none— Monitor only. Collect data, don't affect delivery.quarantine— Treat failures as suspicious. Usually means spam folder.reject— Don't deliver failures at all.
rua= — Where to send aggregate reports (daily summaries of authentication results)
ruf= — Where to send forensic reports (detailed failure information, though many receivers don't send these)
sp= — Policy for subdomains (inherits from p= if not specified)
pct= — Percentage of failing messages to apply policy to (useful for gradual rollout)
adkim= — DKIM alignment mode (r=relaxed, s=strict)
aspf= — SPF alignment mode (r=relaxed, s=strict)
A Complete Example
This says: reject failures for the main domain, quarantine failures for subdomains, apply to all messages, use relaxed alignment, and send reports to these addresses.
The Deployment Path
DMARC deployment is a journey, not an event. Rush to p=reject and you'll break legitimate email.
Phase 1: Monitor
Start here. Collect 2-4 weeks of data. See who's sending email as your domain—legitimate services you forgot about, marketing platforms, support systems. And attackers.
Phase 2: Analyze
Aggregate reports arrive daily as XML files showing:
- Source IP addresses sending as your domain
- Volume from each source
- SPF and DKIM pass/fail rates
- How messages were handled
Raw XML is tedious. Use analysis tools (dmarcian, Valimail, Postmark DMARC Digests, EasyDMARC) to visualize patterns and identify gaps.
Phase 3: Quarantine
Start at 10%. Watch for delivery problems. Increase gradually: 25%, 50%, 100%.
Phase 4: Reject
Once you're confident all legitimate mail passes, enforce the strongest policy. Now spoofed messages claiming to be from your domain get rejected worldwide.
Third-Party Senders
Every service sending email on your behalf must pass DMARC. Marketing platforms, support systems, transactional email services—they all need to authenticate properly.
Options:
-
DKIM delegation: The service signs with your domain (d=yourdomain.com), and you publish their DKIM key in your DNS.
-
Dedicated subdomain: Give the service a subdomain like newsletter.example.com, which they authenticate independently.
-
Send as their domain: The service sends from their own domain, not yours. Simplest, but changes how recipients see the sender.
Subdomains
Without an sp= tag, subdomains inherit the main domain's policy. You can override this:
Or publish separate records for specific subdomains:
Subdomain-specific records take precedence over the parent.
The Limitations
Forwarding breaks things. When email is forwarded, SPF fails (different sending server) and DKIM may fail (if the message is modified). ARC (Authenticated Received Chain) is an emerging solution, but adoption is incomplete.
Mailing lists are complicated. Lists that add footers or modify subjects break DKIM signatures. Some lists implement ARC; many don't.
Adoption varies. Major providers (Gmail, Outlook, Yahoo) honor DMARC policies. Smaller servers may not. Your protection depends on receivers implementing the standard.
Reports aren't universal. Not all receivers send aggregate reports, and many refuse to send forensic reports due to privacy concerns.
Frequently Asked Questions About DMARC
Was this page helpful?