SpamRATS Blacklist: What It Checks and How to Get Removed

If your mail server is suddenly getting rejected by receivers with a message referencing "spamrats.com", you've hit one of the more unusual blacklists out there. SpamRATS isn't primarily looking for spam content or volume spikes — it's looking at the shape of your IP address and, more importantly, its reverse DNS record. For a lot of self-hosted mailers and small VPS setups, that's the thing that trips the wire.

This guide explains what SpamRATS is, the three lists it maintains, why reverse DNS matters so much, and exactly how to fix the problem and get delisted.

What SpamRATS Actually Is

SpamRATS (Spam Rats) is a DNS-based blacklist service run by a small team that's been operating since around 2007. Unlike Spamhaus or SORBS, which rely heavily on spam traps and user reports, SpamRATS focuses on heuristics around how an IP presents itself to the world. The core assumption is simple: legitimate mail servers have clean, matching, purpose-built reverse DNS. Residential connections, dynamic IP pools, and carelessly configured VPS hosts usually do not.

That assumption isn't perfect, but it catches a huge amount of botnet traffic and misconfigured relays before they ever reach a recipient's inbox. Many mail providers subscribe to SpamRATS as a lightweight pre-filter.

The Three SpamRATS Lists

SpamRATS isn't one list — it's three, and which one you're on tells you exactly what's wrong.

RATS-Dyna

This list targets IPs that look dynamically assigned. SpamRATS inspects the reverse DNS hostname for patterns common to residential broadband and dynamic pools — things like dsl-, dhcp-, pool-, dyn-, cable-, or hostnames containing the IP address itself (e.g. 203-0-113-45.isp.example.com). If your PTR record looks like a consumer connection, RATS-Dyna assumes you shouldn't be sending mail directly.

RATS-NoPtr

The simplest of the three. If your IP has no reverse DNS record at all, you land here. A missing PTR is one of the strongest signals of an unconfigured or compromised host, and almost every serious receiver treats it as disqualifying on its own.

RATS-Spam

This is the more traditional list. RATS-Spam contains IPs that have been caught sending spam through traps or reported by partner networks. It's smaller than the other two and harder to land on accidentally — but also harder to get off quickly.

Why Reverse DNS Matters So Much

Reverse DNS (rDNS), stored as a PTR record, is the mapping from an IP address back to a hostname. When your mail server connects to a remote MX and says HELO mail.example.com, the receiver does three checks almost instantly:

1. Does the IP have a PTR record at all?
2. Does that PTR resolve to a hostname?
3. Does that hostname resolve forward back to the same IP? (This is "Forward Confirmed Reverse DNS", or FCrDNS.)

If any of those fail, your mail is suspect before the message body is even transmitted. SpamRATS formalises that suspicion into a listing, but Gmail, Microsoft, and most serious ESPs apply the same logic independently. A broken PTR isn't just a SpamRATS problem — it's a deliverability problem everywhere.

How to Check Your rDNS

Checking is fast. From any machine with dig or nslookup:

dig -x 203.0.113.45 +short

Or with nslookup:

nslookup 203.0.113.45

You should get back a hostname like mail.yourdomain.com. Then confirm the forward match:

dig mail.yourdomain.com +short

That should return the exact same IP you started with. If it doesn't — or if the reverse lookup returns nothing, a generic hosting hostname like 203-0-113-45.vps-provider.net, or something containing "dyn", "dsl", "pool", or "dhcp" — you have work to do.

Fixing Your rDNS Configuration

Here's the key thing to understand: you cannot set your own PTR record through your own DNS zone. Reverse DNS for an IP is controlled by whoever owns the IP block, which is almost always your hosting provider, VPS company, or ISP.

For VPS and cloud hosts

Most modern providers (DigitalOcean, Linode, Hetzner, Vultr, OVH, AWS EC2) expose rDNS configuration in their control panel. Look for a field labelled "PTR record", "Reverse DNS", or "rDNS" on the instance or IP detail page. Set it to the hostname your mail server uses in its HELO/EHLO — typically mail.yourdomain.com.

For dedicated servers and colocation

You'll usually need to open a ticket with your provider. Give them the IP and the exact hostname you want set. Turnaround is normally a few hours.

For residential or business broadband

If you're trying to send mail from a home or office connection, most ISPs flatly refuse to set custom rDNS, and even if they did, the IP is probably in an allocation that receivers distrust by default. The honest answer here is to stop sending directly and route outbound mail through a relay — your ISP's SMTP service, a transactional provider, or a small VPS with proper rDNS.

Don't forget the forward record

Once the PTR is set, make sure mail.yourdomain.com has an A record pointing back to the same IP. Without that forward match, you'll still fail FCrDNS checks.

The Removal Process

SpamRATS removal is refreshingly simple compared to some blacklists. Once your rDNS is fixed:

1. Go to spamrats.com and use the lookup tool to confirm you're listed and which list you're on.
2. Submit a removal request through the form on the site. You'll need to provide the IP.
3. SpamRATS will re-check your rDNS automatically. If the PTR is now clean — present, non-dynamic-looking, and forward-confirmed — the delisting is usually processed within an hour.

For RATS-Spam listings, expect more scrutiny. You may need to demonstrate that the underlying spam issue has been resolved, which often means checking the host for compromise, reviewing outbound logs, and tightening authentication. See our guide on how to get delisted for the broader playbook.

If you're unsure why you were blocked in the first place, why is my IP blocked walks through the common causes, and how to release a banned IP covers recovery steps across providers.

Prevention

Staying off SpamRATS is mostly a matter of doing the boring things once and leaving them alone:

• Set clean, descriptive rDNS on every IP that sends mail. Never leave a PTR blank.
• Make sure the hostname forward-resolves back to the same IP.
• Don't send mail directly from residential or obviously dynamic allocations.
• Use the same hostname in your HELO/EHLO that your PTR points to.
• Monitor regularly so a silent listing doesn't become a deliverability crisis.

For background on how SpamRATS fits alongside Spamhaus, Barracuda, SORBS and the rest, see blocklists explained and the full blacklist directory.