You've set up SPF. You've configured DKIM. Your emails are authenticated, and you feel good about your security posture. Then you discover that someone has been sending thousands of phishing emails from your domain for months, and none of your authentication mattered because you never told anyone what to do about failures.
This is the gap DMARC fills. SPF and DKIM are verification mechanisms—they can tell a receiving server whether an email is legitimate. But they don't specify what should happen when verification fails. Should the email be delivered anyway? Quarantined? Rejected outright? Without explicit instructions, most servers default to delivering the email, maybe with a warning flag that users ignore.
DMARC—Domain-based Message Authentication, Reporting, and Conformance—is the policy layer. It tells the world: 'Here's what I want you to do with emails that fail authentication. And by the way, send me reports about what you're seeing.'
The three DMARC policies
DMARC policies are specified with the 'p=' tag in your DMARC record. There are three options, and choosing the right one depends on where you are in your email authentication journey.
'p=none' is monitoring mode. It tells receiving servers: 'Don't do anything special with failures, but send me reports about what you see.' This is where everyone should start. You get visibility into your email ecosystem without risking legitimate email being blocked.
'p=quarantine' is the middle ground. It tells servers: 'If authentication fails, treat the email as suspicious.' In practice, this usually means the email goes to spam or junk folders. Users can still find it if they look, but it's not in their inbox.
'p=reject' is full enforcement. It tells servers: 'If authentication fails, don't deliver the email at all.' This is the goal—complete protection against domain spoofing. But it's also the most dangerous if your authentication isn't properly configured, because legitimate emails will be blocked.
The journey from 'none' to 'reject' typically takes weeks or months. You start with monitoring, analyze the reports to find all legitimate email sources, ensure they're properly authenticated, then gradually increase enforcement. Rushing to 'reject' before you're ready is a great way to break your email.
Understanding DMARC alignment
Here's where DMARC gets subtle, and where a lot of people get confused. DMARC doesn't just check whether SPF and DKIM pass—it checks whether they 'align' with the visible From address.
Consider this scenario: An attacker sends an email with a From address of [email protected]. They send it through their own server, which has valid SPF for attackerdomain.com. The email passes SPF—but for the wrong domain. Without alignment checking, this attack would succeed.
DMARC alignment requires that the domain authenticated by SPF or DKIM matches the domain in the From header. 'Matches' can mean either an exact match (strict alignment) or a match at the organizational domain level (relaxed alignment).
With relaxed alignment (the default), mail.yourcompany.com aligns with yourcompany.com. With strict alignment, they don't—only exact matches count. Most organizations use relaxed alignment because it's more practical, especially if you use subdomains for different email streams.
For DMARC to pass, either SPF must pass AND align, or DKIM must pass AND align (or both). This is why having both SPF and DKIM configured is important—if one fails (say, SPF fails due to forwarding), the other can still provide a passing result.
DMARC reports: Your window into email abuse
The reporting feature of DMARC is arguably as valuable as the policy enforcement. When you publish a DMARC record with a 'rua=' tag, receiving servers send you aggregate reports about emails they've seen claiming to be from your domain.
These reports are XML files that arrive daily (usually). They contain data about email volume, authentication results, and sending sources. For each source IP, you'll see how many emails were sent, whether SPF and DKIM passed, and what policy was applied.
The first time you look at DMARC reports, you'll probably be surprised. You'll see email coming from sources you forgot about—that old marketing tool you stopped using but never decommissioned, the invoicing system that sends receipts, the monitoring service that sends alerts. You'll also likely see unauthorized sources: spammers, phishers, or just misconfigured systems that somehow ended up sending as your domain.
Raw DMARC reports are hard to read. Most organizations use a DMARC analysis service (there are free and paid options) that aggregates reports, visualizes the data, and alerts you to problems. This is strongly recommended—trying to parse XML reports manually doesn't scale.
There's also 'ruf=' for forensic reports, which send detailed information about individual failing emails. These are more privacy-sensitive (they can include email content) and many receivers don't send them, but they can be useful for investigating specific incidents.
The path to enforcement
Moving from p=none to p=reject is a process, not an event. Here's how it typically works in practice.
You start by publishing a DMARC record with p=none and a rua address for reports. You don't need perfect SPF and DKIM at this point—you're just gathering data. Wait at least two weeks, preferably a month, to collect enough reports to see the full picture.
Analyze the reports. Identify every legitimate source of email for your domain. For each one, verify that SPF and DKIM are properly configured. This is often where you discover forgotten services or misconfigurations. Fix them.
Once your legitimate sources are consistently passing authentication, move to p=quarantine. But don't go all-in immediately—use the 'pct=' tag to apply the policy to only a percentage of failing emails. Start with pct=10, meaning 10% of failures get quarantined while 90% are still delivered normally.
Monitor the reports. If you see legitimate email being quarantined, investigate and fix. If everything looks good, gradually increase the percentage: 25%, 50%, 75%, 100%.
Once you're at p=quarantine with pct=100 and everything is stable, repeat the process for p=reject. Again, start with a low percentage and gradually increase. When you reach p=reject with pct=100 (or no pct tag, which defaults to 100%), you have full DMARC enforcement.
This process typically takes 2-6 months depending on the complexity of your email ecosystem. Rushing it risks blocking legitimate email. Being too slow leaves you vulnerable to spoofing. Find the right pace for your organization.
Common DMARC mistakes
The most common mistake is jumping straight to p=reject without monitoring first. You will break something. Maybe it's the HR system that sends offer letters, or the finance tool that sends invoices, or the legacy application that nobody remembers exists. Start with p=none, always.
Another frequent error is setting up DMARC but never looking at the reports. The reports are the whole point of the monitoring phase. If you're not analyzing them, you're flying blind. Set up a DMARC analysis tool and actually review the data.
Forgetting about subdomains catches many organizations. By default, DMARC policy applies only to the exact domain, not subdomains. If you want to protect marketing.yourcompany.com, you need either a separate DMARC record for that subdomain or a 'sp=' tag in your main record specifying the subdomain policy.
Misconfiguring third-party services is endemic. When you add a new email service, you need to update both SPF (to authorize their servers) and ensure they're signing with DKIM on your domain (not their default domain). Many services require explicit configuration to use your domain's DKIM.
Finally, treating DMARC as 'set and forget' leads to problems. Your email ecosystem changes over time. New services get added, old ones get removed, configurations drift. Review your DMARC reports regularly, even after reaching full enforcement.
Frequently asked questions
Can I use DMARC without SPF or DKIM?
Technically yes, but it's pointless. DMARC's policy is based on SPF and DKIM results. Without at least one of them configured, every email will fail DMARC. You need SPF, DKIM, or both for DMARC to be meaningful.
What's the difference between rua and ruf reports?
rua (aggregate) reports are daily summaries of authentication results—volumes and pass/fail rates by source. ruf (forensic) reports are detailed information about individual failing emails. Most organizations only use rua; ruf reports are less commonly sent and raise privacy concerns.
How long should I stay at p=none before moving to quarantine?
At least 2-4 weeks, longer if you have a complex email ecosystem. You need enough data to identify all legitimate email sources and verify they're properly authenticated. Rushing this phase is the most common cause of DMARC-related email problems.
Will DMARC stop all phishing?
No. DMARC prevents exact domain spoofing (someone sending as @yourcompany.com), but it doesn't stop lookalike domains (yourcompany-secure.com) or display name spoofing ('Your Company `<[email protected]>`'). It's an important layer, but not a complete anti-phishing solution.