What is DMARC? The Complete Guide to Domain-Based Message Authentication

DMARC - Domain-based Message Authentication, Reporting, and Conformance - is the protocol that ties SPF and DKIM together into a unified email authentication framework. Without DMARC, SPF and DKIM operate independently, and there is no standardized way to tell receiving servers what to do when authentication fails, or to receive reports about authentication results across the internet.

RFC 7489 defines DMARC as a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting. Receiving mail servers can use these policies to improve mail handling decisions.

DMARC solves three problems that SPF and DKIM alone cannot:

1. Policy enforcement - It tells receiving servers whether to reject, quarantine, or accept messages that fail authentication
2. Alignment - It requires that the domain authenticated by SPF or DKIM matches the domain in the visible From header, closing the gap where SPF or DKIM might pass on a different domain than the one the recipient sees
3. Reporting - It provides a standardized reporting mechanism so domain owners can see exactly who is sending email using their domain - and whether those messages pass or fail authentication

How DMARC Works

DMARC evaluation happens after SPF and DKIM have already been checked. The flow is:

1. The receiving server checks SPF (is the sending IP authorized by the domain’s SPF record?)
2. The receiving server checks DKIM (does the message carry a valid DKIM signature?)
3. The receiving server checks DMARC alignment (does the domain authenticated by SPF or DKIM match the From header domain?)
4. If neither SPF nor DKIM passes with alignment, the receiving server applies the DMARC policy

The key insight is that DMARC does not perform its own authentication check. It evaluates the results of SPF and DKIM and adds alignment verification and policy enforcement on top.

The DMARC DNS Record

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. Here is a typical example:

_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=r; aspf=r; pct=100"

Tag	Meaning	Values
v=DMARC1	Version (required)	Always DMARC1
p=	Policy (required)	none, quarantine, reject
rua=	Aggregate report recipients	mailto: URI
ruf=	Forensic report recipients	mailto: URI
adkim=	DKIM alignment mode	r (relaxed) or s (strict)
aspf=	SPF alignment mode	r (relaxed) or s (strict)
pct=	Percentage of messages to apply policy	1-100 (default 100)
sp=	Subdomain policy	none, quarantine, reject
fo=	Forensic report options	0, 1, d, s

You can check any domain’s DMARC record using the DMARC Checker.

DMARC Policies: none, quarantine, reject

The p= tag is the most important element of a DMARC record. It tells receiving servers what to do with messages that fail both SPF and DKIM alignment.

p=none (Monitor Only)

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

This is the starting point for DMARC deployment. It instructs receiving servers to take no action on failing messages - deliver them normally. The purpose of p=none is to collect aggregate reports so you can see:

• Which services are sending email on your behalf
• Whether those services pass SPF and DKIM
• Whether alignment is configured correctly
• Whether any unauthorized senders are using your domain

Use p=none for at least 2-4 weeks before moving to a stricter policy. This gives you time to identify and fix legitimate sending sources that are not properly authenticated.

p=quarantine

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=25

Quarantine instructs receiving servers to treat failing messages as suspicious. In practice, this usually means routing them to the spam or junk folder. The pct= tag lets you apply the quarantine policy to only a percentage of failing messages, allowing a gradual rollout.

A common deployment strategy is:

1. Start with p=quarantine; pct=10 - Apply quarantine to 10% of failing messages
2. Monitor reports for false positives
3. Increase to pct=25, then pct=50, then pct=100
4. Move to p=reject once you are confident

p=reject

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

Reject instructs receiving servers to completely block messages that fail both SPF and DKIM alignment. The message is not delivered at all - the sender receives a bounce message.

p=reject provides the strongest protection against domain spoofing, but it must be deployed carefully. If any legitimate sending source is not properly authenticated, its messages will be rejected.

Detailed guide: From Monitoring to Enforcement: Building a Scalable DMARC Strategy

DMARC Alignment: The Missing Piece

Alignment is what makes DMARC fundamentally different from running SPF and DKIM independently. Without alignment, an attacker could set up SPF and DKIM for their own domain and then use that domain in the Return-Path or DKIM signature while spoofing your domain in the visible From header. The recipient would see your domain, but authentication would actually be checking the attacker’s domain.

DMARC closes this gap by requiring that at least one of the following is true:

• SPF alignment - The domain in the Return-Path (envelope sender) matches the domain in the From header
• DKIM alignment - The domain in the DKIM signature (d= value) matches the domain in the From header

Relaxed vs Strict Alignment

DMARC supports two alignment modes for each protocol:

Relaxed alignment (default): The organizational domain must match, but subdomains are allowed.

• From: user@example.com with Return-Path: bounce@mail.example.com - Passes relaxed SPF alignment
• From: user@example.com with d=mail.example.com - Passes relaxed DKIM alignment

Strict alignment: The domains must match exactly.

• From: user@example.com with Return-Path: bounce@mail.example.com - Fails strict SPF alignment
• From: user@example.com with d=example.com - Passes strict DKIM alignment

Most organizations should start with relaxed alignment. Strict alignment is appropriate for high-security environments where subdomain control is critical.

Detailed guides:

• Are Your SPF and DKIM Identifiers Aligned?
• A Simple Explanation of DMARC Compliance Laws
• Fixing the SPF Alignment Failed Error

DMARC Reporting: Visibility Into Your Email Ecosystem

One of DMARC’s most valuable features is its reporting mechanism. DMARC reports give you visibility into every email sent using your domain - whether you authorized it or not.

Aggregate Reports (rua)

Aggregate reports are XML documents sent by receiving mail servers (typically daily) that summarize authentication results for your domain. They include:

• Source IP addresses that sent email using your domain
• The number of messages from each source
• SPF and DKIM pass/fail results for each source
• DMARC alignment results
• The DMARC policy applied to failing messages

Aggregate reports are the primary tool for:

• Discovering unauthorized senders using your domain
• Identifying legitimate services that are not properly authenticated
• Monitoring the effectiveness of your DMARC policy over time
• Preparing for policy upgrades (from none to quarantine to reject)

Raw aggregate reports are XML and difficult to read manually. A purpose-built DMARC reporting tool like DMARC Report parses these reports into human-readable dashboards, showing you exactly which sources are passing or failing authentication. DMARC Report is DuoCircle’s complementary product designed specifically for this purpose - it ingests your aggregate reports and provides actionable insights, trend analysis, and alerting.

Detailed guide: How to Utilize DMARC Reports to Resolve SPF Errors

Forensic Reports (ruf)

Forensic reports (also called failure reports) are sent in near-real-time for individual messages that fail DMARC. They include detailed information about the specific message, including headers and sometimes partial message content.

Forensic reports are useful for:

• Investigating specific spoofing incidents
• Debugging authentication failures for individual messages
• Identifying the exact point of failure in the authentication chain

Privacy note: Many receiving servers do not send forensic reports due to privacy concerns, and some redact personal information from the reports they do send. Do not rely on forensic reports as your sole source of DMARC data.

The fo= tag controls when forensic reports are generated:

Value	Meaning
fo=0	Report if both SPF and DKIM fail (default)
fo=1	Report if either SPF or DKIM fails
fo=d	Report if DKIM fails
fo=s	Report if SPF fails

DMARC and Anti-Spam: Different Problems

A common misconception is that DMARC is an anti-spam tool. It is not. DMARC authenticates domain identity - it tells you whether the sender is who they claim to be. It does not evaluate message content for spam characteristics.

An email can pass DMARC and still be spam (if the sender is authenticated but sends unwanted content). Conversely, a legitimate email can fail DMARC (if authentication is misconfigured). DMARC and anti-spam filters work at different layers and complement each other.

Detailed guide: DMARC and Anti-Spam Aren’t the Same!

Deploying DMARC: A Step-by-Step Strategy

DMARC deployment should follow a phased approach to avoid disrupting legitimate email delivery.

Phase 1: Preparation

1. Audit your sending sources - Document every service, server, and platform that sends email using your domain
2. Configure SPF - Ensure your SPF record includes all authorized senders
3. Configure DKIM - Set up DKIM signing for all sending platforms
4. Verify alignment - Confirm that SPF and DKIM domains align with your From header domain

Phase 2: Monitor (p=none)

1. Publish a DMARC record with p=none and a rua= address for aggregate reports
2. Set up a DMARC report processor (like DMARC Report) to parse incoming reports
3. Monitor reports for 2-4 weeks
4. Identify and fix any legitimate sources that are failing authentication or alignment

Phase 3: Quarantine

1. Update to p=quarantine; pct=10 to start routing a small percentage of failing messages to spam
2. Monitor reports for false positives (legitimate mail being quarantined)
3. Gradually increase the pct= value as confidence grows
4. Once at pct=100 with no false positives, move to Phase 4

Phase 4: Reject

1. Update to p=reject to fully block unauthenticated messages
2. Continue monitoring aggregate reports for any new services or misconfigurations
3. Maintain your SPF and DKIM configurations as services change over time

Detailed guides:

• From Monitoring to Enforcement: Building a Scalable DMARC Strategy
• How Should You Implement DMARC as an MSP or Enterprise?
• Spotting Spoofed Emails with DMARC: A Guide

DMARC Compliance Requirements

DMARC is increasingly becoming a regulatory and industry requirement, not just a best practice.

Google and Yahoo Requirements (2024+)

Since February 2024, Google and Yahoo require DMARC authentication for bulk senders (those sending more than 5,000 messages per day to Gmail or Yahoo addresses). Domains without DMARC may see reduced deliverability.

Detailed guide: Major Email Service Providers Emphasize DMARC Deployment

PCI DSS 4.0

The Payment Card Industry Data Security Standard (PCI DSS) version 4.0 makes DMARC mandatory for organizations that process payment card data, with full enforcement beginning in 2025.

Detailed guide: DMARC to be Mandatory for PCI DSS Compliance by 2025

GDPR and Data Protection

DMARC aggregate reports provide visibility into email traffic that can help organizations meet GDPR requirements for data protection and breach notification.

Detailed guide: Implementing DMARC to Gain Visibility and Maintain GDPR Compliance

Government Requirements

Multiple governments have mandated or strongly recommended DMARC for government domains, including the UK (via the NCSC), New Zealand, and the United States (via BOD 18-01).

Detailed guides:

• The New Zealand Government’s New DMARC Requirements
• Efficient DMARC Tools Needed After UK NCSC Changes

DORA (Digital Operational Resilience Act)

The EU’s DORA regulation intersects with DMARC requirements for financial institutions.

Detailed guide: The Point Where DORA and DMARC Intersect

Common DMARC Errors and Troubleshooting

554 5.7.5 Permanent Error in DMARC

This error indicates that a receiving server rejected a message based on DMARC policy. It typically means both SPF and DKIM failed to align with the From header domain.

Detailed guide: What is the 554 5.7.5 Permanent Error in DMARC and How to Fix It?

SPF Passes but DMARC Fails

This happens when SPF authenticates the envelope sender domain, but that domain does not match the From header domain (alignment failure). The fix is to configure the envelope sender to use your domain, or to set up DKIM with a matching d= domain.

Detailed guides:

• How SPF, DKIM, and DMARC Work Together During Authentication Failures
• How SPF and DMARC Work Together to Improve Email Security

Forwarded Mail Fails DMARC

Email forwarding breaks SPF (the forwarding server’s IP is not in the original domain’s SPF record). If DKIM is not configured or the forwarding server modifies the message (breaking the DKIM signature), DMARC fails. The solution is to ensure DKIM is properly configured, as DKIM signatures survive forwarding if the message content is not modified.

The DMARC and SPF Relationship

DMARC depends heavily on SPF being correctly configured. If your SPF record has errors - whether it exceeds the 10-DNS-lookup limit, contains syntax mistakes, or is missing authorized senders - DMARC enforcement will cause those authentication failures to result in quarantined or rejected mail.

Before deploying DMARC in enforcement mode, verify your SPF record with the SPF Checker and ensure your DNS lookup count is within limits using the SPF Validator.

For domains with complex SPF records that approach the lookup limit, AutoSPF provides dynamic SPF flattening that keeps your record within limits automatically - a critical foundation for reliable DMARC enforcement.

DMARC Report - DuoCircle’s Complementary Product

DMARC Report is DuoCircle’s dedicated DMARC reporting and analytics platform. It is designed to work alongside AutoSPF to provide complete email authentication management:

• AutoSPF handles the SPF side - dynamic flattening, DNS lookup management, and SPF record optimization
• DMARC Report handles the visibility side - parsing aggregate reports, identifying authentication failures, tracking compliance trends, and alerting on issues

Together, they give you full control over your email authentication posture. DMARC Report ingests your rua= aggregate reports, normalizes the data, and presents actionable dashboards that show you exactly which senders are passing or failing authentication for your domain.

Diagnostic Tools

• DMARC Checker - Validate your DMARC record and check for common configuration issues
• Domain Auth Checker - Combined SPF, DKIM, and DMARC check in one lookup
• SPF Checker - Verify SPF is correct before enforcing DMARC
• DKIM Lookup - Verify DKIM keys are published and valid
• SPF Validator - Full SPF evaluation with lookup counting

Next Steps

1. Check your current DMARC status - Use the DMARC Checker to see if you have a DMARC record and what policy it specifies
2. Start with p=none - If you do not have DMARC deployed, start in monitor mode to collect data
3. Set up report processing - Point your rua= address to DMARC Report for human-readable dashboards
4. Fix authentication gaps - Use aggregate reports to identify and fix services that fail SPF or DKIM
5. Progress to enforcement - Move through quarantine to reject as your authentication coverage matures
6. Maintain ongoing - Email infrastructure changes constantly. Monitor reports and update SPF/DKIM configurations as needed

For a complete comparison of SPF management tools, see PowerDMARC Alternatives, EasyDMARC Alternatives, and DMARCLY Alternatives.