HomeBlogAboutLog in

How to Read DMARC Aggregate Reports to Catch Third-Party Alignment Failures

Key Takeaway

A DMARC aggregate report is a receipt for your email. It lists every server that sent mail as your domain and whether that mail passed. When a third-party tool breaks alignment, the report points straight at the IP address behind it. Learn to read that file and you can find the guilty sender fast.

Why Most People Never Open These Files

A DMARC aggregate report lands in your inbox as a gzip attachment. You unzip it and get raw XML full of angle brackets and rows of cryptic fields.

It looks like machine noise. So people archive it and move on. That is exactly how a spoofing problem or a broken newsletter keeps costing you money without anyone noticing.

The DMARC standard was published as RFC 7489 in 2012. Aggregate reports are the rua stream, which stands for Reporting URI for Aggregate reports.

The core idea: one report covers one day from one receiving provider. Patterns show up only across several files.

What Is Actually Inside A DMARC Aggregate Report

Each record holds a handful of fields: the source IP that sent the mail, the number of messages, the SPF result and the DKIM result. Then a header with your domain and the policy you published. That is all you need.

Here is a trimmed example. Real files carry many more records.

<record> <row> <source_ip>198.51.100.24</source_ip> <count>1482</count> <policy_evaluated> <disposition>none</disposition> <dkim>fail</dkim> <spf>pass</spf> </policy_evaluated> </row>
</record>

Read that and you already know a lot. One IP sent 1,482 messages, with SPF passing and DKIM failing. Something is off with the signature on that stream.

Step By Step: Reading The Report To Find The Failing Sender

1. Grab the reports and unzip them

Log into your rua mailbox. Download the attachments. Unzip each file and open the XML in a text editor or a report viewer. Do not skim the summary email some tools send. Go to the source data.

2. Read the policy line first

Look for <policy_published>. It shows your domain and your p value. If p is none, mail is not blocked. If p is reject, failing mail may already be bouncing. That single letter changes how urgent the fix is.

3. Find the rows that failed

Search for fail inside the policy_evaluated block. Each hit is a stream that did not line up with your domain. Note the source IP next to it.

4. Map the IP back to a real sender

Copy the IP into a lookup tool. It will name the owner. You might see your CRM, your billing platform, your help desk or a marketing tool. Now you have a name instead of a number.

5. Check SPF alignment

SPF passes when the sending server sits on your SPF record. Alignment is a stricter test. The domain in the envelope must match your From domain or a subdomain you set up.

Many tools send from their own bounce domain. SPF passes for them. Alignment fails for you. That split is the trap most people miss.

6. Check DKIM alignment

DKIM passes when the signature validates against a public key in DNS. Alignment means the d= domain on that signature matches your From domain.

If a vendor signs as their own domain, your DKIM check shows fail even though their signature is valid. The report cannot tell you that. Your job is to notice the mismatch and ask the vendor for a custom signing domain.

7. Confirm which domain is misaligned

Look at the <identifiers> block. It shows the header From domain and the envelope From. Compare them. When they differ, you have found the exact place your alignment breaks.

8. Fix the weakest stream

Start with the highest count. A sender pushing 90,000 messages a month matters more than one sending 40. Fix the big one, then move down the list.

Keep in mind: SPF allows a maximum of 10 DNS lookups. A bloated SPF record that trips this limit can fail silently and the report will show it as an S

Two Mistakes That Waste Your Time

Mistake one: chasing every failing IP at once. You will drown. Fix the sender with the biggest message count.

Mistake two: assuming a pass means all is well. DKIM requires at least a 1024-bit key and 1024 is weak in practice. Push vendors toward 2048. A passing report on a thin key still leaves you exposed.

What To Do Next

Pick one report from last week and look up the IP behind its highest failing count. In about 15 minutes you will know which tool is hurting your deliverability.

Then email that vendor and ask two questions. Do you offer a custom return-path domain? Will you sign with a domain I control? The answers decide whether the fix is a DNS record or a new sender.

That is how DMARC aggregate reports turn a vague fear into a clear to-do list.

Read the full guide: Fix DMARC Failure: A Case Study in Third-Party Email Alignment