1. Why DMARC Aggregate Reporting is Mandatory for High-Volume MTAs

DMARC (Domain-based Message Authentication, Reporting, and Conformance) does not simply block unauthenticated mail; it provides a bi-directional reporting mechanism:

• Visibility into Shadow IT: Marketing teams frequently spin up third-party services (Zendesk, Marketo, Mailgun) using corporate domains without notifying infrastructure teams. RUA reports expose these unauthorized sending sources instantly.
• DKIM Key Drift Detection: If a public key published in DNS becomes corrupted, truncated, or out of sync with PowerMTA’s private key, RUA reports reflect instant 100% DKIM failure across receiving networks.
• Prerequisite for BIMI: Brand Indicators for Message Identification (BIMI)—displaying verified brand logos in Gmail and Apple Mail—strictly requires DMARC enforcement at p=quarantine pct=100 or p=reject.

2. DNS Record Construction: Configuring rua and ruf Reporting Tags

To enable aggregate reporting, publish an authoritative TXT record at _dmarc.yourdomain.com:

# Stage 1: Monitoring Mode with Daily Aggregate XML Ingestion
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@yourdomain.com; ruf=mailto:dmarc-ruf@yourdomain.com; fo=1; aspf=r; adkim=r;"

# Stage 2: Full Enforcement Under Strict Rejection
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-rua@yourdomain.com; aspf=s; adkim=s;"

3. Decoding DMARC XML Aggregate Reports: Structure & Diagnostics

Mailbox providers bundle daily delivery results into compressed XML archives (.xml.gz). The payload reveals exactly how each receiving ISP evaluated your mail:

• <source_ip>: The public IPv4 address that connected to the ISP MX server over port 25.
• <count>: The number of messages delivered from that IP during the 24-hour reporting period.
• <policy_evaluated>: Shows the final disposition applied by the ISP (none, quarantine, reject) and SPF/DKIM validation results.
• <auth_results>: Details specific DKIM selectors, domain signatures, and SPF Return-Path evaluation.

4. Identifying Authentication Failures: Alignment Mismatches vs Third-Party Forgery

When analyzing DMARC aggregate XML data, operators must distinguish between two failure types:

• Alignment Failure (Internal Fix Required): The email passed SPF and DKIM, but the domain used in the Return-Path (e.g., bounce.espprovider.com) does not match the visible From: domain (yourdomain.com). Fix: Configure PowerMTA with custom Return-Path subdomains matching your brand.
• Third-Party Spoofing (External Threat): Unknown IP addresses (e.g., residential botnets in Eastern Europe or South America) attempting to send mail claiming to be your domain with zero valid signatures. Fix: Escalate policy to p=reject to instruct ISPs to drop this traffic immediately.

5. The Road to p=reject: Safe Escalation Milestones

Moving from monitoring to strict enforcement requires a structured, phased roadmap:

1. Phase 1: Audit (p=none for 30 Days): Ingest all RUA reports. Identify all legitimate internal services sending mail on your behalf. Add authorized IPs to SPF and configure 2048-bit DKIM keys.
2. Phase 2: Quarantine Ramp (p=quarantine pct=25 → 50 → 100): Instruct ISPs to route failing messages to Spam. Monitor for false positives among legitimate business streams.
3. Phase 3: Strict Enforcement (p=reject): Instruct global ISPs to drop unaligned mail at the SMTP handshake. Zero spoofed mail reaches recipient inboxes.

6. DMARC Policy Progression Matrix