Learn · Email authentication
Source IPs in DMARC reports, explained
Every row of a DMARC aggregate report starts with an IP address, a message count, and one question: is this server mine? The IP itself carries more evidence than most people expect. Reverse DNS, geolocation, network ownership and threat reputation turn "203.0.113.7, fails everything" into "a flagged rented server in a hosting network on another continent" — which is usually all you need to decide.
Four kinds of evidence an IP carries
- Reverse DNS (PTR) — the name the server's operator gave it, which often identifies the service directly.
- Geolocation — the country and city the address is registered and observed in.
- Network ownership (ASN) — which organisation announces the address block, and what kind of network it is.
- Threat reputation — whether the address appears in threat-intelligence feeds: Tor exit nodes, open proxies, addresses seen attacking or spamming.
None of these is a verdict on its own. Combined with the SPF/DKIM results in the report, they almost always are.
Reverse DNS: the server's own name
A PTR record maps an IP back to a hostname. Well-run mail infrastructure always has one, and it's usually self-describing: mail-sor-f41.google.com is Google, o1.email.sendgrid.net is SendGrid, a8-30.smtp-out.amazonses.com is Amazon SES. This is how a monitoring tool can label a bare IP "Google Workspace" or "Mailchimp" — the big platforms and ESPs are instantly recognisable.
Two caveats. A missing or generic PTR (static-45-83-122-19.example-isp.net) doesn't prove anything bad — small self-hosted mail servers often have lazy PTRs. And the operator of an IP controls its own PTR, so a spoofer can name their server anything; the PTR identifies the operator, it doesn't authenticate the mail. Authentication is what SPF and DKIM are for.
Geolocation: where it sends from
IP geolocation comes from regional address registries plus commercial measurement, and it's city-approximate at best. Its value in DMARC triage is cluster sanity: your legitimate senders should map to places that make sense — your ESP's sending regions, your office, your cloud region. A burst of mail claiming to be your Brisbane accounting firm, sent from addresses scattered across residential networks on three continents, tells its own story.
Don't over-read it in the other direction: global platforms send from everywhere (Google mail for an Australian domain routinely leaves US or European data centres), so an unexpected country on a passing, identified sender means nothing. Geography is supporting evidence for rows that are already suspicious, not a filter.
The network behind the IP: ASN
Every public IP belongs to an address block announced by an autonomous system — a network with an AS number, like AS15169 (Google) — and each AS has a broad type: ISP (consumer/business connectivity), hosting (rented servers and VPSes), business (a company running its own network), plus education and government. This is often the single most useful field on an unknown row:
- Your mail should come from mail networks. Corporate mail arrives from your platform's AS (Google, Microsoft), bulk mail from your ESP's AS. These are stable and recognisable.
- "Hosting" cuts both ways. Your own application server on AWS or Hetzner is a hosting ASN — legitimate, and worth adding to SPF or signing with DKIM. An unknown hosting IP failing both checks is the classic signature of a compromised VPS being used as a spam cannon.
- Residential ISP addresses sending bulk mail are almost always malware-infected machines in a botnet — real mail platforms don't deliver from consumer broadband.
Threat flags, one by one
Threat-intelligence feeds track addresses observed doing specific things. The flags you'll see on a source, and how to read each:
| Flag | What it means | How to read it |
|---|---|---|
| Tor exit node | The last hop of the Tor anonymity network. | Legitimate mail platforms never deliver via Tor. On a failing row this is about as close to a verdict as a flag gets. |
| VPN | Egress of a commercial VPN service. | On failing mail: someone hiding their origin. On passing mail: usually just a teammate or a service routing through a VPN — not a problem. |
| Proxy | An open or commercial proxy relays traffic through this address. | Same logic as VPN — suspicious on failures, mostly noise on passes. |
| Known attacker | Recently observed attacking honeypots or intrusion-detection sensors. | Strong evidence the address is hostile infrastructure, not a misconfigured vendor. |
| Known abuser | Reported for abuse — spam traps, abuse-desk reports. | Ditto; this address's operator is not going to email you an apology. |
| Threat-listed | Appears on one or more public threat or block lists. | General bad reputation. Weight it with the other signals. |
Flags are evidence, not verdicts. Threat feeds age, IPs change hands, and shared egress (corporate VPNs, carrier-grade NAT) puts innocent traffic behind flagged addresses. A flag on mail that passes DMARC is almost always ignorable; a stack of flags on mail that fails is a story that writes itself. Never make an allow-or-block decision from a flag alone.
Putting it together: a triage recipe
For any row you don't recognise, read the signals in this order:
- Passes DMARC (SPF or DKIM aligned)? Then it's authorised to send as you — the interesting question is which service it is, and the PTR/ASN answers that. Ignore geography and most flags.
- Fails both, hosting or residential ASN, threat flags, implausible geography? Spoofing. There is nothing to fix on your side — this is exactly the mail moving your policy to quarantine and then reject exists to stop. Count it as evidence for enforcing, not a reason to hesitate.
- Fails both, but a clean business or ISP network in a plausible location? Slow down. This is the profile of a real system nobody configured — a ticketing tool, a multifunction printer, a line-of-business app relaying through the office connection. Find it and authenticate it before you enforce, or its mail gets rejected along with the spoofers'.
That last case is the whole reason DMARC rollouts start at p=none: the reports exist to separate "attacker" from "forgotten legitimate sender", and the IP intelligence is what makes that separation fast. Canny Pigeons does the enrichment automatically — expand any source row and the location, network owner and threat labels are already there, on every plan.