550 5.7.25: Sending IP has no reverse DNS record
550 5.7.25 means the receiver could not match your sending IP address to a name through reverse DNS. Gmail blocks mail from IPs with no PTR record. It mostly affects people who run their own SMTP server or VPS.
- Bounce type
- Hard bounce (permanent)
- Usually caused on
- Your sending side
- Terlido report label
- Blocked by the provider
What the standard says
RFC 5321 defines 550 as "mailbox unavailable", which includes refusals for policy reasons. RFC 7372 defines X.7.25 as "Reverse DNS validation failed": the sending IP does not have a reverse DNS record that passes the receiver's check. Class 5 means the refusal is permanent.
What the mailbox providers say
- Gmail (550 5.7.25): “This message was blocked because the sending IP address doesn't have a PTR record...” Source
Common causes
- A VPS or a server at a hosting company where no PTR record was ever set.
- A PTR record that exists but does not point to a name that resolves back to the same IP.
- A change of IP address after which the old record no longer applies.
- A shared IP at a provider that does not let customers set reverse DNS.
- A server that sends mail with a hostname in its greeting that does not match its PTR record.
How to fix it
- Ask your hosting provider to set a PTR record for the sending IP, or set it in their panel.
- Make the name in the PTR record resolve forward to the same IP.
- Use the same name as the one your server announces when it connects.
- If your provider cannot set the record, send through a mail service that already has clean reverse DNS.
- After you set the PTR record, use a reverse DNS check to confirm that the name resolves back to the same IP.
- Wait for DNS changes to spread before you retry, because the old answer may be cached.
Is it a deliverability problem?
For your own server, yes, because a missing PTR is a basic requirement of large receivers and it will keep blocking you. If you send through Google Workspace or Microsoft 365 mailboxes, this code is rare, because those providers manage the IP and its records. Even when a receiver does not reject you for missing reverse DNS, it may count it against you. A correct PTR record costs nothing and removes a point of doubt, so set it on any server that sends mail.
How Terlido handles it
When a bounce message for this code arrives in a connected mailbox, Terlido reads the status code. An enhanced code that starts with 5 is a hard bounce. In the campaign Reports tab this one is grouped as "Blocked by the provider".
On a hard bounce Terlido adds the address to the workspace blocklist with the reason "hard bounce", so no campaign emails it again. The lead stops in that campaign as bounced, its lead score goes down by 15, and the bounce counts toward the campaign's bounce rate.
Once a campaign has at least 20 sends, it pauses itself when hard bounces divided by sends goes over the campaign's maximum bounce rate. The default is 5%. If the cause was on your side and you fixed it, you can remove the entry on the Blocklist page of your account settings and try again.
Terlido treats every 5.x.x code as a hard bounce, so it blocklists the recipient even when the real cause is your own sending setup. After you fix the sending side, remove the entry from the blocklist if you want to contact that person again.
Check the domain behind the bounce
The free domain checker runs live SPF, DKIM, DMARC, MX and blocklist lookups and explains each result in plain English.
Free tools that help
Related error codes
- 554 5.7.1: Relay access denied or client host rejected
- 550 5.7.606: Microsoft banned the sending IP
- 451 4.4.2: Connection timed out