RATS-Dyna: The Listing Your Reverse DNS Caused

RATS-Dyna is the one list on a typical blocklist report that can be answered without knowing anything about your list, your copy or your complaint rate. It reads a single DNS record and decides, from the shape of the name it finds, whether the machine at that address looks like a residential connection pretending to be a mail server.

That makes it the fastest row on the report to resolve, and for most cold email programmes it is also the fastest row to dismiss, because the address being judged is not theirs.

Who runs it and what it is for

RATS-Dyna is one of four lists published by SpamRATS, which its own pages describe as automatic IP listing technology and which the site footer attributes to mThreat Technology Inc. The siblings are RATS-NoPtr, RATS-Spam and RATS-Auth, each keyed on a different signal, and Dyna is the one keyed on the shape of a reverse DNS name.

The operator's own description of the list runs: "RATS-Dyna is a collection of IP Addresses that have been found sending an abusive amount of connections, or trying too many invalid users at ISP and Telco's mail servers. A distinguishing characteristic is that the IP has a reverse DNS/PTR record that conforms to naming conventions indicative of a home connection or dynamic address space."

Two conditions in one sentence. Abusive connection behaviour or repeated attempts at invalid recipients, plus a reverse DNS name that looks residential. The second condition is what separates this list from a general spam list, and it is what makes the remedy mechanical.

What a residential-looking name is

Every address can carry a reverse DNS record, a PTR, which maps the number back to a name. The convention SpamRATS keys on is the one that large access providers use when they generate names in bulk for a consumer estate: the address embedded in the hostname, with the provider's domain attached. The operator gives a shape rather than a list, describing a pattern "similar to the form" of an address written out inside a telco domain.

Against that, the operator states what a mail server's PTR ought to look like: "Real mail servers should have a reverse DNS/PTR record that reflects the operators of the mail server", and it gives the two forms everybody recognises, a mail or mx label on the domain that actually runs the server. The reasoning it attaches is about responsibility rather than aesthetics: the name should say who is answerable for the machine.

1. Step 1An address connects

   To a mail server at an access provider or telco that reports into the list

2. Step 2The behaviour is counted

   An abusive volume of connections, or repeated attempts at recipients who do not exist

3. Step 3The name is read

   The reverse DNS record for that address is resolved and its shape examined

4. Step 4The shape decides

   A name that follows the conventions of a home or dynamic connection is what completes the listing

Whether this is even your address

Here the list does something unusual and helpful. The operator answers the question in its own copy, in a sentence most competing pages skip: "You should ONLY need to remove yourself from this list IF you are running your own mail server."

Its removal page says the same thing more bluntly, in a note aimed at anybody who is not an email administrator and does not own or manage their own mail server. That reader is told to contact their provider instead, because the problem is either one only the provider can fix or a mail client configured to send directly when it should be authenticating through a submission service.

For most cold email programmes that settles it. Mail leaving through Google Workspace, Microsoft 365 or a sending platform connects from an address the provider owns, whose PTR the provider set, and which no customer can change. A RATS-Dyna row against such an address is a fact about the provider's estate. The general form of that diagnosis, including why the address to check is the one quoted inside a rejection rather than the one a browser reports, is in whose IP a blocklist lookup is checking.

You run the sending serverYour address, your PTR

• The reverse DNS record is yours to publish and yours to correct
• The listing condition is mechanical and the fix is a DNS change
• Removal is available once the record is corrected and has propagated
• A dynamic or generic PTR on a sending host is a real configuration defect

You send through a providerTheir address, their PTR

• The connecting address belongs to the provider and is shared widely
• You cannot publish or change the reverse DNS record for it
• There is no request for you to file and no configuration to change
• The row describes the provider estate on the day you looked

Removal, and the condition attached to it

The operator states the precondition rather than burying it. Its list page says removal is available only once the reverse DNS has been corrected "to better conform to" the naming practice above, and it asks for enough time to have passed for the change to propagate before the request is made. Where self-service removal is not offered, it points at a contact form.

The removal page sets out three steps: check the address, read the lookup result, and submit a request only where automatic removal is unavailable. The first step exists because the answer to it frequently ends the exercise.

This precondition is the detail most of the competing pages drop. Several tell a reader to submit a removal request as the primary action, with reverse DNS mentioned afterwards as good practice. In the operator's own sequence the DNS change is the requirement and the request is the formality. Filing first produces a refusal, and repeat refusals are the worst position to be in with any list operator.

One further mechanical detail is worth knowing before you configure anything. The operator publishes the query form for the zone with a subscriber key in front of the hostname rather than a bare zone name, so a receiver querying RATS-Dyna is doing so under an identifier the operator issued. That is a design choice about who consumes the data, and it belongs in the weighting question below.

What it means for a cold outbound programme

Read the row through three questions and it resolves in a minute.

Does the address belong to you? If mail leaves through a provider or a platform, no, and there is nothing to do. Note it and move on.

If it does belong to you, does its PTR say who runs it? A sending host whose reverse DNS is whatever the hosting provider generated is a configuration defect independent of any list. Receivers other than SpamRATS read the same record, and a mismatch between the name a server announces in HELO and the name its address resolves to is a signal several large providers weigh. Publishing a PTR that names the sending domain is the same work as publishing the rest of the sending records, and it belongs in the same pass as SPF, DKIM and DMARC.

If both are fine, what is the connection behaviour? The first of the two conditions the operator states is an abusive volume of connections or repeated attempts at recipients who do not exist. In an outbound programme the second of those has one usual cause, which is an unverified list producing a wall of invalid recipients in a short window. That is a list-quality problem before it is a blocklist problem, and it is measured rather than guessed: compare the campaign's own figure against published bounce rate benchmarks and clean the source before the next send.

The weighting question is the same one every row on an aggregated report deserves. SpamRATS distributes the zone under per-subscriber hostnames, telling a prospective consumer that "If you are interested in querying RATS-Dyna, you can query it just like any other RBL using the hostname" with their own key in front of it, so the receivers consulting the list are those who registered to do so. Whether that population includes your prospects is answerable from your own bounce strings rather than from anybody's opinion, and a zone no refusal has ever named has probably never cost a send. The order to work a multi-list report in applies here unchanged, and the same restraint applies to the Woody's SMTP Blacklist row further down the same page.

House posture makes the whole question smaller. Outbound runs on provider infrastructure with separate sending domains rather than on a self-managed server, which removes the PTR failure mode entirely, and lists are verified before a send rather than after a bounce spike, which removes the connection-behaviour failure mode. What remains is a row on a report about somebody else's address space.

The short version

RATS-Dyna is one of four SpamRATS lists. It combines two conditions: an abusive volume of connections or repeated attempts at recipients who do not exist, plus a reverse DNS record whose shape follows the naming conventions of a home or dynamic connection.

The operator states that a sender who does not run their own mail server should never need to delist from it, and its removal page tells that reader to contact their provider instead. For a team sending through Google Workspace, Microsoft 365 or a platform, that is the end of the enquiry.

Where the address is yours, removal has a precondition rather than a queue. The reverse DNS record has to be corrected first, to a name that reflects who operates the server, and enough time has to pass for the change to propagate. Filing a request before that produces a refusal.

The competing pages generally lead with the removal form and mention reverse DNS afterwards. The operator's own sequence is the other way round, and following the operator's order is faster.

If you would rather run outbound on infrastructure where reverse DNS, authentication and list verification are set up before the first send, we plan the first campaign for free.

The list description, the reverse DNS naming practice, the removal precondition, the query form and the guidance to senders who do not run their own server are taken from SpamRATS's own RATS-Dyna and removal pages, fetched 2 September 2026. Verify current list behaviour with the operator before relying on it.