DMARC Enforcement Blueprint: A Step-by-Step Technical Guide to Policy Creation & Aggregate Report Analysis for Multi-Domain Senders

DMARC Fundamentals and Prerequisites

DMARC (Domain-based Message Authentication, Reporting, and Conformance), defined in RFC 7489, is an email authentication protocol. It builds upon SPF (Sender Policy Framework, RFC 7208) and DKIM (DomainKeys Identified Mail, RFC 6376) to provide domain owners with the ability to protect their domain from unauthorized use, such as phishing and spoofing. DMARC instructs receiving mail servers on how to handle messages that fail authentication and provides reporting on authentication results.

Successful DMARC enforcement relies on SPF alignment and DKIM alignment. SPF aligns when the domain in the Return-Path header (MAIL FROM) matches the From header domain. DKIM aligns when the domain in the d= tag of the DKIM signature matches the From header domain. A message passes DMARC if at least one of these mechanisms passes and is aligned.

Before DMARC deployment, verify your SPF records are correctly configured and aligned. You can use our SPF checker for this. Ensure all legitimate sending sources are authorized in your SPF record. Similarly, confirm DKIM is properly implemented for all outbound mail streams.

DMARC Policy Creation and Deployment

DMARC policy is published as a TXT record in your DNS under the _dmarc subdomain. The policy dictates how receiving servers should treat emails that fail DMARC authentication. There are three primary policy types:

• p=none: This is the monitoring mode. Receiving servers collect DMARC reports but take no action on unauthenticated mail. This is the essential first step for data collection.
• p=quarantine: Receiving servers are instructed to place unauthenticated mail into the recipient's spam or junk folder. This policy provides a soft enforcement.
• p=reject: Receiving servers are instructed to outright reject or drop unauthenticated mail. This is the strongest enforcement policy, preventing unauthenticated mail from reaching the inbox or spam folder.

The rua tag specifies an email address to receive Aggregate Reports. The ruf tag specifies an email address for Forensic Reports, though these are less commonly used due to privacy concerns. The pct tag allows for gradual enforcement, applying the policy to a percentage of mail.

DNS Record Examples:

• Monitoring Mode (p=none): _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:[e-mail]"
• Quarantine Mode (p=quarantine) with 25% enforcement: _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:[e-mail]"
• Reject Mode (p=reject): _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[e-mail]"

The adkim and aspf tags control alignment modes. s (strict) requires exact domain matches, while r (relaxed, default) allows subdomain matches. For most deployments, relaxed alignment is sufficient.

Aggregate Report Analysis

Aggregate Reports (RUA) are XML-formatted reports sent daily by DMARC-compliant receiving mail servers. These reports provide a high-level overview of DMARC authentication results for your domain's mail. They are crucial for understanding your email ecosystem.

Key data points within an aggregate report include:

• source_ip: The IP address of the sending server.
• count: The number of messages observed from that IP.
• policy_evaluated: Shows the DMARC policy applied (none, quarantine, reject).
• disposition: The action taken by the receiving server (none, quarantine, reject).
• spf_pass: Whether SPF passed for the message.
• dkim_pass: Whether DKIM passed for the message.
• spf_aligned: Whether SPF was aligned with the From domain.
• dkim_aligned: Whether DKIM was aligned with the From domain.

Analyzing these reports helps identify legitimate sending sources that are failing DMARC. It also reveals unauthorized senders attempting to spoof your domain. Manual parsing of XML files is complex; dedicated DMARC report analyzers simplify this process by presenting data in an actionable format. Focus on discrepancies between spf_pass/dkim_pass and spf_aligned/dkim_aligned to pinpoint alignment issues.

Iterative Enforcement and Multi-Domain Strategy

DMARC enforcement is an iterative process. Start with p=none to gather data without impacting mail delivery. Analyze aggregate reports for several weeks to identify all legitimate sending sources and correct any SPF or DKIM configuration issues. Once confident, move to p=quarantine with a low pct value (e.g., 10-25%).

Gradually increase the pct value for p=quarantine over time, continuously monitoring reports. Address any new issues that arise. Once 100% of legitimate mail is passing DMARC with p=quarantine, transition to p=reject. Again, start with a low pct for p=reject and increase it incrementally. This phased approach minimizes disruption to legitimate email flow.

For multi-domain senders, each domain requires its own DMARC record. Subdomains inherit the parent domain's DMARC policy by default, unless an explicit sp (subdomain policy) tag is defined. For example, sp=reject will apply the reject policy to subdomains even if the parent domain is p=quarantine. Centralize DMARC report collection for all domains to streamline analysis. Prioritize critical domains and those most susceptible to spoofing for initial enforcement. Consistent DMARC enforcement helps maintain a positive email reputation checker. Ongoing monitoring of aggregate reports is essential, even after reaching p=reject, to detect new sending sources or configuration drift.