Why DMARC Reporting Is Underused — and What You're Missing

• December 2022
• Engineering Memo · External Release

DMARC aggregate reports (rua= reports) are free daily intelligence from every major ISP about every message that arrived claiming to come from the monitored domain. They show every sending source (by IP and by authenticated domain), their authentication pass/fail rates, and the DMARC policy disposition applied to each. This data is available to every programme that has deployed DMARC with a rua= tag — at no additional cost, with no additional infrastructure requirement. And the majority of programmes that deploy DMARC do not read their aggregate reports.

This note documents what DMARC aggregate reports contain, what operational intelligence they provide, and why the programmes that read them consistently make better authentication and sender identity decisions than those that deploy DMARC and ignore the reporting it provides.

What the Aggregate Report Contains

Each DMARC aggregate report covers a 24-hour period and is sent by the reporting ISP to the email address specified in the DMARC record's rua= tag. The report is an XML file (sometimes gzip-compressed) that contains: the reporting organisation (the ISP sending the report), the reporting period (start and end timestamps), and a set of records — one record per sending source (unique combination of IP address and authentication results).

Each record in the aggregate report contains: the source IP address that sent the messages, the count of messages sent from that IP in the reporting period, the SPF authentication result (pass/fail/softfail/neutral/permerror/temperror), the SPF alignment result (pass/fail), the DKIM authentication result (pass/fail), the DKIM alignment result (pass/fail), the DMARC policy disposition applied (none/quarantine/reject), and the header_from domain (the From: header domain that triggered the DMARC evaluation).

This data answers the most important sender identity questions: which IP addresses are sending email with this domain in the From: header? Of those, which are passing authentication? Which are failing? Are there any sources sending with the programme's domain that should not be (spoofing or unauthorised sending)? Are all legitimate sending sources correctly configured for DKIM and SPF alignment?

The Five Operational Insights DMARC Reports Provide

Insight 1: Authentication configuration completeness. The aggregate report shows every legitimate sending source and its authentication status. A new ESP that was added without DKIM configuration appears in the report with DKIM fail and SPF alignment fail — DMARC failing for all messages from that source. Without the aggregate report, this authentication gap might go undetected for months until DMARC policy is advanced to p=quarantine and the misconfigured source begins generating quarantined messages. With the aggregate report, the gap is visible the next day.

Insight 2: Spoofing detection. Illegitimate senders attempting to spoof the programme's domain appear in the aggregate report as sources sending with the monitored From: header domain, but failing both SPF and DKIM authentication. These unknown sources, failing both authentication mechanisms, are either misconfigured legitimate sources or active spoofing attempts. The aggregate report is the only complete view of all entities sending with the programme's domain — which makes it a security intelligence tool as much as an authentication management tool.

Insight 3: DMARC policy advancement readiness. Before advancing DMARC policy from p=none to p=quarantine, the aggregate report provides the evidence that all legitimate sources are passing alignment. If the report shows one or more legitimate sources with DMARC failures, advancing the policy would quarantine their messages. The report review identifies which sources need authentication configuration correction before the policy can be safely advanced.

Insight 4: SPF permerror detection. When a sending source generates SPF permerror (from the SPF record complexity issue documented in the preceding note), this appears in the aggregate report as SPF permerror for that source. Without the report, SPF permerror may not be visible in any other monitoring tool — Postmaster Tools does not specifically report SPF permerror, and the accounting log may show normal delivery without indicating the authentication anomaly.

Insight 5: Forwarding and mailing list impact. Messages forwarded through mailing lists that break DKIM signatures appear in the aggregate report with DKIM fail from the forwarding server's IP. This pattern, combined with the ARC (Authenticated Received Chain) data in forensic reports, identifies which forwarding services are breaking authentication for the programme's messages and whether ARC implementation at those services would improve the situation.

Why Most Programmes Do Not Read Their Reports

DMARC aggregate reports are XML files that are useful only when parsed and displayed in a readable format. Raw XML aggregate reports sent to an email address accumulate as unread attachments that most email security teams are not equipped to process. The friction of report processing — downloading XML attachments, parsing the XML, extracting the relevant data fields, and summarising across multiple ISP reports for the same day — is sufficient to discourage systematic review even by technically capable teams.

The solution is DMARC report processing tools that automate the XML parsing and dashboard presentation. Commercial services (Dmarcian, Valimail, Postmark DMARC Digests, EasyDMARC) provide daily dashboards that display aggregate report data in readable format: the top sending sources, their authentication pass rates, the failure sources, and trend charts. These services transform the XML filing problem into a 5-minute daily dashboard review. The cost (€20-100/month depending on domain count and feature requirements) is the lowest-cost intelligence investment available for sender identity management.

For programmes that prefer not to use commercial tools, the DMARC aggregate reports can be processed with open-source tools (dmarc-cat, parsedmarc) or custom Python scripts using the dmarc-report-parser library. The open-source approach requires initial engineering investment to set up the processing pipeline but eliminates the monthly cost and provides more customisation options for the dashboard and alerting logic.

DMARC reporting is the only mechanism that makes the full sender identity landscape visible — every source sending with the programme's domain, their authentication status, and the threat landscape from spoofing sources. Not reading it is like deploying a security camera system and leaving the monitors off. The reports are being generated and sent whether or not they are read; the only question is whether the intelligence they contain informs operational decisions or accumulates unread in an email folder. Read the reports, act on what they reveal, and DMARC becomes the full sender identity management tool it was designed to be rather than just an authentication mechanism deployed for compliance.

The Monthly DMARC Report Review Routine

A structured monthly DMARC aggregate report review produces the five operational insights documented above in approximately 30 minutes. The review questions and where to find the answers in a DMARC reporting tool:

Question 1: Are any new sources appearing this month that were not present last month? Sort the source list by first-seen date. New IP addresses appearing in the report represent either new legitimate sending services (which should be investigated to confirm they are authorised) or new spoofing sources (which should be blocked through DMARC policy advancement or ISP postmaster reports). Any new source requires classification before the next monthly review.

Question 2: Are all high-volume sending sources passing DMARC? Sort the source list by message count, descending. The top 10 sending sources by volume should all show DMARC pass. Any high-volume source showing DMARC fail requires immediate investigation — it is either a misconfigured legitimate source (fix the authentication) or a significant spoofing campaign (report to ISPs).

Question 3: Has SPF permerror appeared for any source? Filter for SPF permerror results. Any source showing permerror should trigger an SPF record audit as described in the SPF complexity note. Permerror from the programme's own sending sources (known IPs) indicates an SPF record configuration problem. Permerror from unknown sources is typically irrelevant — spoofing sources may use SPF configurations that generate their own permerrors.

Question 4: Is DMARC failing for any volume above 0.5% of total messages? Calculate the DMARC failure rate (failed messages / total messages) from the report summary. Any DMARC failure rate above 0.5% in aggregate reports indicates a significant authentication configuration problem that requires immediate investigation and resolution before DMARC policy can be safely advanced to p=quarantine or p=reject.

Question 5: Are there ISP reports missing from this month's dataset? Major ISPs (Gmail, Yahoo, Microsoft) consistently send DMARC aggregate reports for monitored domains. If a major ISP is not represented in the past month's reports, it may indicate that the DMARC record's rua= address has a delivery problem (the reports are being sent but not received) or that the programme is sending very low volume to that ISP (below the ISP's reporting threshold). Verifying that the rua= reports are being received from all major ISPs confirms the reporting pipeline is functional.

Forensic Reports: The Companion to Aggregate Reports

DMARC also supports forensic reports (ruf= tag in the DMARC record), which provide per-message details for messages that fail DMARC evaluation. Unlike aggregate reports (which aggregate all messages by source and provide summary counts), forensic reports include the full message headers, DKIM signature data, and authentication failure reason for individual failed messages.

Forensic reports are extremely valuable for diagnosing specific authentication failures that the aggregate report identifies but cannot fully explain. An aggregate report entry showing 500 messages from IP 203.0.113.100 with DKIM fail — is this a DKIM key configuration error, a body hash mismatch, or a selector lookup failure? The forensic report for one of those failed messages shows the complete DKIM-Signature header and the specific failure reason, making diagnosis precise rather than inferential.

The limitation of forensic reports: not all ISPs send them (Gmail does not send ruf= forensic reports for privacy reasons), and the reports may contain message content that is sensitive. Many programmes therefore enable aggregate reports (rua=) but not forensic reports (ruf=). For programmes that do enable forensic reports, the data should be processed with appropriate privacy controls — forensic reports can contain email content, subject lines, and recipient data that requires careful handling under GDPR and similar data protection frameworks.

DMARC aggregate reports are the intelligence layer that makes authentication management evidence-based rather than assumption-based. They answer the questions that SPF records and DKIM configurations alone cannot: are they actually working for all the sources sending the programme's email? Is anyone spoofing the domain? Are there authentication gaps that are invisible without the ISP's perspective? These questions are answered by the reports, daily, for free, for every programme that has deployed DMARC. The only remaining investment is reading them. Make that investment, make it consistently, and DMARC reporting will pay dividends in authentication completeness, security visibility, and configuration confidence that no other tool can provide.

Setting Up DMARC Reporting: Technical Implementation

Enabling DMARC aggregate reporting requires two configuration steps: adding the rua= tag to the DMARC record with the email address where reports should be sent, and setting up processing for the reports once they arrive.

The rua= address can be any email address that can receive the aggregate report emails. If the rua= address is at a different domain than the monitored domain (e.g., rua=mailto:dmarc@reporting-service.com when monitoring brand.com), the reporting service's domain must publish a DMARC reporting authorisation record at brand.com._report._dmarc.reporting-service.com with content v=DMARC1. This authorisation record confirms that reporting-service.com has consented to receive reports for brand.com — preventing DMARC report harvesting by unauthorised third parties.

For programmes using a commercial DMARC reporting service, the service provides the rua= address and handles the authorisation record. The programme only needs to add the rua= tag to the DMARC record. For programmes building their own reporting pipeline, the rua= address is a mailbox on a domain the programme controls, and the authorisation record is only needed if the mailbox domain differs from the monitored domain.

Report processing latency: ISPs typically send aggregate reports within 24-48 hours of the close of the reporting period (end of day UTC). A DMARC record deployed today will begin receiving reports within 2-3 days, covering the first 24-hour reporting period after the record was published. The reports are retrospective — they cover past sending — so the intelligence they provide reflects authentication performance from the previous day. For most operational purposes, this 24-48 hour lag is acceptable; for urgent authentication incident investigation, the DMARC aggregate report for the previous day is available by the next morning.

DMARC Reporting and GDPR

DMARC aggregate reports contain IP addresses (which may be personal data under GDPR in some interpretations) and email header data. The aggregate nature of the reports — showing counts per IP rather than individual messages — significantly reduces the personal data concern. However, for programmes operating under strict GDPR interpretations, ensuring that the rua= address routes reports to a processing location within the EU (or an adequacy decision territory) is a precaution that may be appropriate.

Commercial DMARC reporting services that process reports on behalf of EU organisations are typically GDPR-compliant and operate under data processing agreements. For programmes building their own DMARC report processing pipeline, storing the raw XML report files for no more than 30 days and pseudonymising IP addresses in the analytical database (hashing them rather than storing in plain text) provides adequate data minimisation for most GDPR compliance requirements.

DMARC forensic reports (ruf= reports) have more significant privacy implications because they contain email content, recipient addresses, and full header data — all of which are personal data under GDPR. For EU programmes, enabling forensic reports requires careful consideration of the data protection framework, the lawful basis for processing, and the storage and access controls applied to the forensic data. Many EU programmes therefore choose to enable aggregate reports (rua=) only and not forensic reports (ruf=), accepting the loss of per-message diagnostic detail in exchange for the reduced data protection complexity.

The DMARC aggregate report intelligence is too valuable to leave unread, and the implementation complexity is lower than most programmes assume: add a rua= tag to the DMARC record, subscribe to a DMARC reporting service for dashboard presentation, and spend 30 minutes per month reviewing the five operational questions documented in this note. That investment -- one-time setup, 30 minutes monthly -- surfaces the sender identity intelligence that DMARC was designed to deliver and that most programmes are currently leaving on the table. Enable the reporting. Read the reports. Act on what they reveal.

The Competitive Advantage of Reading DMARC Reports

In industries where multiple organisations send email to overlapping audiences, the organisation that reads its DMARC reports has a structural authentication management advantage over those that do not. It knows immediately when a new sending service has an authentication configuration gap. It detects spoofing attempts against its domain within 24-48 hours of when they begin. It can advance DMARC policy to p=reject with confidence, providing maximum phishing protection, because it has verified from the reports that all legitimate sources pass DMARC. These are not hypothetical advantages — they are the practical differences in authentication posture that separate organisations that manage DMARC actively from those that deploy it passively.

The p=reject advancement in particular is a significant security and deliverability distinction. Organisations at p=reject have strong DMARC enforcement that prevents spoofed messages using their domain from being delivered to recipients at compliant ISPs. Organisations at p=none or p=quarantine have weaker protection. The p=reject advancement requires confidence that all legitimate sending sources pass DMARC — confidence that only aggregate report review can provide. The organisations that read their reports can achieve p=reject; those that do not cannot safely advance beyond p=quarantine without risking legitimate message rejection.

DMARC reporting is the last major authentication investment that most organisations make but do not fully utilise. DMARC deployment is increasingly universal; DMARC report processing is not. The organisations that bridge this gap — deploying DMARC and systematically reading what the reports reveal — operate with authentication transparency that makes every other deliverability investment more effective, more confident, and more clearly validated. The reports are free, the intelligence is detailed, and the investment to read them is modest. There is no strong argument for not doing it.

From Deployment to Active Management: The DMARC Journey

Many organisations treat DMARC as a one-time deployment project: add the DNS record, deploy at p=none, and consider it done. The DMARC journey that produces the full value of the protocol requires active management after deployment: reviewing aggregate reports, fixing authentication failures they reveal, advancing policy as confidence grows, and using the report data to maintain authentication completeness as the sending environment changes.

The active management model: deploy at p=none with rua= reporting → review aggregate reports monthly for 60 days → fix any authentication failures revealed → deploy at p=quarantine → review aggregate reports for 30 days to confirm no legitimate messages quarantined → deploy at p=reject → maintain monthly aggregate report reviews to detect authentication changes and spoofing attempts. This journey, completed systematically, takes 3-6 months from initial deployment to p=reject. Each step is gated on aggregate report evidence that the previous step is correctly configured.

The programmes that complete this journey benefit from the strongest available email authentication posture: all legitimate sources passing DMARC, spoofed messages rejected at major ISPs, and continuous visibility into the sender identity landscape. This posture is not achievable by deploying DMARC and ignoring the reports — it requires the active management that the report review enables. The report is the compass that guides the journey from initial deployment to p=reject enforcement. Follow it consistently, and the destination is the authentication posture that protects both deliverability and recipients.

DMARC reporting is the most underused intelligence asset in email deliverability management. The data is generated by ISPs, sent for free, and contains sender identity data that no other tool provides. The only barrier is the operational discipline to process and review it. Remove that barrier -- with a reporting tool, a monthly review habit, and the five operational questions documented in this note -- and DMARC reporting will deliver the authentication transparency that makes every other deliverability investment more effective and more clearly measurable.

The reports are free. The intelligence is rich. The investment is 30 minutes per month. Read them.

DMARC without reports is a lock without a key. The reports are the key. Use them.