Understanding DMARC Reports

If you own a domain, you have no visibility into who is sending emails in your name, unless you've set up DMARC. Without it, anyone can spoof your domain and you'd never know.

DMARC reports fix that. They're automated summaries sent to you by mail providers like Google and Microsoft, showing who sent email from your domain, whether it passed authentication, and whether anyone is trying to impersonate you.

In short: DMARC reports are your window into your domain's email activity. Here's what they contain, how they work, and how to use them.

 

What Are DMARC Reports?

Once your DMARC record includes a rua and ruf reporting address, mail providers automatically send you two types of reports:

Aggregate Reports (RUA) Daily summaries from mail providers covering all email traffic they received claiming to be from your domain. For each sending IP address, they show how many messages were sent and whether they passed or failed SPF and DKIM checks. These are the most important reports for monitoring your domain.

Forensic Reports (RUF) Near-real-time alerts triggered when a specific message fails authentication. They contain more detail like email headers, useful for diagnosing individual failures.

Note: not all mail providers send forensic reports due to privacy considerations.

 

What's Inside a DMARC Report?

Aggregate reports are delivered as XML files and typically include:

 

• The reporting organization (e.g., Google, Microsoft, Yahoo)

Every major email provider that receives email on behalf of others is required to send DMARC reports if your domain requests them. The reporting organization is that provider, Google, Microsoft, Yahoo, Apple, and dozens of others.

This matters because each reporter only tells you about emails their users received. A full picture of your domain's email activity comes from aggregating reports across all reporters.

<org_name>Google Inc.</org_name> <email>noreply-dmarc-support@google.com</email>

If you're not receiving reports from major providers like Google or Microsoft, it usually means your DMARC record is missing or misconfigured.

 

• Your DMARC policy as seen by the reporter

What policy was actually applied.

The report shows the DMARC policy the receiving server read from your DNS at the time, not what you think it says.

This is a useful sanity check: if the policy in the report differs from what you set, it means your DNS change hasn't propagated yet or there's a misconfiguration.

<policy_published> <domain>acme-corp.com</domain> <p>quarantine</p> ← your active policy <pct>100</pct> ← applied to 100% of mail </policy_published>

The pct field lets you roll out enforcement gradually — e.g. pct=20 applies your policy to only 20% of failing mail, useful when moving from none to quarantine for the first time.

 

• A breakdown of sending IP addresses

This is one of the most valuable parts of the report. Every IP address that sent email claiming to be from your domain is listed, along with a message count. This lets you see your full sending footprint, including sources you may have forgotten about or never authorized.

<source_ip>209.85.220.41</source_ip> ← Google Workspace <count>1204</count> <source_ip>91.189.4.72</source_ip> ← Unknown sender <count>98</count>

Common legitimate sources you might find: your email provider (Google Workspace, Microsoft 365), marketing tools (Mailchimp, HubSpot), transactional email services (SendGrid, Postmark), and CRM systems.

Unknown IPs sending volume from your domain are a red flag. They could be spoofing attempts, or a third-party tool your team set up without telling IT.

 

• Authentication results

Whether SPF and DKIM passed or failed, and whether they aligned with your domain.

For each sending IP, the report shows the result of two authentication checks and whether those results aligned with your domain.

SPF (Sender Policy Framework) — checks whether the sending server's IP is listed in your domain's DNS as an authorized sender. Pass means the IP was on your approved list. Fail means it wasn't.

DKIM (DomainKeys Identified Mail) checks a cryptographic signature attached to the email. Pass means the signature matches the public key in your DNS and the message wasn't tampered with in transit. Fail means it either wasn't signed or the signature is broken.

Alignment this is the DMARC-specific part. It's not enough to just pass SPF or DKIM, the authenticated domain must also match the domain in the visible "From" header. This is what prevents a bad actor from passing SPF on their own domain while spoofing yours in the From field.

<policy_evaluated> <dkim>fail</dkim> ← DKIM not aligned <spf>pass</spf> ← SPF passed and aligned </policy_evaluated>

Both pass → DMARC pass

Either passes + aligned → DMARC pass

Both fail → DMARC fail

A common real-world case: your SendGrid setup passes SPF but fails DKIM because the DKIM signing key was never configured. DMARC still passes because SPF alone is sufficient but fixing DKIM adds a second layer of protection and improves deliverability.

 

• The disposition - what action was taken (none, quarantine, or reject)

The disposition tells you what action was taken on each message, which is determined by your policy combined with the authentication result.

none — delivered normally (monitoring mode)

quarantine — sent to spam folder

reject — blocked before delivery

If your policy is p=none, all mail is delivered regardless of result, the disposition will always show "none" even for failing messages. This is intentional for the monitoring phase.

<policy_evaluated> <disposition>quarantine</disposition> <dkim>fail</dkim> <spf>fail</spf> </policy_evaluated>

Important: disposition reflects what the reporter claims to have done. Most large providers like Google and Microsoft honour DMARC policies reliably, smaller or regional providers may not, which is another reason monitoring report data across multiple sources matters.

 

Why Are They Hard to Use Without a Tool?

DMARC reports arrive as raw XML, dense, machine-readable files that are difficult to interpret manually. A busy domain can receive dozens of these files per day from multiple providers. Without tooling, most organizations set up DMARC monitoring and then never actually look at the reports.

This is where a platform like DmarcDkim.com comes in. It ingests your DMARC reports automatically, parses the XML, and presents the data in a clean dashboard, showing you which sources are sending on your behalf, which are failing authentication, and whether any suspicious activity is targeting your domain. It also guides you through fixing misconfigurations and moving toward a stricter DMARC policy over time.

 

Why DMARC Reports Matter for Deliverability

DMARC isn't just a security tool. Reports often reveal that legitimate email sources — your CRM, marketing platform, or transactional email provider — are failing authentication without you knowing. Fixing these issues directly improves inbox placement, since major providers like Google and Yahoo increasingly filter email from domains without proper authentication.

 

The Bottom Line

DMARC reports give you visibility you don't have by default. They show you who is sending email from your domain, catch misconfigurations that hurt deliverability, and alert you to spoofing attempts before they reach your customers. Without them, your domain is an open book for anyone who wants to impersonate you.

Setting up DMARC takes minutes. Reading the reports, with the right tool ,takes seconds. Without - weeks.