How to Report Spam From an IP Address: Abuse Reports for Unsolicited Email

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, 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 from bottom to top.

Reading Email Headers

Email headers contain a chain of Received: lines, each added by a mail server that handled the message. The bottommost Received: header is the one closest to the original sender, and that is where you will find the source IP.

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

In this example, 203.0.113.45 is the originating IP, the server that first injected the message into the mail system. The internal 10.0.0.5 address is a private relay and can be ignored.

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 strong supporting evidence in spam reports. When an email fails SPF, it means the sending IP was not authorized to send on behalf of the claimed domain. A DKIM failure means the message signature could not be verified. A DMARC failure means the domain owner's published policy was violated.

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

These failures confirm the sender was impersonating a domain, which strengthens your abuse report significantly. 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 — Extract the originating IP from the bottommost external Received: header.
• 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-Results header 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 also 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 that domain's SPF and DKIM records. This helps you determine whether the domain was spoofed (the owner is also a victim) or whether the domain owner is complicit in the spam operation.

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. You can submit spam data through their reporting page at spamhaus.org. When an IP gets listed on Spamhaus, most major email providers will reject or quarantine mail from that address.

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, you can forward spam to [email protected], the Federal Trade Commission's spam collection. The FTC uses these submissions to build cases against CAN-SPAM Act violators. 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 to Spamhaus and SpamCop simultaneously.

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.

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. 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 whether your mail server IPs appear on any DNSBLs. Services like MXToolbox offer free blocklist monitoring. 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.