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), any reason it overrode your policy, and the SPF and DKIM results, including which domain each one actually authenticated. That’s the raw material. Nothing in the report says who the IP belongs to.

What we look up for each IP

For each new source IP, DMARCLoop looks up:

  • its reverse DNS name (the PTR record);
  • the network it’s routed from (its autonomous system number and name) and the country that network is registered in.

It also keeps the DKIM and SPF domains reports have shown for that IP, leaving out your own domains, since those say nothing about who the sender is. Lookups are refreshed every 30 days. The network and country are shown on a source’s page as context; they are not used to decide who the sender is.

Recognising a known sender

DMARCLoop has a library of about twenty common sending services: mailbox providers such as Google Workspace and Microsoft 365, transactional and marketing senders, CRM, support and accounting tools, and filtering gateways. For each, it knows the domains that service signs or sends with, and the reverse DNS names of its servers. A source is matched in this order:

  1. The DKIM and SPF domains in your reports. If the IP’s mail was signed by, or sent with an envelope domain under, a service’s own domain, it’s that service. This wins over reverse DNS, because a relay’s PTR names the relay rather than the sender.
  2. The reverse DNS name, matched on whole labels: mail.example.net matches a suffix of example.net, but badexample.net doesn’t.

If neither matches, the source is unrecognised. DMARCLoop does not identify senders by network (ASN) or by lists of IP ranges. A large provider’s network also carries its cloud customers’ servers, so a match on the network alone would label any virtual machine there as that provider’s mail service, including one sending spoofed mail as you.

A recognised sender that isn’t passing yet comes with a short fix guide: the SPF include to add, if the service supports aligned SPF, and how to get an aligned DKIM signature.

Sorting sources into four groups

Each source is sorted over the window you’re viewing, by the first rule that fits:

  1. Forwarded, if the sender is a filtering gateway, or receivers marked at least half of its messages as forwarded, mailing_list or trusted_forwarder in their override reasons.
  2. Compliant, if at least 95% of its messages pass DMARC.
  3. Known sender, failing, for any other source the library recognises.
  4. Forwarded, for an unrecognised source where at least half of its messages fail SPF but pass DKIM.
  5. Unknown or threat, for everything else.

The fourth rule is the forwarding signature: a forwarding hop changes the envelope sender, so SPF fails, but leaves the signed message alone, so the original DKIM signature survives. That’s the mechanics described in how SPF and DKIM can pass while DMARC fails. A forwarder that rewrites the message breaks DKIM too, and then lands in Unknown or threat.

Unknown or threat is one group

DMARCLoop doesn’t try to tell an attacker from a service you haven’t set up yet: both are mail it can’t recognise that fails DMARC. They share one group for you to review, with each source’s reverse DNS name, network and pass rate to go on. Separately, alerts flag a new sending source that sends meaningful volume as your domain, and a volume spike well above the usual daily volume, so a sudden change gets looked at.

Where this shows up

This is what turns a report with forty unlabelled IP addresses into a short list: these are your known senders, this one looks like forwarding, these three need a closer look. Convert a report yourself with the XML-to-human Converter to see the raw per-source data it’s built from.