Unknown IPs in your DMARC report: spoofing or a forgotten sender?

The Email Digit teamUpdated 6 Oct 2026

An IP you do not recognize in your DMARC report is usually one of four things: a service that sends as you which nobody set up properly, a forwarder or mailing list, a server of your own that is misconfigured, or a spoofer. You can tell them apart with a reverse DNS lookup, an owner lookup, the volume, and whether DKIM passed for your domain.

The four usual answers

Source	What it looks like	What to do
A service you forgot	Steady volume from a known provider's network; fails alignment	Authorize it on your domain
A forwarder or mailing list	Small volume from a university, ISP or list host; SPF fails, DKIM often passes	Usually nothing
Your own server	An IP in your own range or cloud account; fails both	Fix it, or route it through an authorized sender
A spoofer	Bursts from unrelated networks; fails both; no DKIM for your domain	Let your DMARC policy handle it

How to tell them apart

1. Look up the reverse DNS (PTR) record

The PTR record often names the owner outright:

$ dig -x 198.51.100.24 +short
mail-out-24.sender.example.net.

A hostname under a sending provider's domain points to a service. A hostname under a residential ISP, or no PTR at all, points to something else.

2. Look up who owns the network

A WHOIS or ASN lookup tells you which organization holds the IP range. If the owner is a CRM, a help desk, a billing tool or a cloud host that your team uses, start there.

$ whois 198.51.100.24 | grep -i -E "orgname|org-name|netname"
OrgName:  Example Sender Inc.

3. Read the volume and the pattern

A forgotten service sends every day, often in amounts that match something real: invoices, password resets, support replies. Forwarders show up as a trickle. Spoofing tends to come in bursts from many unrelated networks, then stop.

4. Check whether DKIM passed for your domain

This is the strongest signal. A spoofer cannot produce a valid DKIM signature with d=example.com without your private key. If the record shows DKIM passing for your own domain, the mail almost certainly started at one of your real senders.

5. Compare header_from with envelope_from

The envelope_from (the Return-Path domain) often names the real sender. If it is a provider's bounce domain, that provider sent the mail. If it is your domain but SPF still fails, the mail was probably forwarded.

<row>
  <source_ip>203.0.113.7</source_ip>
  <count>12</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>               <!-- signature survived -->
    <spf>fail</spf>                 <!-- forwarder's IP is not in your SPF -->
  </policy_evaluated>
</row>
<identifiers>
  <header_from>example.com</header_from>
  <envelope_from>example.com</envelope_from>
</identifiers>
<auth_results>
  <dkim><domain>example.com</domain><selector>s1</selector><result>pass</result></dkim>
  <spf><domain>example.com</domain><result>fail</result></spf>
</auth_results>

This is the classic forwarding pattern: your domain in both identifiers, SPF failing because the forwarding server is not in your SPF record, and DKIM passing because the message was not changed.

What to do about each one

A service you forgot: authorize it

Add the service's SPF include to your record and turn on DKIM signing with your own domain in the service's settings. DKIM matters more: it survives forwarding, and it aligns even when the service uses its own bounce domain.

example.com.  TXT  "v=spf1 include:_spf.example.net include:spf.example.org ~all"

Each include costs DNS lookups, and SPF allows ten in total. Past that, SPF returns an error, so remove includes for services you no longer use.

A forwarder or mailing list: usually leave it

You cannot add every forwarder in the world to your SPF record, and you should not try. A forwarder that keeps the message intact keeps your DKIM signature valid, so the mail still passes DMARC. Mailing lists that add a footer or change the subject break DKIM too. Receivers often recognize this and report a forwarded or mailing_list reason in policy_evaluated. Making sure all your legitimate mail is DKIM signed with your own domain is the defense here.

Your own server: fix it

A web server sending contact form notifications, a printer that emails scans, an old app on a virtual machine. Either authorize it (SPF plus DKIM on your domain) or, better, send through a service you have already set up.

A spoofer: let the policy do its job

There is nothing to reply to and nobody to contact. Your DMARC policy is the tool: under p=quarantine or p=reject, receivers that honor it send failing mail to spam or refuse it.

Stay on p=none while you investigate

Under p=none, receivers report but do not act, so a service you have not authorized yet keeps delivering while you find it. Moving to reject before you have accounted for every legitimate source is how invoices and password resets quietly stop arriving.

Stay on p=none and read a few weeks of reports.
Authorize or fix every legitimate source until it passes aligned.
Move to p=quarantine. Watch the reports for anything legitimate that now fails.
Move to p=reject.

If you have not read a report before, start with how to read a DMARC report. To see your sources grouped in plain English, paste the XML into the free DMARC report analyser or upload the .xml file: no account, no cap. Email Digit can also manage this for domains you send from: you publish four DNS records once, then rotate keys in one click and step up DMARC when your reports say it is safe, without editing DNS again.