RATS-Spam: SpamRATS\u2019 volume-based list, and how to get delisted

RATS-Spam is one of four lists run by SpamRATS (spamrats.com), and it's the one based on directly observed abuse rather than network characteristics. SpamRATS runs four separate, independently-queried zones:

RATS-Spam, specifically, is not about your IP's network type or PTR configuration — it's a direct observation that mail from that IP matched spam-trap or high-volume-abuse patterns. That makes it the sibling list most likely to reflect an actual sending-practices problem on your side, rather than infrastructure hygiene.

How to check it

$ dig +short 5.113.0.203.spam.spamrats.com
127.0.0.2

A response means you're listed; no answer (NXDOMAIN) means clean. Check each of the four zones separately — a clean result on RATS-Spam doesn't tell you anything about RATS-Dyna or RATS-NoPtr.

Why an IP ends up on RATS-Spam specifically

• Sending to a stale or purchased list that includes spam-trap addresses.
• A compromised account or server sending mail without the account owner's knowledge.
• Sudden, large-volume sending from an IP with little prior history — this pattern alone can trigger a listing even without confirmed spam-trap hits.
• Shared IP pools: if you're on a shared sending IP (common with some ESPs) another tenant's bad sending can get the whole IP listed.

Removal process

RATS-Spam listings are handled through SpamRATS's self-service removal, which doesn't require a support ticket for most cases:

1. Confirm the listing with a direct query against spam.spamrats.com, not just a third-party aggregator.
2. Fix the sending cause first — stop the send, clean the list that triggered it, or secure the compromised credential. SpamRATS will relist quickly if the same pattern repeats.
3. Use SpamRATS's web-based delisting tool to submit the IP for removal.
4. If you're on a shared IP and the listing came from another tenant, contact your ESP; you can't remove a listing caused by someone else's sending from a pool IP you don't control alone.

This is distinct from RATS-NoPtr and RATS-Dyna, which largely self-resolve once the underlying rDNS or network-type condition is fixed and don't need the same manual submission.

What not to do

• Don't request removal before identifying and stopping the cause. A spam-volume listing with the underlying sending behaviour still active will simply reappear.
• Don't assume a RATS-Spam hit is the same issue as a RATS-Dyna or RATS-NoPtr hit. They have different causes and different fixes; treating them as one problem wastes time on the wrong remediation.
• Don't ignore a shared-IP listing on the assumption it will resolve itself. It typically needs your ESP to act on the account that caused it.
• Don't request removal multiple times in quick succession. Repeated submissions for the same IP before the underlying cause is confirmed fixed can slow down review rather than speed it up.

How RATS-Spam compares to its sibling lists in practice

RATS-Dyna and RATS-NoPtr listings tend to be mechanical — fix the PTR record or move off the dynamic range, and the listing clears on its own without a request. RATS-Spam is the one that requires you to actually diagnose what happened, because the trigger was observed behaviour rather than a static network property. If you're seeing a RATS-Spam listing alongside a clean result on the other three zones, that's a reasonably strong signal the issue is specific to content or list quality rather than your sending infrastructure generally — worth checking your most recent send for anything that stands out, such as a newly imported list or a template change.

RATS-Auth is worth distinguishing too, because it's easy to confuse with RATS-Spam if you only glance at a multi-list report. RATS-Auth flags IPs caught attempting to guess SMTP AUTH credentials — brute-forcing mailbox logins rather than sending unsolicited content — and it almost always points to a compromised or misconfigured client, not a list-quality or content problem. If both RATS-Spam and RATS-Auth list the same IP at once, treat it as a strong signal of a compromised host sending spam through guessed or stolen credentials, and prioritise securing the server before doing anything about either listing.

After delisting

Resend volume slowly rather than resuming at full pace immediately — a fresh listing right after removal looks, to any automated system watching for it, exactly like evasion.

MailPilot's warm-up process ramps sending volume gradually and its blocklist monitoring checks all four SpamRATS zones by name, so a RATS-Spam listing is identified specifically rather than lumped in with unrelated rDNS or network-type issues, and the gradual ramp itself is the same pattern that keeps a new or recovering IP from tripping a volume-based listing like this one in the first place.