Error guide / 550 5.7.25 Reverse DNS PTR failure
550 5.7.25: reverse DNS (PTR) validation failed
550 5.7.25 is a rejection from the receiving mail server, not an error on your machine. It means the receiver took the IP address your message came from, looked up its reverse DNS (the PTR record), and did not get an answer it accepts. You normally see it in a bounce message or in your own mail log, worded as "reverse DNS validation failed", "no PTR record", or "client host rejected: cannot find your reverse hostname". It hits anyone sending from their own server or VPS: site owners with contact forms and order notifications, developers, and admins running a mail server.
Check your site
What causes it
Most often there is simply no PTR record for the sending IP, which is the default state on many VPS and cloud instances until someone asks for one. Next most common is a PTR that exists but does not forward-confirm: the hostname in the PTR does not resolve back to the same IP, usually because its A record was never created or went stale after a server move. Third, the PTR is technically fine but generic, the kind an ISP assigns automatically (something like 203-0-113-45.dynamic.example-isp.net); it passes the test yet reads as a home or dynamic connection, and Google and Microsoft reject such senders at anything above trickle volume. A separate trap is mail leaving over IPv6 while only the IPv4 address has a PTR.
How to fix it
- Find the exact IP your mail leaves from. It is printed in the bounce text, usually in brackets after "client host" or "from". This is the server's outgoing IP and it is not always the same as the IP your website answers on.
- Run the reverse DNS check on this page for that IP. It returns the PTR name, whether that name resolves forward back to the same IP (forward-confirmed reverse DNS, which is what receivers actually test), and the ASN with the network operator, which tells you which company owns the address and therefore controls the PTR. If your server also sends over IPv6, check the IPv6 address separately: a missing IPv6 PTR causes the same rejection while the IPv4 side looks perfect.
- If the check shows no PTR at all, open a ticket with the company shown as the network operator, your hosting provider or ISP, and ask them to set the PTR for that IP to your mail hostname, for example mail.example.com. You cannot add it in your own DNS zone: reverse DNS belongs to the owner of the address block, unless the provider has delegated the reverse zone to you, which is rare. On a VPS or dedicated server many providers expose an rDNS field in their panel, so check there first.
- If the check shows a PTR but reports that it does not forward-confirm, fix the forward half yourself. Create or correct an A record (AAAA for IPv6) for exactly the hostname the PTR returned so it points to that same IP, wait for the TTL to pass, and re-run the check until both directions match. If the PTR name sits in a domain you do not control, ask the provider to change the PTR to a name you do control.
- If the check confirms both directions but the PTR is generic ISP-style, ask the provider to replace it with a hostname in your own domain, ideally the same name your mail server announces in HELO/EHLO, and keep the matching A record in place. On shared hosting you usually cannot change any of this, and on residential or dynamic ranges the mail may be refused whatever the PTR says.
- If the provider will not set a proper PTR, stop fighting it: relay outgoing mail through a server or service that already has correct reverse DNS (your host's smarthost or a transactional mail provider), or move the mail to a host that does. Once the PTR is right, re-run the check and send a test message before assuming the queue will clear.