Reading DMARC XML Reports: What source_ip and policy_evaluated Reveal

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.

1. None means the message was delivered normally
2. Quarantine means the message was routed to Spam or Junk
3. 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.