How to Read a DMARC Aggregate Report Without Being an Email Engineer

How do you read a DMARC aggregate report without being an email engineer?

Open the XML, find each record, and read four things: the sending IP address, the message count, whether SPF and DKIM passed in alignment with your From domain, and what the receiving server did with the mail. Then match each IP to a service you know. Anything you cannot match is either a forgotten tool or someone spoofing you.

This tutorial is for a marketer, founder, or RevOps lead at a small B2B company who added a DMARC record to their domain, maybe while setting up outbound, and now gets a daily stream of emails with zipped XML files attached. Nobody reads them. They pile up in a shared inbox, and the DMARC policy stays at monitor-only forever.

That is a waste. Those reports are the only place you can see every system sending email as your domain. Reading them takes less skill than it looks, and it is the step that lets you move from monitoring to actually protecting your domain.

What is a DMARC aggregate report?

It is a summary that receiving mail servers send you about email that claimed to come from your domain. Google's Workspace documentation says reports are typically sent once a day, by every server that receives mail from your domain, to the address in the rua tag of your DMARC record. The raw reports are in XML format.

Each report covers a time period and one receiving organization, such as a large mailbox provider. Inside, it groups messages by sending IP address and tells you how they fared against SPF, DKIM, and DMARC. It does not include message content. It is metadata about authentication, which is exactly what you need.

If your rua address sits on a different domain from the one the DMARC record protects, Google's documentation notes you must add a DNS record at that other domain to accept the reports. That is a common reason reports never arrive when people point them at a third-party mailbox.

Step 1: Where do you find and open the reports?

Look in the mailbox named in the rua tag of your DMARC record. Google recommends using a dedicated group or mailbox for these reports. The attachments usually arrive compressed. Unzip one, and open the XML file in any text editor or a browser, which will show the structure even if it looks dense at first.

If you do not know which mailbox receives reports, look up your DMARC record. It lives as a TXT record at the name _dmarc followed by your domain. Any DNS lookup tool will show it. The rua value after mailto is the address you need.

Do not try to read every report every day by hand. For the first week, open one report from a major mailbox provider each day. That gives you a representative picture of how your domain's mail is doing without drowning in files.

Step 2: What does the report header tell you?

The top of the file holds report_metadata and policy_published. The metadata names the organization that sent the report and the date range it covers. The published policy section repeats the DMARC policy the receiver saw for your domain, which is a quick way to confirm your DNS record is what you think it is.

Check the published policy first. If it shows a policy you did not expect, or a different reporting address, your DNS may have an old or duplicate record. Fix that before interpreting anything else, because every result below depends on the policy the receiver actually applied.

Note the date range too. Reports cover a window of time, so a problem you fixed this morning may still appear in yesterday's report. Compare across a few days before concluding a fix did or did not work.

Step 3: How do you read each record?

Each record holds a row with a source_ip, a count, and a policy_evaluated section. The source IP is the server that sent the mail. The count is how many messages came from it in the period. The policy_evaluated section shows the DMARC results for DKIM and SPF and the disposition, which records what the receiver did with those messages.

Below the row, the identifiers section shows the header_from domain, the domain in the visible From address. The auth_results section shows the raw SPF and DKIM checks, including which domains were checked. Those raw results explain why the evaluated results came out the way they did.

Read records in order of count, largest first. Your main email provider and your marketing platform will usually account for most of the volume. Small counts from unfamiliar IPs are where forgotten tools and spoofing attempts tend to show up.

Step 4: What is alignment, and why does it matter?

Alignment means the domain that passed SPF or DKIM matches the domain in your visible From address. The DMARC specification, RFC 7489, describes this as identifier alignment. A message can pass SPF or DKIM for some other domain and still fail DMARC, because the passing domain is not aligned with yours.

This is the part that confuses most people. A tool like a CRM or a sequencing platform may sign mail with its own domain by default. SPF and DKIM pass, so everything looks fine, but DMARC fails because the passing domain belongs to the vendor, not you. The fix is usually to set up the tool's custom sending domain or DKIM for your domain.

In the report, compare the evaluated dkim and spf results with the domains in auth_results. If auth_results shows a pass for a vendor's domain while the evaluated result fails, you have found an alignment problem, and the vendor's documentation on authenticating your domain is your next stop.

Step 5: How do you match IPs to the tools that send for you?

List every service that sends email as your domain: your main mailbox provider, marketing email tool, CRM, sequencing tool, support desk, billing system, and any app that sends notifications. Then match each source IP in the report to one of them, using a reverse lookup or the vendor's published sending ranges.

Most teams find at least one surprise. A billing tool someone set up years ago, a form tool sending notifications, or an old marketing platform nobody canceled. Each one either needs proper authentication for your domain or should stop sending as your domain altogether.

Anything you cannot match after checking every known service deserves a closer look. It may be a legitimate tool someone forgot to mention, or it may be someone sending mail that pretends to be you. Either way, it is exactly what DMARC reports exist to show.

Step 6: When should you move from monitoring to enforcement?

Once every legitimate sender passes with alignment and you have reviewed reports for a while. Google's recommended rollout is to start with a policy of none for one week while reviewing reports daily, then move to quarantine for a small percentage of messages using the pct tag, and raise it over time until it covers all mail.

Google's documentation notes you can use reject instead of quarantine if required. Under reject, receiving servers reject messages that fail DMARC, so they are never delivered. Only move there when you are confident every legitimate sender is aligned, because a missed tool will have its mail blocked.

For teams running outbound on a separate domain, the same logic applies to that domain. I covered the initial setup in cold email domain setup before the first send, and DMARC reports are how you confirm that setup is still working months later.

How do you keep reading reports without it becoming a chore?

Use a tool after the first few weeks. Google's documentation suggests considering a third-party DMARC service that can receive, store, and analyze reports, because raw XML is hard to interpret at volume. A dashboard that groups senders and flags new IPs turns a daily chore into a quick weekly check.

Pair DMARC reports with other signals. Google Postmaster Tools gives you another view of how Gmail treats mail from your domain. I walked through it in setting up Google Postmaster Tools for an outbound domain. Together, they show whether your mail is authenticated and whether recipients treat it well.

Assign an owner. Someone on the team, usually whoever owns your GTM stack or IT, should check the summary weekly and investigate new senders. When a new tool is added that sends email, that person makes sure it is authenticated before it goes live.

What should you do next?

Find the mailbox in your DMARC rua tag, open one recent report, and read each record for source IP, count, alignment, and disposition. List every tool that sends as your domain and match them to the IPs. Fix alignment for each legitimate sender, then follow Google's staged rollout toward enforcement.

I build the outbound and CRM systems that send email on behalf of B2B teams, and domain authentication is part of getting them right. If you want help reading your DMARC reports or fixing alignment for your sending tools, reach out at pravinkumar.co and let's chat.