What Do DMARC Reports Actually Tell Me?

DMARC reports tell you which IP addresses sent mail claiming to be from your domain, the volume of messages from each source, and whether SPF, DKIM, and DMARC passed or failed for each one. Aggregate reports arrive daily as XML files. Forensic reports show individual failure details, but most providers no longer send them.

What's the difference between aggregate and forensic reports?

Aggregate reports (RUA) are daily XML summaries sent by receiving mail servers that show every IP address sending email from your domain, the volume of messages, and whether SPF, DKIM, and DMARC passed or failed for each source (dmarcreport.com). They arrive as compressed XML and show you sending IPs, message volumes, SPF pass/fail, DKIM pass/fail, and the DMARC disposition (the action the receiver took) (powerdmarc.com).

Critically, they contain no email content and no personally identifiable information, just authentication metadata, which makes them safe to receive and store in every region.

Forensic reports (RUF), also known as failure reports, are message-level reports generated when an individual email fails DMARC authentication, including details such as the recipient address, authentication results, and message headers for that specific email (easydmarc.com). The format is different, too. Aggregate reports are XML because they're built for machines to parse in bulk. Forensic reports use a completely different format called AFRF, the Authentication Failure Reporting Format (redsift.com).

Most major providers, including Google, Microsoft, and Yahoo, no longer send failure reports due to privacy constraints, so aggregate reports are more common and globally supported. Google has never sent RUF forensic reports due to privacy concerns about including email headers and subject lines in failure notifications. You will receive forensic reports from Microsoft (Outlook/365), Yahoo, and some enterprise receivers, but not from Gmail (dmarcreport.com).

For MSPs selling managed security, this means you can rely on aggregate reports but should not build monitoring workflows around forensic data that may never arrive.

What do failing sources usually turn out to be?

When you first open the guide (/guide) to DMARC reports, the most common question is whether a failing IP represents a threat or a legitimate tool you forgot to authorize. Marketing tools, CRM platforms, ticketing systems, legacy applications all surface in the reports. The ones that fail authentication are the ones you need to fix before enforcing your DMARC policy (dmarcreport.com).

Common shadow IT sources include support platforms (Zendesk), marketing tools (HubSpot, Mailchimp), CRM systems (SalesForce), and survey platforms (redsift.com). A sending IP you do not recognise appears in reports failing both SPF and DKIM. Either a legitimate service (invoicing, CRM, ticketing, a survey tool) was never authorised, or it is a genuine spoofing attempt. The reports tell you which by showing the source IP and volume.

If the volume is consistent and the IP resolves to a known provider, it is usually a forgotten third-party service. If the volume spikes unpredictably and the hostname does not match any vendor you recognize, treat it as unauthorized until proven otherwise. A single report showing five messages from an unknown IP in Eastern Europe is rarely a misconfigured helpdesk.

If someone is impersonating your domain to send phishing or spam emails, those messages will naturally fail DMARC, since the unauthorized source doesn't pass SPF or DKIM checks aligned to your domain. This is the one cause on this list that isn't a misconfiguration.

Why the first week of reports is mostly your own marketing tools

Start reviewing DMARC aggregate (RUA) reports within 24–48 hours of publishing your DMARC record, and continue daily reviews for at least 14–30 days (30–60 days for large enterprises) before moving from p=none to quarantine/reject. 74% of domains receive their first RUA within 24 hours, and median unique sending sources identified by day 7 range from 8–15 for SMBs to 60–120 for enterprises.

What surfaces first are the services that send the most mail. For most domains, that means transactional email platforms (SendGrid, Postmark), marketing automation (Mailchimp, HubSpot, Constant Contact), and the primary email provider (Google Workspace, Microsoft 365). Marketing platforms, CRMs, ticketing systems, and transactional email services all send messages using your domain in the From header. If they are not authorized in your SPF record and do not have DKIM selectors configured, every message they send will fail DMARC.

Spoofing attempts and obscure legacy services show up later, once you have enough volume to detect low-frequency senders. A survey tool that sends one reminder email per month will not appear in the first 48 hours unless you happen to send a survey during that window. You only get a report from a receiver if you sent them mail during the period.

This is why the free AI-visibility check (/check) at the domain level gives you a head start on inventory, but it cannot replace the forensic detail that only DMARC reports provide once mail starts flowing. By the time you reach day seven, you should have identified the majority of your active sending sources and can begin fixing the failures before tightening policy. If you are still discovering new sources in week three, your client likely has decentralized email practices that need documentation before enforcement is safe.

ActiScore's pricing (/pricing) includes DMARC monitoring as part of the Security category score, measured over DNS and TLS alongside SPF, DKIM, and TLS certificate health. For MSPs managing multiple client domains, the white-labelled reports make it straightforward to surface authentication gaps without requiring clients to interpret raw XML or understand the difference between alignment and authentication.