550 5.7.25 critical
550 5.7.25 Reverse DNS / PTR Record Failure
The receiving server rejects the connection because the sending IP has no PTR record or it fails forward-confirmed reverse DNS.
What you see
550-5.7.25 [203.0.113.5] The IP address sending this message does not have a 550-5.7.25 PTR record setup, or the corresponding forward DNS entry does not 550 5.7.25 point to the sending IP. For more information, go to ...
What’s actually happening
Mail — most often to Gmail/Google Workspace — bounces with 550 5.7.25 the moment you send. The connecting IP either has no reverse-DNS (PTR) record at all, or it has one that doesn't forward-confirm: the PTR points to a hostname, but that hostname's A/AAAA record doesn't resolve back to the same IP. Google requires forward-confirmed reverse DNS (FCrDNS) and refuses mail that lacks it.
Common causes
- The sending IP has no PTR record at all (common on freshly provisioned VPS/cloud IPs)
- Broken FCrDNS: the PTR hostname's A record points to a different IP, so the round-trip doesn't confirm
- IPv6 mismatch — the server sends over IPv6 (Google prefers it) but only an IPv4 PTR exists; the AAAA/PTR pair is missing or wrong
- The PTR points to a generic ISP/host default (e.g. 203-0-113-5.cust.example.net) that doesn't match your mail hostname or SPF
- You set a PTR at your domain registrar expecting it to work — but registrars don't control reverse DNS for an IP
How to fix it
- Set the PTR record with whoever owns the IPReverse DNS lives with the IP owner — your hosting/cloud provider (AWS, GCP, DigitalOcean, your colo), NOT your domain registrar. In their control panel set the PTR for your sending IP to your mail hostname, e.g. mail.yourdomain.com. On AWS you typically open a support request to remove sending limits and set rDNS.
- Make it forward-confirm (FCrDNS)Create a matching A record so the PTR hostname resolves back to the exact sending IP: PTR 203.0.113.5 -> mail.yourdomain.com, and A mail.yourdomain.com -> 203.0.113.5. Both directions must agree or Google still rejects. Verify with `dig -x 203.0.113.5` then `dig mail.yourdomain.com`.
- Handle IPv6 explicitlyIf your server has an IPv6 address, Google will likely connect over it. Either set a correct AAAA + IPv6 PTR pair, or disable IPv6 sending in your MTA (Postfix: `smtp_address_preference = ipv4`) so it falls back to the IPv4 IP you've already configured.
- Align the PTR hostname with SPF/HELOUse the same hostname for PTR, the MTA's HELO/EHLO greeting, and within your SPF. Mismatches won't trigger 5.7.25 directly but drag down reputation and can fail other checks. Keep them consistent.
- Wait for DNS, then retestReverse-DNS changes can take time to propagate. After setting it, confirm with `dig -x <ip>` and an external tool like MXToolbox, then resend. Don't keep retrying immediately — a cached negative result will keep bouncing.
Stop it recurring
Before sending production mail from any new IP, set its PTR at the IP owner and confirm `dig -x` round-trips to a hostname that resolves back to that exact IP.
Related errors