DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email security protocol. It protects your domain from spoofing and phishing and gives you visibility into your email traffic.
Whether you manage a small business domain or oversee email infrastructure for an enterprise, DMARC gives you policies and reports to control your domain's email reputation. This guide walks you through the main concepts, step-by-step deployment, and troubleshooting strategies.
What you will learn
What happens without DMARC
A spoofing attack in 4 steps
Step 1. An attacker wants to impersonate your CEO. They do not need access to your mail server. They just need to know the CEO's email address, which is usually public.
Step 2. Using any mail server on the internet, the attacker sends an email to your CFO. The "From" address shows [email protected]. The display name looks correct. The email asks the CFO to wire $47,000 to a "new vendor" before end of day.
Step 3. Your CFO sees the email in their inbox. It looks legitimate. There is no warning, no spam flag, nothing unusual. The sender appears to be the CEO.
Step 4. The wire goes out. The money is gone.
This is called Business Email Compromise (BEC). According to Hoxhunt's 2026 BEC analysis, which compiles FBI IC3 data, BEC caused approximately $2.9 billion in reported losses in the US alone in 2023. Organizations with more than 1,000 employees face a 70% weekly probability of receiving at least one BEC attack. Over 60% of these scams rely on impersonating a trusted sender, which is exactly what DMARC blocks.
DMARC prevents this attack. When your domain has a DMARC record set to p=reject, the receiving mail server checks whether the email was actually sent from an authorized server. The spoofed email fails the check and gets rejected before it reaches the CFO's inbox.
What is DMARC?
DMARC builds on two existing email checks: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). It lets you publish a policy that tells receivers how to handle email that fails these checks.
When a message arrives, the receiving server runs SPF and DKIM checks. It then applies your DMARC policy to decide what to do with emails that fail.
DMARC is defined in RFC 7489 (2015). The next version, DMARCbis, is in progress at the IETF and will become the new standard.
Why DMARC matters
Email spoofing remains one of the most common attack vectors. With DMARC, you can:
- Block exact-domain spoofing. Stop emails that pretend to come from your domain. Providers report high block rates once p=reject is stable
- Protect brand trust. Maintain trust with customers and partners by preventing attackers from using your name
- Improve deliverability. Authenticated emails land in the inbox more often
- Gain visibility. Receive XML aggregate reports that show every source sending email as your domain
- Meet sender requirements. Google and Yahoo require DMARC for bulk senders (5,000+ emails/day) since February 2024. Senders who do not comply get their emails rejected
Deploy DMARC in 3 phases
This is the part most people need first. DMARC deployment follows a proven 3-phase approach. Do not skip phases. Each phase builds confidence before tightening the policy.
Monitor (p=none)
Duration: 2-4 weeks minimum
Start by collecting data. This policy does not affect email delivery. It only tells receivers to send you reports.
Review reports to discover all legitimate senders. Use fo=1 to request forensic reports on any failure. Note: Gmail, Yahoo, and Microsoft rarely send forensic reports (RUF) due to privacy policies.
Quarantine (p=quarantine)
After SPF/DKIM are set for all legitimate sources
Move suspicious emails to spam. Start with a low percentage and increase gradually.
Start with pct=25. This means only 25% of failing emails get quarantined. Increase to 50%, then 100% as you confirm no legitimate emails are affected.
Reject (p=reject)
Full protection. Block spoofed emails completely
Reject all emails that fail DMARC checks. This is the goal.
Use strict alignment (adkim=s; aspf=s) for stronger security. Set sp=reject to protect subdomains too.
Do not skip monitoring. Jumping to p=reject without analysis can block legitimate emails. Validate SPF and DKIM for 100% of your email volume before enforcing reject.
How DMARC works
DMARC works in four steps. The first two happen behind the scenes. The last two are what you control.
Step 1: Authentication check
The receiving server runs SPF and DKIM checks to verify the message. SPF confirms the sending server is authorized. DKIM confirms the message was not modified in transit.
Step 2: Alignment verification
This is the key concept that makes DMARC different from SPF and DKIM alone.
Alignment in plain language
Think of it like a physical letter. When you receive a letter, it has two addresses: the return address on the envelope (the technical sender) and the letterhead inside (the visible sender). You trust the letter because both match.
Email works the same way. Every email has a technical sender (hidden from the user) and a visible sender (the "From" address you see in your inbox). SPF and DKIM verify the technical sender. But without DMARC, nobody checks whether the technical sender matches the visible one.
That is the gap attackers exploit. They can pass SPF and DKIM using their own domain for the technical sender, while putting your domain in the visible "From" field. The email looks like it came from you.
DMARC closes this gap. It checks that the technical sender and the visible sender belong to the same domain. This check is called alignment. If they do not match, the email fails DMARC.
Technical details: how alignment works under the hood
DMARC focuses strictly on the RFC 5322 "Header From" domain. This is the address visible to the end user in their email client. It explicitly ignores other headers like Reply-To, Sender, or X-Original-Sender.
To pass DMARC, a message must pass Identifier Alignment with at least one protocol (SPF or DKIM). As Cisco's DMARC documentation explains, alignment ensures "the domain identity authenticated by SPF and DKIM matches the domain in the email address visible to the end user."
SPF alignment
Compares the Return-Path (RFC 5321 Envelope From) vs. Header From.
Challenge: ESPs (like Mailchimp or SendGrid) often use their own domain in the Return-Path to process bounces. This breaks SPF alignment, so DKIM alignment becomes necessary.
DKIM alignment
Compares the d= domain in the cryptographic signature vs. Header From.
Benefit: This survives forwarding (which breaks SPF) and allows ESPs to sign on your behalf without changing the invisible Return-Path.
The rule: DMARC Pass = (SPF Pass + SPF Aligned) OR (DKIM Pass + DKIM Aligned). You do not need both, but having both is best practice (defense in depth).
If the difference between Header From and Return-Path still feels abstract, our article on the Return-Path and its role in DMARC walks through the message identities step by step.
Step 3: Policy application
Based on your DNS policy, the server decides how to handle emails that fail alignment:
- None (p=none). Take no action, but send reports
- Quarantine (p=quarantine). Send suspicious messages to the spam folder
- Reject (p=reject). Reject suspicious messages completely
Step 4: Reporting
Receivers send aggregate and sometimes forensic reports back to you. Aggregate reports (RUA) are daily stats. Forensic reports (RUF) include details about individual failed messages. These reports are what allow you to move safely from phase 1 (monitor) to phase 3 (reject).
DMARC record structure
A DMARC record is a DNS TXT record at _dmarc.yourdomain.com. It uses tags to define your policy:
For all fields and rules, see our DMARC DNS specifications reference guide.
Key DMARC tags
- v. Version (always DMARC1)
- p. Policy for the domain (none, quarantine, reject)
- rua. Email address for aggregate reports (XML format, daily frequency)
- ruf. Email address for forensic reports (message samples for failed auth)
- sp. Policy for subdomains (inherits parent domain policy if not specified)
- adkim. DKIM alignment (r=relaxed allows org-domain match; s=strict needs exact match)
- aspf. SPF alignment (r=relaxed allows org-domain match; s=strict needs exact match)
- pct. Percentage of messages to apply policy (0-100, being replaced by t=y/n flag in DMARCbis)
- rf. Reporting format (afrf for authentication failure reports)
- ri. Reporting interval in seconds (86400 = daily default)
Alignment modes: relaxed vs. strict
You can control how precise the domain match must be using the aspf (SPF alignment) and adkim (DKIM alignment) tags.
Relaxed mode (default)
aspf=r; adkim=r;
Allows a match between the organizational domain and any subdomain. This is the industry standard.
Strict mode
aspf=s; adkim=s;
Requires an exact FQDN match. Useful only if subdomains are distinct entities that should not send email as each other.
Note: Most organizations use relaxed alignment. Strict alignment often breaks valid email flows (like marketing subdomains signed by the root domain) without adding much security for typical business use cases.
Infrastructure considerations
Use secure, well-configured mail servers with current TLS settings, patched MTAs, and strict access controls on DNS and signing keys. Keep sender inventories accurate so every service can be authenticated.
Subdomain policy inheritance
Common DMARC challenges
DMARC works well, but teams often face these issues during deployment:
Email source discovery
Many teams discover more legitimate senders than expected, including third-party tools, marketing platforms, and legacy systems. The monitoring phase (p=none) is specifically designed to reveal these senders before enforcement begins.
Authentication setup
Setting SPF and DKIM for every sender can be complex, especially at scale. Each email service provider has different instructions for DKIM key configuration and SPF include mechanisms.
Report analysis
Aggregate reports are XML files with pass/fail stats, source IPs, and auth results. They are usually compressed (GZIP/ZIP) and sent daily. Forensic reports (ARF) include headers but are rare due to privacy rules. A DMARC monitoring tool makes analysis significantly easier than reading raw XML.
DMARC validation and testing
Validate your DMARC setup with these checks:
Check DMARC record
Test email authentication
Monitor implementation
Troubleshooting common issues
DMARC pass but delivery issues
- Check reputation. Domain/IP may be on blocklists
- Content filters. Message content may trigger spam filters
- Rate limiting. Sending too many emails too fast
Authentication failures
- SPF failures. Missing IPs in SPF, over 10 DNS lookups (RFC 7208), forwarding breaks SPF
- DKIM failures. Wrong selector, weak keys (< 1024-bit, RFC 8301), body changes, mailing list footers
- Alignment failures. Domain mismatch in relaxed/strict mode, org-domain vs subdomain issues
- ARC help. RFC 8617 (Authenticated Received Chain) preserves auth through forwarding (Gmail, Outlook, Yahoo support it)
Report delivery problems
- RUA/RUF not received. Check mail server, spam filters, mailbox size
- XML parsing errors. Use a DMARC analyzer, validate XML
- Too many reports. Rate-limit, or use an external service
Performance and security considerations
DNS performance
- TTL. Use a sensible TTL (3600s is a good default)
- Record size. Keep DMARC records under 512 bytes for UDP
- One record only. Only one DMARC record per domain
- Tree Walk. DMARCbis replaces Public Suffix List with DNS Tree Walk (7-label limit)
Security best practices
- Monitor often. Review reports weekly, alert on auth failures
- Rotate keys. Rotate DKIM keys yearly. Use 2048-bit RSA or Ed25519-SHA256 (RFC 8463)
- Access control. Restrict DNS record modification access
- Backup reporting. Add multiple RUA addresses
- External reports. Authorize third-party services with _report._dmarc records
- Stay patched. Keep validators updated (e.g., CVE-2020-12272, CVE-2024-7208/7209)
Next steps
Ready to protect your domain? Follow this plan:
- Assessment. Audit senders and current auth
- Prerequisites. Set SPF and DKIM for all sources
- Monitoring. Deploy p=none and collect 2-4 weeks of data
- Analysis. Review RUA/RUF and find all senders
- Enforcement. Ramp from quarantine to reject
- Maintenance. Keep monitoring and responding
For official resources, visit DMARC.org, an initiative of the Trusted Domain Project.
Learn more
Want to go deeper? Explore these guides:
- Free DMARC generator: create your first DMARC record
- Real-time DMARC state of top 100 domains
- Why DMARC was created: closing SPF and DKIM gaps
- SPF explained: strengths, weaknesses and role in DMARC
- DKIM deep dive: pros, cons and alignment with DMARC
- DMARC alignment explained: why SPF and DKIM pass but DMARC fails
- DMARC monitoring and reporting: a practical guide
Common mistakes to avoid: multiple DMARC records on the same domain, too many SPF lookups (10 max), enforcing p=reject without a monitoring phase, and missing subdomain policies. These cause delivery failures.