31 Jul 20267 minutes read
SendmarcReading DMARC XML Reports: What source_ip and policy_evaluated Reveal
DMARC XML reports overview:
source_ipis the first thing to check; unrecognized IPs need attribution before remediationpolicy_evaluatedreflects alignment, not just authentication, so a fail here doesn’t mean the signature itself is invaliddisposition: rejecton a recognized, high-volume IP needs same-day remediation- A monthly review of new IPs, DKIM-only passes, and SPF coverage turns report data into intelligence
Your DMARC XML reports generate data every day. Most enterprise teams never extract the information that matters and miss alignment failures that signal active spoofing or impersonation attempts.
If aggregate reports are sitting in a mailbox or being parsed by a tool that isn’t configured to alert on anything meaningful, that’s data without action. This guide focuses on the fields inside DMARC XML reports that matter most: source_ip, policy_evaluated, disposition, and auth_results. Together, they point to infrastructure drift, unauthorized senders, and misconfigured services.
Interpreting DMARC XML reports at enterprise scale means moving past manual, one-domain-at-a-time review. Sendmarc’s DMARC Management Platform surfaces source_ip and policy_evaluated outcomes across every domain, so review doesn’t depend on opening XML attachments individually.
Why source_ip is Your First Diagnostic Stop
A DMARC XML report looks like this:
<record>
<row>
<source_ip>203.0.113.45</source_ip>
<count>120</count>
<policy_evaluated>
<disposition>quarantine</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>yourdomain.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>yourdomain.com</domain>
<result>fail</result>
<selector>20150623</selector>
</dkim>
<spf>
<domain>yourdomain.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>The first question is always: Is that IP recognized? If not, that’s not a footnote; it’s an investigation trigger.
In enterprise environments with multiple cloud services and third-party senders, unfamiliar source IPs appear regularly. Some are legitimate services that marketing or HR set up without notifying IT. Others are newly onboarded SaaS tools not yet added to the SPF record. A small number may be unauthorized.
For each unfamiliar source_ip, run a reverse DNS lookup and check it against the authorized sender inventory. An IP that resolves to a known vendor not yet authorized points to a configuration gap. An IP that resolves to unrecognized infrastructure should be escalated.
Reading policy_evaluated: What the Receiving Server Actually Did
The policy_evaluated block is where the receiving server documents its decision. It contains three sub-fields: disposition, dkim, and spf. These reflect alignment, not just authentication.
dkim: pass or fail. A fail here means either no valid DKIM signature was present, the signature didn’t match the “From” domain (an alignment failure), or the signature broke in transit, often caused by message rewriting.
spf: pass or fail. A fail here in the policy_evaluated block means the SPF-authenticated domain didn’t align with the “From” header.
disposition: The outcome the receiving system applied. Three values are possible: none, quarantine, and reject.
- None means the message was delivered normally
- Quarantine means the message was routed to Spam or Junk
- Reject means the message was blocked outright
The combination of these three fields shows what’s happening and what it costs. A row with disposition: reject, dkim: fail, and spf: fail across a recognized IP is a misconfiguration actively blocking messages. That row needs remediation today, not at the next monthly review.
Diagnosing Common Field Combinations in DMARC XML Reports
Certain patterns in DMARC XML reports repeat across enterprise environments. Understanding what each combination signals speeds up triage.
SPF: pass, DKIM: fail, disposition: none
Policy is p=none. Authentication is partially working: SPF is passing alignment, but DKIM isn’t signing correctly. Before moving toward p=reject, this IP needs a valid DKIM signature. Check whether the sending service has DKIM enabled and whether the signing domain aligns with the “From” domain.
SPF: fail, DKIM: pass, disposition: none
SPF alignment fails because the envelope sender domain doesn’t match. This source will survive enforcement if DKIM alignment continues to pass, but confirm the DKIM key is managed internally, not solely by the vendor, so it can be rotated when needed.
SPF: fail, DKIM: fail, disposition: quarantine or reject
Urgent on a recognized IP. Either the IP was recently added without SPF record updates, the DKIM key was removed, or the service is misconfigured. Cross-reference with SMTP delivery errors surfacing in parallel.
SPF: fail, DKIM: fail, disposition: none, from an unrecognized IP
Policy isn’t enforced yet, but this may be an unauthorized sender using the domain. If the IP can’t be attributed to a known service, treat it as a potential impersonation attempt and investigate.
Monthly DMARC XML Report Review Checklist
A structured monthly review turns raw DMARC XML report data into intelligence.
Use this checklist as a baseline:
- New source IPs: Identify any IPs not present in last month’s DMARC XML reports, and map each to a service or escalate for investigation
- DKIM-only passes: Flag senders passing only on DKIM alignment, and confirm those DKIM keys are controlled internally rather than by a third-party vendor
- SPF record coverage: Cross-reference authorized source IPs against the published SPF record; an IP that passes SPF but isn’t in the record may be authorized through a third-party
include
How Sendmarc Helps
Reading DMARC XML reports at scale takes more than a script that parses RUA files. Sendmarc consolidates report data across every managed domain, surfaces new and anomalous source_ip entries with alerting, and maps policy_evaluated outcomes to the authorized sender.
For teams managing multi-domain deployments or MSP portfolios, it removes the manual bottleneck of opening XML attachments domain by domain and helps prevent alignment failures from sitting undetected between review cycles.
This directly assists stretched security and IT teams by providing unified visibility into SPF, DKIM, and DMARC configurations across every domain, faster identification of unauthorized or unknown senders, and less manual investigation of misconfigurations and suspicious emails.
Coverage extends across distributed, multi-tenant, and regional environments without adding to internal workload, which matters for teams that need continuous monitoring without continuously growing headcount.
If the current process involves downloading DMARC XML reports and filtering them in a spreadsheet, explore Sendmarc’s DMARC Management Platform to see how centralized analysis replaces manual review at enterprise scale.
