Who are the unknown sources in my DMARC reports?

Every DMARC aggregate report lists IP addresses you've never heard of. Some are harmless, some are services your colleagues signed up for, and some are people forging your domain. This guide shows how to tell them apart quickly, using reverse DNS, network ownership, volume and the SPF and DKIM results in each row, and what to do once you know. If you're new to the report format itself, start with how to read DMARC reports.

Why do DMARC reports show IPs you don't recognize?

A report is a receiver's view of every message it saw with your domain in the From address. RFC 9990 defines source_ip as "the connecting IP address", which means the last server that handed the message to that receiver. That isn't always the server that created the message.

So a single message from your own mailbox can show up under an IP you've never seen, if a forwarder, an alias or a mailing list delivered it. And anyone on the internet can put your domain in a From line, so spoofed mail appears too. Google describes reports as showing "which servers or third-party senders are sending mail for your domain", and notes they "can alert you to potential spammers".

Unknown sources fall into four groups:

How do you identify an unknown sending IP?

Work through each unfamiliar source in this order. Our free DMARC Report Analyzer groups a report's rows by source IP in your browser, which makes the list much shorter before you start.

1. Reverse DNS. Look up the IP's PTR record with the PTR Lookup. Mail servers run by real providers usually have a hostname that names the provider. A generic name built from the IP address, or no PTR at all, suggests a home connection or a cheap virtual server. Our guide to reverse DNS for mail servers explains what a good PTR looks like.
2. Network owner. Query the regional internet registry. ARIN's RDAP service answers queries of the form https://rdap.arin.net/registry/ip/<address> with JSON that includes the network name and the organization it's registered to. ARIN calls RDAP "a Whois alternative for querying Internet resource registration data", and it redirects queries for addresses held by other registries to the right one. The owner tells you whether you're looking at a mail provider, a cloud host, an ISP or a university.
3. Volume and timing. Compare the count with what you'd expect. A handful of messages a day from one IP looks like a forwarded mailbox. Hundreds of messages, once, from many unrelated networks looks like a spoofing run.
4. The raw results in auth_results. Check which domain SPF was evaluated for and which d= domains signed. This is the most telling step, covered in the next section.
5. The reason element. If alignment failed and the receiver applied something other than your published policy, RFC 9990 says the row must include a reason. mailing_list means "local heuristics determined that the message arrived via a mailing list", and trusted_forwarder means a match against "a locally maintained list of known and trusted forwarders". RFC 8617 suggests receivers report ARC-based decisions as local_policy with a comment, so look there too.

Keep a simple sender inventory as you go: IP range, owner, which service it is, who in your company uses it, and whether it's fixed. You'll see the same sources every week.

What do the SPF and DKIM results tell you?

The pattern of passes and failures usually identifies the group faster than the IP does.

Aligned DKIM passes, SPF fails: forwarding

A DKIM signature with d= set to your domain can only be created by a system holding your private key. If that signature verifies at the receiver, the message came from you, unchanged. The unknown IP simply relayed it. RFC 9989 explains that forwarded mail "will most likely fail SPF checks" while "DKIM signatures will generally remain valid".

These rows already pass DMARC through DKIM. Leave them alone. The forwarding guide explains the mechanics.

Everything fails, from a list host: mailing lists

Lists resend posts from their own servers and often add a subject tag or footer, which breaks your signature. Low, steady counts that match how often your staff post, from servers belonging to a university, a project or a list hosting service, are typical. The mailing lists guide covers when that matters for p=reject.

SPF passes for someone else's domain: a third-party service

If SPF passed but envelope_from is a domain like bounces.someservice.example, and DKIM is missing or signed with the service's own domain, you've found a service sending as you. It might be a CRM, a helpdesk, an invoicing tool, a survey platform or a website plugin that nobody told IT about. Microsoft's report guidance calls this a legitimate service "with wrong MAIL FROM domain" and gives the fix: use your domain in MAIL FROM, or "set up DKIM signing with your domain".

Nothing passes, from scattered networks: spoofing

No DKIM signature for your domain, SPF failing, sources spread across residential ISPs and hosting providers, often in bursts. Microsoft's guidance describes "Unknown IP, high volume, all fails" as a "potential spoofing/phishing campaign" and says "No action needed. Your DMARC policy is protecting recipients." That's only true once your policy enforces. At p=none, receivers deliver this mail by their own judgment.

What should you do with each type of source?

Forwarders and mailing lists

Usually nothing. Make sure every service you control signs with aligned DKIM, because DKIM is what survives the hop. If you run Microsoft 365 and your own inbound mail passes through an outside service that modifies it, that's a separate inbound problem; trusted ARC sealers and Enhanced Filtering cover it.

Services someone in your company uses

1. Find the owner. Ask finance, sales, support and marketing. The service's name is often in the PTR or the envelope_from domain.
2. Decide whether it should send as your domain at all. If not, have it send from its own domain.
3. If it should, turn on custom-domain DKIM in the service so it signs with d= set to your domain, and set a custom return-path if it offers one. Add it to SPF only if it uses your domain as the envelope sender, and watch the 10-lookup limit. Our SPF records by provider pages list the exact values for common services.
4. Consider a subdomain such as mail.example.com for bulk or automated tools. See separate subdomains for transactional and marketing email.
5. Confirm the fix in the next week's reports.

Spoofers

Don't try to block IPs one by one at other people's mail servers; you can't. Your DMARC policy is the instruction receivers act on. Once every legitimate source passes, move to enforcement as described in moving DMARC from p=none to p=reject. Choosing between the two enforcing policies is covered in DMARC quarantine vs reject.

If spoofed mail is also landing in your own staff's inboxes, that's a job for your inbound filtering. Someone sending email from my address explains both sides.

What if you can't tell?

Some sources stay ambiguous. A few messages from a residential IP that pass SPF because the IP sits inside a broad range in your SPF record. A cloud server that fails everything but sends a steady trickle during business hours.

Treat these as a short investigation list:

• Check your SPF record for broad ranges. RFC 9989 section 7.1 warns that historically lax enforcement of SPF led many domain owners "to publish extremely broad records containing many extensive network ranges". If an unknown IP passes SPF, find out which mechanism authorized it with the SPF Checker.
• Check the IP's reputation. The Blacklist Checker shows whether public blocklists list it. A listed IP sending as you is more likely abuse than a forgotten tool.
• Ask about devices and home workers. A printer, a scanner or a script on someone's laptop can send directly from an office or home connection. Low counts from an ISP address in your own city are often this.
• Look for a pattern over time. One report is a snapshot. A source that appears every weekday is a system; one that appears once is more likely abuse.

How often should you review unknown sources?

During your p=none stage, review weekly. RFC 9989 section 5.1.5 says monitoring mode exists "to ensure that nothing's been missed in the initial SPF and DKIM deployments", and section 5.1.7 warns it "may take many months of consuming DMARC aggregate reports" for some domains to be sure. Microsoft suggests reviewing aggregate reports "weekly during initial deployment; monthly once stable".

After you enforce, keep looking monthly. New tools show up in reports before anyone tells IT about them. A new legitimate source failing DMARC after enforcement means its mail is being junked or rejected, which is usually how you find out.

Remember that coverage isn't complete. Not every receiver sends reports, and a report only shows mail that receiver saw. A source missing from your reports isn't proof it doesn't exist.

A quick triage checklist

1. Group rows by source IP and sort by message count.
2. Mark every IP that belongs to a provider you knowingly use. Those should pass with aligned DKIM.
3. For each remaining IP, look up its PTR and network owner.
4. Check auth_results: aligned DKIM pass means forwarding; SPF pass for another domain means a service; nothing passing means spoofing or an unauthenticated tool.
5. Read any reason element.
6. Fix or retire each real service, ignore forwarders and lists, and leave spoofers to enforcement.
7. Re-check next week.

Next steps

• Load your latest report into the free DMARC Report Analyzer and work through the checklist above.
• Look up each unfamiliar IP with the PTR Lookup, then confirm your records with the SPF Checker and DKIM Checker.
• If a known service keeps failing, work through why DMARC fails.
• iBlockSpam's domain monitoring alerts you when your SPF or DMARC record changes, so a new service added to SPF doesn't go unnoticed. Its DMARC monitoring reads your aggregate reports every day and flags unknown senders and likely spoofing, so you don't have to work through each XML file by hand.

Browse more guides on running email day to day.