SpamRats blacklist: why reverse DNS gets you listed

Most blocklists judge you on behaviour — who you mail, how often you bounce, how many people complain. The SpamRats blacklist is different. Its most-used zones barely look at your content or your complaint rate at all; they look at your sending IP's infrastructure and ask a blunt question: does this address look like a legitimate mail server, or does it look like a random machine on a home broadband line? If your reverse DNS is missing or generic, SpamRats can list you before you have sent a single spam message. Here's what the SpamRats zones actually check, why reverse DNS matters so much, how to inspect your own setup, and how to fix and delist.

The short answer#

SpamRats.com (the "Spam Rats" reputation service) runs a family of DNS blocklists — DNSBLs — that mail servers query to decide whether to accept your connection. Unlike reputation lists that score your behaviour over time, the headline SpamRats zones are largely automated and infrastructural: they flag IP addresses that lack a reverse-DNS record, or whose reverse DNS follows the naming patterns of dynamic, residential, and consumer ranges. The single most common reason a legitimate sender lands on the SpamRats blacklist is a missing or generic reverse-DNS (PTR) record on the sending IP — not spam. That also makes it one of the more fixable listings: correct the rDNS, then request removal, which is free.

The SpamRats zones, one by one#

SpamRats is not a single list. It publishes several zones, each targeting a different signal. Understanding which one you're on tells you exactly what to fix.

The pattern is worth noticing. RATS-Spam and RATS-Auth are behavioural — they are what you'd expect from any blocklist. But RATS-NoPtr and RATS-Dyna, the two that catch the most surprised senders, are pure infrastructure checks. They don't need you to send spam. They only need your IP to look like it doesn't belong to a properly configured mail server.

Why reverse DNS matters so much on the SpamRats blacklist#

Forward DNS turns a name into an address: mail.example.com → 203.0.113.5. Reverse DNS (the PTR record) does the opposite — it turns an address back into a name: 203.0.113.5 → mail.example.com. Every real mail server should have both, and they should agree. This round-trip — the IP resolves to a hostname, and that hostname resolves back to the same IP — is called Forward-Confirmed reverse DNS (FCrDNS), and receiving mail servers lean on it heavily as a first-glance test of legitimacy.

The logic is simple. A company running a genuine mail server sets up a matching PTR record as a matter of course; it's a basic operational step. A botnet-infected laptop on a home connection almost never does — it either has no PTR, or it has the generic PTR the ISP auto-assigned to the whole residential range. So a missing or dynamic-looking PTR is a strong, cheap signal that a connection is not from a legitimate mail server. That is exactly the signal RATS-NoPtr and RATS-Dyna encode. Major mailbox providers apply the same reasoning independently: many will refuse or heavily penalise mail from an IP with no valid reverse DNS, whether or not SpamRats is involved.

How to check your own PTR record#

Before you can fix a reverse-DNS problem you need to see what receivers see. You can check any sending IP from your own machine:

• On macOS or Linux: run dig -x 203.0.113.5 +short (substitute your IP). It prints the PTR hostname, or nothing if there is none.
• On Windows: run nslookup 203.0.113.5.
• Confirm the round-trip: take the hostname it returns and resolve that back to an IP (dig +short mail.example.com). If it doesn't come back to the same IP you started with, your FCrDNS is broken even though a PTR exists.

You want to see a real, mail-shaped hostname on your own domain — mail.yourdomain.com — not an empty result and not something like 192-0-2-5.dynamic.some-isp.net. An empty result is what puts you on RATS-NoPtr; a generic ISP-generated name is what puts you on RATS-Dyna. To see whether the listing has already happened rather than inferring it, run your IP through a blacklist lookup that queries the SpamRats zones directly.

How to get removed from the SpamRats blacklist#

Removal is free, and because the common listings are mechanical, delisting is usually more predictable here than on behaviour-based lists. The order of operations matters — fixing the cause has to come before the removal request, or the automated system will simply relist you.

1. Fix the reverse DNS first. For a RATS-NoPtr listing, get a PTR record created for your IP. For RATS-Dyna, get the PTR changed from the generic ISP name to a real mail hostname on your domain. This is done through whoever controls the IP — your hosting provider, VPS control panel, or ESP.
2. Confirm the round-trip resolves. Re-run dig -x and the forward lookup and verify the IP and hostname point at each other. Give DNS changes time to propagate before moving on.
3. Check the other zones. If you're on RATS-Spam or RATS-Auth, reverse DNS won't be the issue — you need to find and stop the actual abuse: secure any compromised mailbox, close an open relay, and confirm your SPF, DKIM, and DMARC are correct so your legitimate mail is clearly distinguishable from forgeries.
4. Request removal at spamrats.com. Use the lookup on their site to submit the delisting for your IP. With the underlying cause genuinely resolved, the automated zones clear far more readily than a reviewed behavioural list would.

Why a proper dedicated setup avoids SpamRats in the first place#

Almost every accidental SpamRats listing traces back to sending mail directly from an IP that was never provisioned as a mail server. A fresh VPS, a new cloud instance, an office connection, a home lab — spin one up, point your application at it, and start sending, and you've skipped the step where a real mail operator would have configured reverse DNS. RATS-NoPtr catches you immediately.

Doing it properly closes that gap:

• Send through infrastructure built for mail. A reputable ESP, or a dedicated IP that your provider has set up with matching reverse DNS, means FCrDNS is correct before you send your first message. The dedicated-versus-shared IP decision is partly a decision about who owns these details — on shared infrastructure they're handled for you.
• Warm up gradually. New IPs and domains earn trust over time. Following a sensible warm-up plan means you build volume on infrastructure that already passes the infrastructural checks, rather than tripping them at full throttle on day one.
• Authenticate everything. SPF, DKIM, and DMARC don't directly control the SpamRats zones, but they're the other half of "does this look like a real mail server," and they matter to every receiver and to the behavioural zones.

Get those three right and the SpamRats blacklist essentially stops being something you have to think about — your IP already looks like exactly what it is.

Catch a SpamRats listing before it costs you#

Like every DNSBL, SpamRats doesn't send you a warning. A PTR record silently lapses, a provider re-images your server and drops the reverse DNS, an IP gets reassigned — and you find out only when mail starts bouncing, days into a drop in deliverability. The reliable way to hear about it in time is continuous blacklist monitoring, which checks your IPs and domains against SpamRats and other major lists on a schedule and alerts you the moment a listing appears or clears — so a silent infrastructure change becomes an alert instead of a mystery.

Frequently asked questions#

What is the SpamRats blacklist and how is it different from other blocklists?#

SpamRats.com runs a family of DNS blocklists (DNSBLs) that mail servers query before accepting a connection. What sets it apart is that its most-used zones — RATS-NoPtr and RATS-Dyna — are infrastructural rather than behavioural: they flag IPs with missing or generic reverse DNS instead of measuring spam or complaints. It also runs RATS-Spam and RATS-Auth for spam and authentication abuse, but most surprised legitimate senders are caught by the reverse-DNS checks.

Why am I on RATS-NoPtr or RATS-Dyna if I never sent spam?#

Because those zones don't check for spam — they check your IP's reverse DNS. RATS-NoPtr lists any sending IP that has no PTR record at all, and RATS-Dyna lists IPs whose PTR follows the generic naming patterns of dynamic or residential ranges. If you sent mail from a new server or a connection that was never set up as a proper mail server, the reverse DNS is usually the missing piece, and that alone is enough to be listed.

How do I check my reverse DNS (PTR) record?#

Run dig -x <your-ip> +short on macOS or Linux, or nslookup <your-ip> on Windows, to see the PTR hostname your IP resolves to. Then resolve that hostname forward and confirm it points back to the same IP — that round-trip is what receivers actually test. An empty result means no PTR (a RATS-NoPtr risk); a generic ISP-style name means a RATS-Dyna risk.

Is SpamRats removal free, and how long does it take?#

Yes, delisting at spamrats.com is free. Fix the underlying cause first — create or correct the reverse-DNS record for a RATS-NoPtr or RATS-Dyna listing, or stop the abuse for RATS-Spam and RATS-Auth — then submit the removal request through their lookup. Because the common listings are automated, they typically clear more predictably than reviewed behavioural lists once the cause is genuinely resolved, though you should allow time for DNS changes to propagate first.

The SpamRats blacklist is one of the easiest listings to prevent and one of the quietest to discover. Qualisend's blacklist monitoring watches your domains and IPs against SpamRats and other major lists continuously and alerts you the moment a listing appears — so a lapsed PTR record becomes an alert, not a week of lost mail. Not sure whether your sending IP even has a problem yet? Start with our free email checker, and clean the dead addresses and spam traps that damage your reputation before they cost you the inbox.