DMARC Policy Enforcement Explained
How DMARC ties SPF and DKIM together into an enforceable policy against spoofed and phishing email.
Core Concept
DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM by requiring alignment with the visible From address and defining what receivers should do when authentication fails.
It closes the gap that SPF and DKIM leave open individually: neither guarantees the address a user actually sees matches the address that was actually authenticated.
How DMARC Alignment Works
DMARC passes when at least one of SPF or DKIM aligns with the domain in the visible From header.
- SPF alignment — envelope sender domain matches the From domain
- DKIM alignment — signing domain matches the From domain
- DMARC passes if either mechanism aligns successfully
Either Path Works
A message only needs to pass one aligned mechanism — SPF or DKIM — not both, to satisfy DMARC.
Policy Enforcement Levels
The DMARC record's policy tag tells receiving servers how to handle messages that fail authentication.
- p=none — monitor only, take no action on failures
- p=quarantine — route failing messages to spam/junk
- p=reject — block failing messages outright
Aggregate and Forensic Reporting
DMARC includes a reporting mechanism that gives domain owners visibility into how their domain's email is being authenticated across the internet.
Aggregate reports, sent by participating receivers, show which sending sources are passing or failing DMARC — invaluable for discovering unauthorized or misconfigured senders.
Visibility Before Enforcement
Running DMARC at p=none while collecting aggregate reports is the standard way to discover every legitimate sending source before enforcing a stricter policy.
A Practical Rollout Path
Moving to full DMARC enforcement is typically a staged process rather than a single change.
- Start at p=none and review aggregate reports for several weeks
- Align every legitimate sending source with proper SPF/DKIM
- Gradually move to p=quarantine, then p=reject
Real-World Implementation
DMARC enforcement has become a standard requirement across the email ecosystem.
- Major mailbox providers requiring DMARC for bulk senders
- Financial and government domains typically enforcing p=reject
- Brand protection teams monitoring aggregate reports for abuse
A domain with SPF, DKIM, and a fully enforced DMARC policy is substantially harder to spoof convincingly than one relying on any single mechanism alone.
Common Mistakes to Avoid
A few common mistakes derail DMARC rollouts or reduce their effectiveness.
- Jumping straight to p=reject without a monitoring period to catch unaligned senders.
- Ignoring aggregate reports that would reveal legitimate senders needing alignment fixes.
- Assuming a message passing SPF automatically means it passes DMARC alignment too.
- Failing to align every legitimate sending source before enforcing a strict policy.
- Overlooking DMARC reports as an ongoing monitoring tool after initial rollout.
- Overlooking the pct tag, which allows gradual policy rollout rather than an all-or-nothing switch.
- Assuming DMARC aggregate reports are simple to interpret without any tooling.
- Failing to identify every legitimate sending source before moving to enforcement.
- Overlooking subdomain-specific DMARC policies, which can differ from the organizational domain's policy.
- Assuming DMARC forensic reports are as widely supported as aggregate reports.
- Failing to review DMARC reports on a consistent, regular cadence during the monitoring phase.
- Overlooking that some DMARC reporting tools have a delay before newly configured records show data.
Best Practices Checklist
These practices lead to a safe, effective DMARC rollout and ongoing enforcement.
- Start at p=none and review aggregate reports for several weeks before enforcing.
- Align every legitimate sending source with proper SPF or DKIM before tightening the policy.
- Move gradually from p=none to p=quarantine, then p=reject.
- Continue monitoring aggregate reports even after reaching full enforcement.
- Investigate any unexpected DMARC failures promptly to catch misconfigurations or abuse.
- Use the pct tag to gradually ramp up enforcement rather than switching abruptly.
- Use a dedicated DMARC reporting tool to make aggregate report data actionable.
- Thoroughly identify every legitimate sending source before committing to full enforcement.
- Consider subdomain-specific DMARC policies where subdomain risk profiles genuinely differ.
- Rely primarily on aggregate reports, since forensic report support is less consistent across providers.
- Establish a consistent, regular cadence for reviewing DMARC reports during the monitoring phase.
- Allow a reasonable ramp-up period before expecting comprehensive data from a newly configured DMARC reporting tool.
Frequently Asked Questions
Frequently asked questions about DMARC.
What does DMARC add on top of SPF and DKIM?
It requires alignment between SPF or DKIM results and the visible From address, and defines what receivers should do when authentication fails.
Does a message need to pass both SPF and DKIM for DMARC?
No — DMARC passes if at least one of SPF or DKIM aligns with the domain in the visible From header.
What's the difference between p=none, p=quarantine, and p=reject?
p=none only monitors, p=quarantine routes failing messages to spam, and p=reject blocks failing messages outright.
Why shouldn't organizations jump straight to p=reject?
Doing so without a monitoring period risks blocking legitimate mail from services that haven't been properly aligned yet.
What are DMARC aggregate reports used for?
They give domain owners visibility into which sending sources are passing or failing DMARC, helping discover unauthorized or misconfigured senders.
What does the pct tag do in a DMARC record?
It specifies what percentage of failing messages the policy should apply to, enabling a gradual rollout rather than immediate full enforcement.
Are DMARC aggregate reports easy to read manually?
Not particularly — they're XML-formatted and often high-volume, which is why dedicated reporting tools are commonly used to interpret them.
Why is identifying every sending source so important before enforcement?
Because any legitimate source missed during this process risks having its mail blocked or quarantined once strict enforcement begins.
Can subdomains have a different DMARC policy than the main domain?
Yes — a subdomain-specific policy tag (sp=) allows different enforcement levels tailored to that subdomain's actual risk profile.
Are DMARC forensic reports as widely supported as aggregate reports?
No — forensic report support and volume have declined over time due to privacy concerns, making aggregate reports the more reliable data source.
Does DMARC reporting data appear immediately after setup?
Not immediately — there's typically a ramp-up period before comprehensive aggregate report data becomes available for review.
Check DMARC Policy
Run an email security scan to see a domain's DMARC policy and enforcement level.
Launch Tool →