How to Read a DMARC Aggregate Report

What a DMARC aggregate report tells you

A DMARC aggregate report is an XML feedback file from a participating mailbox provider. It is usually compressed and often covers a reporting window such as a day, but the exact timing depends on the receiver and your DMARC reporting tags.

The report shows which IPs sent mail using your domain, whether SPF and DKIM passed, whether either result aligned with the visible From domain, and what the receiver did under your published DMARC policy. It is not a message-by-message inbox placement report. It usually will not show subject lines, message bodies, or individual recipients. It answers a narrower and useful question: who is sending as your domain, and did that traffic pass DMARC?

DMARC builds on SPF and DKIM. SPF checks whether the sending server is authorized by the SPF record for the envelope sender domain, or HELO domain in limited cases. DKIM checks whether the message has a valid cryptographic signature tied to a DNS selector. DMARC then checks alignment with the domain in the visible From header. A message passes DMARC when SPF passes and aligns, DKIM passes and aligns, or both. If both aligned checks fail, your published DMARC policy tells the receiver what handling you prefer.

• p=none: monitor and collect reports, but do not ask receivers to block failing mail because of DMARC.
• p=quarantine: ask receivers to treat failing mail as suspicious, commonly by placing it in spam, junk, or another restricted area.
• p=reject: ask receivers to reject failing mail rather than accept it when they honor your policy.

Aggregate reports are sent to the addresses in the rua= tag when the receiver supports reporting. Receivers can still apply local policy, so the DMARC disposition in a report is not a promise that every similar message reached the inbox or was blocked the same way everywhere.

Mailbox providers like Gmail and Outlook still make their own delivery decisions. Authentication helps you avoid rejection and spam placement, but it is not a guarantee of inbox placement. Reputation, complaint rate, content, volume patterns, user engagement, blocklists, and local provider policy still matter. Use DMARC reports to find authentication failures first, then test deliverability from real sending systems.

The fields to read first

Most DMARC aggregate reports contain the same building blocks: report metadata, the policy the receiver found in DNS, and one or more records grouped by sending IP and authentication outcome.

• report_metadata: the reporting organization, report ID, and date range covered. This tells you whether the report came from Google, Microsoft, Yahoo, or another receiver, and which period it describes.
• policy_published: the DMARC record the receiver saw for your domain, including p=, sp=, adkim=, aspf=, and sometimes older or receiver-specific fields. Some RFC 7489-era records and reports include pct=, but the current DMARC standard, RFC 9989, removed that tag, so do not depend on it without checking current receiver guidance.
• record / row / source_ip: the IP address that sent the mail seen by that receiver. This is usually the first clue when a tool, CRM, help desk, store, or attacker is sending as you.
• count: how many messages matched that source IP and result combination during the reporting window. Fix high-volume legitimate failures before low-volume noise.
• policy_evaluated: the receiver's DMARC result for the row, including disposition, DKIM alignment result, SPF alignment result, and any override reason.
• identifiers / header_from: the visible From domain. DMARC protects this domain, not just the envelope sender.
• auth_results: the raw SPF and DKIM results the receiver saw, including DKIM domains and selectors when reported.

Start with rows where count is meaningful and policy_evaluated shows both DKIM and SPF as fail. If the source is one of your real services, the sender needs to be authenticated and aligned. If the source is unknown, the report may be showing spoofing, forwarding, or a system you forgot you had.

How to diagnose each row

Read each row as a simple decision tree. Do not start by changing your DMARC policy. First decide whether the traffic is legitimate, then fix the authentication path that should be carrying it.

• Identify the sender. Map the source IP and volume to a service: Google Workspace, Microsoft 365, Shopify, HubSpot, Zendesk, a marketing platform, an app server, or an unknown sender. Reverse DNS and the provider's documented sending ranges can help, but your own sending inventory is the source of truth.
• Check SPF. SPF passes when the SPF-authenticated domain authorizes the sending server. For your visible From domain to pass DMARC through SPF, that SPF-authenticated domain must also align with the From domain. Make sure your SPF record includes the real sender and stays under SPF's 10 DNS-lookup limit for mechanisms and modifiers that cause lookups, such as include, a, mx, ptr, exists, and redirect. An SPF record ending in ~all returns softfail for unauthorized senders. -all returns fail, often called hardfail. Many domains start with ~all while auditing, then tighten once legitimate senders are known.
• Check DKIM. DKIM passes when the message has a valid signature and the receiver can find the public key at the selector in DNS, usually at a name like selector._domainkey.example.com. For DMARC, the DKIM signing domain in d= must align with the visible From domain. If DKIM fails, look for missing selectors, disabled signing, broken DNS, message modification after signing, or a platform signing only with its own domain instead of yours.
• Check alignment. A raw SPF pass or raw DKIM pass is not always a DMARC pass. The authenticated domain has to match the From domain, or share the same organizational domain under relaxed alignment. Strict alignment requires an exact domain match. Most domains should understand the failure pattern before changing adkim or aspf.
• Check MX separately. MX records tell the world where inbound mail for your domain should go. MX does not make outbound mail pass DMARC, but bad or stale MX can cause missed replies, bounces, and operational confusion while you are debugging deliverability.
• Check blocklists and reputation. A row can pass DMARC and still land in spam if the sending IP or domain has poor reputation. DMARC reports prove authentication status, not inbox placement. If authentication is clean but Gmail or Outlook still routes mail to spam, inspect complaint rates, bounce rates, list quality, content, sending spikes, unsubscribe handling for marketing mail, and provider-specific postmaster guidance.

For a quick plain-English check of SPF, DKIM, DMARC, MX, and common deliverability risks, run your domain through the free InboxRadar domain scorecard. Use the report to find the exact DNS or sender configuration to fix, then confirm the change in later DMARC aggregate reports.

A practical reading workflow

The fastest way to use aggregate reports is to turn them into a sender inventory. You are looking for legitimate senders that fail, legitimate senders that pass only one method, and unknown senders that should be blocked by enforcement.

• 1. Sort by volume. A source IP with 12,000 failing messages deserves attention before a source with 2. High-volume failures are usually a real platform that was never configured correctly.
• 2. Label each source. Mark every row as known good, unknown, forwarded, or suspicious. Do not enforce reject until the known-good list passes DMARC consistently.
• 3. Fix one sender at a time. For each known-good sender, configure SPF and DKIM according to that provider's official instructions. Prefer aligned DKIM when possible because DKIM usually survives more forwarding paths than SPF.
• 4. Watch later reports. DMARC aggregate reports normally arrive after the receiver's reporting window closes. Expect confirmation in a later report, not instantly.
• 5. Move policy in stages. Start at p=none while collecting data. After legitimate senders pass, move to p=quarantine for the domain or for carefully chosen subdomains. Move to p=reject only when normal mail is aligned and monitored.
• 6. Keep monitoring. New SaaS tools, CRM changes, support desks, and domain migrations can break alignment months later. DMARC reports are most valuable when they are watched for drift, not read once.

When you document findings, include the source IP, provider name, message count, SPF result, DKIM result, alignment result, and action needed. That gives your DNS owner or vendor support team enough context to fix the issue without guessing.

Common patterns and what they mean

Most DMARC report surprises fall into a few repeatable patterns. These are the ones to look for before you escalate to a vendor or change policy.

• SPF passes, DMARC fails. The envelope sender passed SPF, but the SPF domain did not align with your visible From domain. Configure a custom return-path or bounce domain if the provider supports it, or rely on aligned DKIM instead.
• DKIM passes, DMARC fails. The message was signed, but the DKIM d= domain did not align with your From domain. Enable branded DKIM for your domain in the sending service.
• SPF fails, DKIM passes, DMARC passes. This is usually acceptable because DMARC needs at least one aligned pass. Still fix SPF if the sender is important, because some receivers and security tools score multiple signals.
• Both SPF and DKIM fail from a known service. The service is sending before DNS setup is complete, a selector is missing, an SPF include is absent, or the service is using a default shared domain. Fix before moving beyond p=none.
• Unknown IPs keep appearing after enforcement. That may be spoofing that your policy is now catching. Keep monitoring counts and receiver disposition. A reject policy can reduce abuse, but receivers may still apply local policy.
• Authentication passes but users report spam placement. DMARC is not the whole deliverability story. Check Google and Microsoft sender guidelines, spam complaint rates, unsubscribe handling for marketing mail, bounce rates, blocklists, and sending consistency.

The official standards are the best reference when you need exact behavior: RFC 7208 for SPF, RFC 6376 for DKIM, RFC 7489 for the original DMARC specification, and RFC 9989 for the current DMARC standard. For current mailbox-provider rules, use the published Google sender guidelines and Microsoft email authentication guidance rather than copying old blog advice.