XML to Action: The SOC Analyst's Playbook for Triaging DMARC Reports

Your DMARC `rua` address is collecting a mountain of XML files. For most, this is just compliance noise—a box checked. But for an analyst, this is a raw intelligence feed, delivered daily from the world's largest mail receivers. Buried inside that ugly, verbose XML is a precise map of who is using your domain to send email, both legitimately and maliciously.

The problem is that the raw data is nearly unusable without a process. It’s a mix of true spoofing attempts, legitimate-but-misconfigured third-party services, and benign failures caused by email forwarding. Simply reading the pass/fail results isn't enough. You have to investigate the context.

This is the playbook for turning that mountain of RUA reports into actionable security intelligence. We're moving beyond simple definitions to build a repeatable workflow for categorizing failures, hunting down misconfigurations, and de-risking the move to an enforcement policy.

More Than Just XML: Deconstructing the RUA Report

Before you can triage a Domain-based Message Authentication, Reporting, and Conformance (DMARC) report, you have to learn to read the story it tells. An aggregate (RUA) report, defined in RFC 7489, is not just a list of failures. It’s a structured summary of how a specific mail receiver evaluated messages claiming to be from your domain over a period of time. Don't just scan for `fail`. Look at the entire record.

The core of the story lives inside the `<record>` tags. Each record represents a group of emails with the same source IP, DMARC disposition, and underlying SPF/DKIM authentication results. The `<row>` element contains the source IP address and a `<count>` of how many messages it sent. The `<policy_evaluated>` section is where the verdicts live, showing the DMARC `disposition` (none, quarantine, or reject) and the individual results for SPF and DKIM.

<record>
<row>
<source_ip>209.85.220.41</source_ip>
<count>15</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>yourdomain.com</header_from>
</identifiers>
<auth_results>...</auth_results>
</record> — A typical DMARC record showing a passing DKIM but failing SPF.

Pay close attention to the interaction between the individual results. A record with `spf=fail` and `dkim=fail` is a much stronger signal of potential spoofing than one where one of the two protocols passes. The latter often points to a configuration issue, not an attack.

First Moves: Correlating IP, ASN, and Reporter Data

Your first triage step for any given record is to establish context. Who sent this email, and who is reporting it to you? The answers dramatically change your interpretation of the data.

Who Is the Sender? IP and rDNS Analysis

Start with the `<source_ip>`. A quick reverse DNS (rDNS) lookup is your most powerful first move. An IP that resolves to `o-123.p23.mailgun.net` immediately tells you the sender is Mailgun, a legitimate email service provider. An IP resolving to `c-98-228-15-131.hsd1.mi.comcast.net` points to a residential broadband connection. One is an expected sender; the other is highly suspicious and could be part of a botnet or a compromised home machine used for a Business Email Compromise (BEC) campaign.

Next, check the IP's Autonomous System Number (ASN). Is it owned by Amazon AWS, Google Cloud, or Microsoft? This suggests a cloud-hosted application. Is it registered to a hosting provider known for bulletproof hosting? That's a red flag. This metadata transforms a raw IP address into a profile of the probable sender.

Who Is the Reporter? Understanding Receiver Bias

Just as important is the source of the report itself, found in the `<report_metadata>` section's `<org_name>`. A report from Google, Microsoft, or Yahoo is high-fidelity. These receivers handle a massive percentage of global email, have mature DMARC processing logic, and often support advanced standards like Authenticated Received Chain (ARC). Failures reported by them are likely real.

Conversely, a failure report from a small, unknown organization running its own on-premise mail server might be noise. Their own mail gateway could be misconfigured, leading to false negatives. Prioritize reports from major receivers first; they give you the cleanest signal.

Signal vs. Noise: Separating Spoofing from Benign Failures

The most common source of DMARC analysis paralysis is the flood of failures caused by indirect mailflows. Not every SPF or DKIM failure is an attack. Many are artifacts of how email works on the modern internet, and your job is to tell the difference.

The Forwarding Problem: When SPF Breaks by Design

SPF, as defined in RFC 7208, breaks with simple email forwarding. Imagine a partner sends an invoice to `accounting@yourcompany.com`, which is a mailing list that forwards to `bob@yourcompany.com` and `alice@yourcompany.com`. The receiving server for Bob and Alice sees the message coming from your mailing list forwarder's IP, not the original partner's IP. It checks the partner's SPF record, sees the forwarder's IP isn't listed, and returns an SPF `fail`. This is a benign failure. It’s not spoofing, it’s just SPF working as specified.

These scenarios are rampant. Mailing lists, legacy forwarding rules, and some outsourced security filters all create the same pattern: an SPF `fail` for a message that is otherwise legitimate. This is why relying solely on SPF for authentication is a recipe for disaster. DKIM, because its signature covers the message body and key headers, is designed to survive forwarding.

ARC as a Clue

Authenticated Received Chain (ARC), specified in RFC 8617, was created to solve this problem. ARC allows an intermediate mail server (like a forwarder) to sign the message's original authentication results before passing it along. The final receiver can then verify this chain and choose to trust the original SPF/DKIM `pass`, even if its own checks fail. When a DMARC report comes from a major provider that supports ARC (like Google), you can have higher confidence in the failure verdicts. The absence of ARC doesn't prove anything, but its presence helps validate the mailflow's history.

Hunting Down Third-Parties with Alignment Issues

Here's where DMARC triage delivers huge operational value: finding all the third-party services sending email on your behalf. These are your marketing platforms, HR systems, and CRM tools. If they aren't configured for DMARC alignment, they will fail DMARC checks even if their SPF and DKIM checks pass.

DMARC requires *identifier alignment*. This means the domain in the visible `From:` header must match the domain used in the SPF check (the `Return-Path` or `MailFrom` address) and/or the domain in the DKIM signature (the `d=` tag). A simple `pass` is not enough.

Consider a report where the `<policy_evaluated>` section shows a DMARC `fail`, but the `auth_results` tell a different story. You might see a `pass` for both SPF and DKIM. How can this be? The answer is an alignment mismatch. The SPF check passed for `bounces.some-crm.com` and the DKIM signature was valid for `d=some-crm.com`, but the email's visible `From:` header was `yourcompany.com`. Since `some-crm.com` does not match `yourcompany.com`, DMARC alignment fails.

<auth_results>
<dkim>
<domain>sendgrid.net</domain>
<result>pass</result>
<selector>s1</selector>
</dkim>
<spf>
<domain>sendgrid.net</domain>
<result>pass</result>
</spf>
</auth_results> — Auth results for a message sent via SendGrid. This will fail DMARC alignment if the From: header is not sendgrid.net.

These are not malicious attacks. They are configuration tasks. Your RUA reports are now a punch list. For each service you identify this way, you need to follow their documentation for custom SPF/DKIM or a dedicated sending subdomain. This process is critical for cleaning up your sending reputation and making `p=reject` viable.

From Triage to Inventory: De-Risking `p=reject`

The end goal of triaging DMARC RUA reports is not just to file them away. It's to build a comprehensive and accurate inventory of every legitimate source of email for your domain. This inventory is your key to confidently deploying an enforcement policy.

For every legitimate source you identify in your reports, add it to a simple spreadsheet or database. Track the service name (e.g., Salesforce, Zendesk), its sending IPs or netblocks, its SPF/DKIM domains, and its alignment status. Note whether it requires configuration changes on your end to achieve alignment.

As you triage reports over several weeks, this inventory will grow. You'll move sources from 'unidentified' to 'known legitimate' or 'known and misconfigured'. The volume of unclassifiable failures should drop precipitously. When your inventory can explain nearly all of your non-aligned, legitimate email volume, the risk of moving to `p=quarantine` or `p=reject` is dramatically reduced. The remaining failures are much more likely to be actual abuse.

Without this inventory, deploying `p=reject` is a blind gamble that will almost certainly cause outages of business-critical email. With it, it's a calculated, evidence-based security control.

Pre-Flight Check: Validating `rua` and `ruf` URI Syntax

A final, often-overlooked step can render this entire process moot: an incorrectly formatted `rua` or `ruf` tag in your DMARC DNS record. If the URI is wrong, or if external reporting isn't authorized, you'll never receive the data you need.

The syntax is more than just `mailto:address@domain.com`. RFC 7489 allows for options, such as a size limit (`rua=mailto:reports@corp.com!10m`). But the most critical part is authorizing third-party reporting. If you use a service like `dmarc-reports@thirdparty.com` to collect your reports, you must publish a special DNS record. The reporting organization will look for a TXT record at `yourdomain.com._report._dmarc.thirdparty.com`. That record must contain `v=DMARC1;` to grant permission.

Without this external domain verification record, most major reporters will simply not send you the reports. You'll have a DMARC policy in place, but you'll be flying blind with no data to triage. Always validate your reporting URIs and permissions before expecting to see any data.

The takeaway

DMARC reports are not a compliance artifact; they are a continuous stream of environmental intelligence. By adopting a systematic triage process, you shift from passively receiving XML files to actively hunting for misconfigurations, discovering shadow IT, and building a definitive inventory of your organization's email footprint.

The process—correlating metadata, separating benign failures from true threats, and fixing alignment issues—builds the evidence base needed to turn on enforcement. This is how you make `p=reject` a safe, effective control against BEC and domain spoofing. While manual triage builds deep expertise, platforms like MailSleuth.AI can automate this correlation and inventory-building process, letting your team focus on the true anomalies.