A RATS-Dyna listing is almost always a naming problem, not a behaviour problem. SpamRATS runs several zones, and Dyna is the one that lists IP addresses whose reverse DNS resembles a dynamically assigned or residential allocation. Mail servers are expected to have deliberate, static-looking hostnames; a PTR record that reads like an automatically generated one is treated as a sign the host should not be delivering mail directly.
The SpamRATS zones, and which one you hit
| Zone | Return code | What it means |
|---|---|---|
| RATS-Dyna | 127.0.0.36 | Reverse DNS looks dynamic or generic |
| RATS-NoPtr | 127.0.0.37 | No reverse DNS at all |
| RATS-Spam | 127.0.0.38 | Repeated high-volume spam from the IP |
| RATS-Auth | 127.0.0.43 | Authentication abuse, password guessing against mail servers |
The combined zone is all.spamrats.com, so a lookup there gives you the code and therefore the zone:
dig +short 9.113.0.203.all.spamrats.com # reversed octets of 203.0.113.9 dig +short -t txt 9.113.0.203.all.spamrats.com dig +short -x 203.0.113.9 # your current PTR
If you get 127.0.0.36, read on. 127.0.0.37 is a missing PTR; 127.0.0.38 and 127.0.0.43 are behavioural and need the cause resolved before anything else.
What a dynamic-looking PTR is
These patterns get flagged, and variations on them:
203-0-113-9.broadband.example.netdsl-203-0-113-9.isp.exampledhcp-9.pool.example.netip-203-0-113-9.hosting.examplestatic.9.113.0.203.clients.example.com— yes, even with "static" in it, if the IP is embedded in the label- No PTR at all, which lands you in RATS-NoPtr instead
A mail server's PTR should look like a mail server: mail.yourdomain.com, smtp.yourdomain.com, mx1.yourdomain.com. It should not contain the IP address in digit form, and it should not include words associated with consumer connectivity.
Fix it, then delist
- Decide whether you should be sending from this IP at all. If it is genuinely a dynamic residential address, the answer is no, and no amount of DNS work changes that. Relay through a provider instead. You will also be listed on Spamhaus PBL, which is the same judgement from a bigger list.
- Set a proper PTR record. Reverse DNS is controlled by whoever owns the IP block, which means your hosting provider or ISP, not your domain's DNS. Most providers expose it: a reverse DNS field on the instance or IP object (DigitalOcean derives it from the droplet name; Hetzner, Azure and GCP have rDNS fields on the public IP; AWS requires a reverse DNS request for an Elastic IP). Set it to a hostname in a domain you control.
- Make it forward-confirmed. Publish an A record for that hostname pointing back to the same IP, so
mail.yourdomain.comresolves to the IP and the IP's PTR resolves tomail.yourdomain.com. This is FCrDNS, and Gmail, Microsoft and Yahoo all expect it. - Match your SMTP HELO/EHLO name to the PTR hostname. A mismatch is a separate penalty at several receivers and some filters score it heavily.
- Wait for DNS to propagate, then verify with
dig -xfrom an external resolver — not from the server itself, which may answer from cache. - Request delisting at SpamRATS. Use the lookup page at
spamrats.com, enter the IP, and submit the removal request once the lookup shows your corrected PTR. Dyna listings clear quickly when the reverse DNS condition no longer holds.
What not to do
- Do not submit the delist request before the PTR resolves externally. The check is automated; it will see the old value and refuse.
- Do not point the PTR at a hostname you do not control. Using your hosting provider's default domain keeps you looking like generic infrastructure.
- Do not put the IP address in the hostname. It is the single most recognisable dynamic pattern.
- Do not ignore a simultaneous RATS-Spam or Spamhaus listing. Fixing DNS does not address spam complaints, and a clean PTR with a bad reputation still fails.
- Do not assume Dyna is what is hurting you. SpamRATS has modest reach compared with Spamhaus. A Dyna listing is a strong hint that your infrastructure fundamentals are incomplete — and those fundamentals are what the large providers also check.
Why this listing is worth fixing anyway
Even if few of your recipients query SpamRATS, every condition that causes a Dyna listing is independently penalised by Gmail, Microsoft and Yahoo. Correct FCrDNS, a sensible mail hostname and a matching HELO are baseline requirements at the receivers that decide most of your delivery. A Dyna listing is a free audit of work you needed to do regardless.
MailPilot checks sending infrastructure alongside SPF, DKIM and DMARC, warms mailboxes at a controlled pace once the configuration is right, and measures per-provider inbox placement daily so you can confirm the fix changed delivery and not just a DNS record.
Ready to reach the inbox every time?
Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.
Start free trial