Spam accounts for roughly 45% of all email sent globally. That translates to billions of unwanted messages every day, consuming bandwidth, clogging mail servers, and burying legitimate communication under mountains of unsolicited junk. Worse, spam is frequently the delivery vehicle for malware that recruits machines into a botnet, phishing links, and credential-harvesting attacks.
Most people delete spam and move on, but that does nothing to stop the source. The most effective action you can take is to trace the spam back to its originating IP address and file an abuse report with the responsible provider. When enough reports land on the same IP, ISPs take action: accounts get suspended, servers get pulled offline, and the IP gets added to blocklists that protect millions of inboxes.
This guide is part of my complete IP abuse reporting series, focused specifically on reporting unsolicited email. I will walk you through header analysis, evidence gathering, abuse contact lookup, and report submission, including templates you can use right away.
How to Identify the Spam Source
Every email carries a trail of metadata in its headers that reveals the servers it passed through on the way to your inbox. The key to tracing spam is reading the Received headers downward from the top, and knowing where to stop trusting them.
Reading Email Headers
Email headers contain a chain of Received: lines, each added by a mail server that handled the message. Each MTA prepends its own line and must not alter the ones already there (RFC 5321 Section 4.4), so the chain reads newest at the top and oldest at the bottom.
That ordering rule is exactly why the bottommost line is not automatically the answer. Because servers only ever prepend, a spammer can fabricate Received: lines before handing the message to the first real MTA, and every honest server downstream will faithfully preserve those forgeries at the bottom of the chain. Take the bottom line at face value and you can end up reporting an innocent third party.
The rule to use instead: read downward from the top through the headers added by infrastructure you trust (your own MX, your mail provider's servers), and stop at the earliest line whose receiving server you still trust. The IP that server recorded, which RFC 5321 specifies as the address "determined from the TCP connection," is the one worth reporting. Everything below that boundary is unverified attacker-supplied text.
Here is what a typical Received header chain looks like:
Received: from mail-frontend.example.com (198.51.100.23) by
mx.yourdomain.com with ESMTPS; Fri, 09 May 2025 08:12:33 +0000
Received: from localhost (10.0.0.5) by mail-frontend.example.com
with ESMTP; Fri, 09 May 2025 08:12:32 +0000
Received: from spammer-vps.shady-host.net (203.0.113.45) by
mail-frontend.example.com with SMTP; Fri, 09 May 2025 08:12:31 +0000
Walk it downward. The top line was added by mx.yourdomain.com, your own MX, so you trust it. It received from mail-frontend.example.com, and the next two lines were added by that host. If example.com is your mail provider, you trust those too, and the last line it wrote records a connection from 203.0.113.45. That is your trust boundary and your reportable IP. (The internal 10.0.0.5 is a private relay hop and can be ignored.)
Note that 203.0.113.45 is reportable here because a server you trust observed that connection, not because it happens to be the bottom line. Had there been further Received: lines below it, claiming a chain through some other network, they would carry no weight: nothing you trust vouches for them, and the spammer could have written them.
Viewing Raw Headers in Common Email Clients
- Gmail: Open the email, click the three-dot menu in the top-right, and select "Show original." Gmail also displays SPF, DKIM, and DMARC verdicts at the top.
- Outlook (web): Open the message, click the three-dot menu, then "View message source."
- Thunderbird: Open the message, go to View > Message Source (or press Ctrl+U).
- Apple Mail: Open the message, go to View > Message > All Headers.
SPF, DKIM, and DMARC Failures as Evidence
Authentication failures are useful supporting evidence in spam reports, as long as you describe them precisely.
An SPF failure means the sending IP was not authorized for the identity SPF actually checked, which is the SMTP MAIL FROM (or HELO where applicable), not the From: address the recipient sees. RFC 7208 Section 2.2 is explicit that these are the identities checked and that checking others is NOT RECOMMENDED. Alignment with the visible From: domain is DMARC's job, not SPF's.
A DKIM failure means no signature verified. A DMARC failure means no authenticated identifier aligned with the visible From: domain.
Look for these lines in the headers:
Authentication-Results: mx.yourdomain.com;
spf=fail (sender IP is 203.0.113.45) smtp.mailfrom=fake-sender.com;
dkim=fail (signature did not verify) header.d=fake-sender.com;
dmarc=fail (p=reject) header.from=fake-sender.com
Include these in your report, but do not claim they prove impersonation, because they do not. Every one of them has innocent explanations that are common in ordinary mail flow: forwarding routinely breaks SPF because the forwarder becomes the sending IP, and mailing lists and security gateways routinely invalidate DKIM by modifying the message. RFC 6376 Section 6.1 says outright that "signatures can fail to verify through no fault of the Signer." What these failures actually tell you is that specific authentication and alignment checks did not pass. Combined with spam content from an unrelated IP that is strong circumstantial evidence, and abuse desks read it that way. Present it as evidence rather than as a verdict. For a deeper dive into how these authentication protocols work, see my guide on SPF, DKIM, and DMARC email authentication.
Evidence Gathering Checklist
Before filing a report, collect the following evidence. The more complete your submission, the faster the provider can act.
- Full email headers: Copy the complete raw headers, not just the visible "From" and "Subject" lines. This is the single most important piece of evidence.
- Sending IP address: Take it from the earliest
Received:header whose receiving server you actually trust, not simply the bottommost line, which can be forged. - Email body: Include the full message content, especially any URLs, phone numbers, or reply-to addresses the spammer wants victims to use.
- SPF/DKIM/DMARC results: Copy the
Authentication-Resultsheader showing pass/fail verdicts. - Timestamps: Note the date and time from the headers, including timezone. This helps the provider correlate with their server logs.
- Volume indicators: If you received multiple spam messages from the same IP, note the count and date range. Bulk abuse carries more weight.
- URLs in the spam: Document any links in the message body. These often point to the actual infrastructure the spammer is monetizing.
Finding the Abuse Contact
Once you have the source IP, you need to find who is responsible for it. Use the IP Location tool to look up the IP address. The results will show you the ISP or hosting provider, the ASN (Autonomous System Number), and often a dedicated abuse contact email.
Most providers publish an abuse contact in their WHOIS records, typically in the format [email protected]. You can run a WHOIS lookup on the IP to find registration details and abuse contacts, or query the WHOIS database directly:
whois 203.0.113.45 | grep -i abuse
This will usually return something like:
OrgAbuseEmail: [email protected]
If the spam claims to come from a specific domain, use the DNS Inspector to look up its SPF record (a TXT record at the domain itself) and see whether the sending IP is authorized.
DKIM takes an extra step, because there is no such thing as "the domain's DKIM record". Keys live under selectors, so you need both the signing domain and the selector from the message's own DKIM-Signature header: take d= and s= from it and query s._domainkey.d as TXT. For d=example.com and s=foo.bar that is foo.bar._domainkey.example.com (RFC 6376 Section 3.6.2.1).
Together these help you judge whether the domain was spoofed (making its owner a victim too) or is actually authorizing the mail.
Spam Abuse Report Template
When you contact the provider's abuse desk, structure your report clearly. Here is a template I use:
Subject: Spam Abuse Report — IP 203.0.113.45
To the abuse team,
I am reporting unsolicited bulk email originating from IP address
203.0.113.45, which is part of your network (AS64496).
Details:
- Source IP: 203.0.113.45
- Date/Time: 2025-05-09 08:12:31 UTC
- Volume: 14 identical messages received over 3 days
- SPF Result: FAIL (IP not authorized for claimed sender domain)
- DKIM Result: FAIL (signature did not verify)
The messages are unsolicited commercial email advertising fraudulent
pharmaceutical products. Each message contains links to
hxxp://spam-site[.]example[.]com (defanged for safety).
Full email headers are attached below.
--- BEGIN HEADERS ---
[Paste complete raw headers here]
--- END HEADERS ---
--- BEGIN MESSAGE BODY ---
[Paste the spam message body here]
--- END MESSAGE BODY ---
I request that you investigate this activity and take appropriate
action against the account responsible.
Regards,
[Your Name]
Defang any URLs in your report by replacing http with hxxp and wrapping dots in brackets. This prevents anyone handling the report from accidentally clicking a malicious link.
Where to Report Spam
ISP or Hosting Provider Abuse Desk
This is your primary target. Every legitimate ISP and hosting provider maintains an abuse desk, and they are obligated by their upstream providers and regional internet registries to respond to abuse complaints. Send your report to the abuse email found via WHOIS lookup or the IP Location tool.
Spamhaus
Spamhaus operates the most widely used DNS-based blocklist (DNSBL) in the world. Their Spamhaus Block List (SBL) and Exploits Block List (XBL) are consulted by mail servers handling billions of messages daily, and when an IP is listed most major email providers reject or quarantine its mail.
Adjust your expectations about what a report does here, though. Spamhaus is not a nomination system. The XBL in particular is driven entirely by Spamhaus's own detectors observing connections directly from the offending IP, and Spamhaus states plainly that "there is no way for third parties to add IP addresses to the XBL." Listing criteria differ per dataset, and none of them turn your complaint into a listing. Report to the responsible network first, since that is where a complaint actually changes something, and treat blocklist listing as a consequence of the spammer's own behaviour rather than a lever you pull.
SpamCop
SpamCop is a free reporting service that automatically parses email headers, identifies the source IP, and forwards complaints to the responsible ISP. Create an account at spamcop.net, paste the full email with headers, and SpamCop handles the rest. It is particularly useful if you receive large volumes of spam and want to automate reporting.
FTC (United States)
If you are in the United States, report through the FTC's online complaint form at reportfraud.ftc.gov. Do not use the old [email protected] address you will still find recommended in plenty of places: the FTC has retired that mailbox and says it now uses other tactics to identify spammers. The FTC uses these submissions to build cases against CAN-SPAM Act violators, and it particularly wants to hear about scams that started with an email and cost someone money. While individual reports rarely trigger action, aggregate data from thousands of reporters helps the FTC identify large-scale offenders.
DNSBL Submission
Beyond Spamhaus, several other DNSBLs accept submissions: SORBS, Barracuda Reputation Block List (BRBL), and the Composite Blocking List (CBL). Getting an IP listed on multiple blocklists significantly increases the pressure on the hosting provider to shut down the spam source.
Common Spam Scenarios
Bulk Unsolicited Commercial Email
This is the classic spam scenario: a sender blasts thousands or millions of marketing messages without consent. The evidence pattern is straightforward: high volume from one or a few IPs, consistent message templates, and links to commercial landing pages. Report to the ISP and submit through SpamCop, which forwards complaints to the responsible network on your behalf.
Compromised Mail Server Relaying Spam
Sometimes the source IP belongs to a legitimate mail server that has been compromised. The owner may not know their server is being used as a spam relay. In this case, your abuse report is actually helping the server owner discover a security breach. Include evidence showing the server is an open relay or has been compromised. This scenario often overlaps with brute force attacks, where attackers gain access to a server and then use it to send spam. If you are on the receiving end of this as the server owner, my guide on reporting a hacked server walks through containment and the abuse reports to file.
Snowshoe Spam
Snowshoe spammers distribute their messages across many IP addresses, sending low volumes from each one to avoid triggering rate-based spam filters. Each individual IP sends just enough mail to stay below detection thresholds. If you notice spam from multiple IPs that share similar message content, domain patterns, or landing pages, document all the IPs in a single report. This helps the provider see the full scope of the operation rather than dismissing each IP as a minor incident.
Backscatter Spam (NDR Spam)
Backscatter occurs when a spammer forges your email address as the "From" address, and the recipient mail servers send bounce notifications (Non-Delivery Reports) back to you. You end up flooded with NDRs for messages you never sent. This is not the same as phishing, but the reporting approach is similar. Report the originating IPs of the bounce messages to their respective providers, and note in your report that the bounces are the result of forged sender addresses.
What to Expect After Reporting
Response Timelines
Most major hosting providers acknowledge abuse reports within 24 to 48 hours. The actual resolution, whether that means suspending the account, null-routing the IP, or issuing a warning, typically takes 3 to 7 business days. Some providers are faster; budget hosting companies and offshore providers may be slower or unresponsive.
DNSBL Listing Effects
When an IP gets listed on a major DNSBL like Spamhaus, the impact is immediate and severe. Mail servers worldwide that consult the blocklist will begin rejecting or quarantining email from that IP. For the spammer, this effectively shuts down their operation on that address. For compromised servers, the listing serves as a wake-up call that forces the owner to clean up the breach and request delisting.
When Providers Do Not Respond
If the hosting provider ignores your report after a reasonable period, escalate to their upstream provider. Every network has upstream transit providers, and those transit providers have their own acceptable use policies. You can identify upstream providers through BGP route data or by checking the ASN's peering information. In extreme cases, reporting to the regional internet registry (RIPE, ARIN, APNIC) can apply additional pressure.
Prevention: Protecting Your Own Mail Infrastructure
If you run a mail server, take steps to ensure it does not become a spam source.
Implement SPF, DKIM, and DMARC
Publish an SPF record listing only your authorized sending IPs, taking care to avoid the common SPF setup mistakes that leave legitimate mail unprotected. Configure DKIM signing for all outbound mail. Set a DMARC policy of at least p=quarantine, working toward p=reject once you have verified your legitimate mail flows. My SPF, DKIM, and DMARC guide covers the full setup process.
Harden Your Mail Server
- Disable open relay. Your server should never accept mail for domains it does not serve.
- Require SMTP authentication for all outbound mail submission.
- Use TLS encryption for all SMTP connections.
- Implement rate limiting on outbound messages per authenticated user.
- Monitor outbound mail queues for sudden spikes in volume.
Restrict Relay Access
Configure your mail server to relay only for authenticated users on your network. Test your configuration by running an open relay test from an external service. A single misconfigured relay rule can turn your server into a spam cannon within hours.
Monitor Blocklist Status
Regularly check if your IP is blacklisted across major DNSBL databases. If you find yourself listed, investigate immediately. A listing usually means either your server has been compromised or a user on your network is sending spam.
Score Inbound IPs Programmatically
If you operate at any scale, the IP Intelligence API lets you score every connecting IP for VPN, proxy, Tor, and datacenter origin before the message even reaches the SMTP queue. Combine that signal with DNSBL checks and you catch the bulk of bot-driven spam at the network layer: including the noise that DNSBLs miss because the spammer is rotating fresh hosting IPs faster than blocklists can update. Free tier covers 1,000 lookups per day, no credit card.