Gmail
Gmail 550 5.7.25 — your sending IP has no PTR record
550 5.7.25
Gmail requires every IP that connects to it to have a PTR record — reverse DNS mapping the IP back to a hostname, with that hostname resolving forward to the same IP. This check is about the sending server's IP, not your domain: your SPF and DKIM can be perfect and 5.7.25 still fires if the machine that made the connection has no valid rDNS.
How to fix it
- 1
Identify which IP actually connected
The bounce names the IP Gmail saw. If you send through an ESP or Google Workspace this should never be your problem — their IPs have PTR records — so a 5.7.25 almost always means mail left from somewhere else: a web server sending directly, a misconfigured application, or an on-premise relay.
- 2
Set the PTR at whoever owns the IP
PTR records live with the party that controls the IP block — your hosting provider, VPS console (AWS, Hetzner, DigitalOcean all expose an rDNS setting), or ISP. Set it to a real hostname like mail.yourdomain.com, and create a matching A record so the hostname resolves back to the same IP (forward-confirmed rDNS).
- 3
Or stop sending direct from that box
For an app server that only sends occasional notifications, routing through an authenticated relay (your ESP's SMTP endpoint or a transactional provider) is usually better than maintaining direct-to-Gmail delivery — rDNS, reputation, and retries become the provider's job.
- 4
Verify before retrying
Confirm the PTR resolves (dig -x YOUR_IP), confirm the hostname resolves back, then send a test to the inbox test and check the received headers show the new hostname.
Meaning current as of 2026-07-25, cross-checked against the provider's own documentation. Providers do occasionally redefine codes — if this doesn't match what you're seeing, the source link is the authoritative reference.