What’s in an aggregate report

Every DMARC aggregate report (delivered to the address in your record’s rua tag) is an XML document listing, per sending source: the source IP address, a message count, the disposition the receiver applied (none, quarantine, reject), and the SPF and DKIM results — including which domain each mechanism actually authenticated. That’s the raw material. Nothing in the report tells you who the IP belongs to or whether it’s your marketing platform, an old forwarding rule, or an attacker.

Layering identification on top

DMARCLoop resolves each source IP against a few independent signals and combines them:

  • Reverse DNS (PTR records). Many legitimate senders — ESPs, cloud providers, ticketing systems — publish PTR records that name the service plainly. This is the fastest, cheapest identification signal and often enough on its own.
  • ASN lookup. The autonomous system an IP belongs to narrows things down even when PTR is absent or generic: a block ASN-registered to a major email platform is a strong prior.
  • Known-ESP IP-range fingerprinting. DMARCLoop maintains a reference set of published and observed IP ranges for common ESPs and business tools, matched against the source IP directly.

These signals get combined per source rather than trusted individually, since PTR records can be missing or misleading and ASN alone can’t distinguish a specific service from its neighbors on the same infrastructure.

Forwarding has a distinctive signature

Forwarded mail tends to show a specific, recognizable pattern in aggregate data: SPF fails, DKIM passes with the original signing domain intact, and volume is typically low, from a wide scatter of consumer or university IP ranges rather than a concentrated infrastructure block. This matches the mechanics described in how SPF/DKIM can pass while DMARC fails: the forwarding hop breaks the envelope sender (SPF) but doesn’t touch the signed content (DKIM), so the original signature survives if the forwarder doesn’t rewrite the body or signed headers.

Unauthenticated threats look different

Genuine abuse — spoofing attempts, phishing using your domain in the From header — tends to show both mechanisms failing with no alignment on either, sourced from ASNs with no prior legitimate history against your domain, and often arriving in a volume spike rather than the steady trickle a forwarding rule produces. Concentration in time and the absence of any recognizable sending infrastructure are what separate this from forwarding or an unconfigured legitimate sender.

Where this shows up

Source identification is what turns a report with forty unlabeled IP addresses into a short list of “these are your known senders, this one looks like forwarding, these three need a closer look” — the difference between reading raw XML and having a rollout plan. Convert a report yourself with the XML-to-human Converter to see the raw per-source data this is built from.