550 5.7.25 means Gmail refused your message because the IP address that sent it has no proper reverse DNS (PTR) record. Gmail requires every sending IP to have one. The full message:

550 5.7.25 The IP address sending this message does not have a PTR record setup, or the corresponding forward DNS entry does not point to the sending IP.

You may also see the temporary version, 421 4.7.0 with the same text, where Gmail defers the message instead of rejecting it. Either way, the fix is the same. For other codes, see our guide to SMTP bounce codes.

What a PTR record is

Normal DNS turns a name into an IP address (mail.example.com → 203.0.113.10). A PTR record does the opposite: it turns the IP back into a name (203.0.113.10 → mail.example.com).

Gmail checks both directions:

  1. The sending IP has a PTR record that gives a hostname.
  2. That hostname resolves back to the same IP.

This is called forward-confirmed reverse DNS. Servers that fail it look like infected home computers or throwaway machines, which is why Gmail blocks them. Our guide What is a PTR record? explains how reverse DNS works and where to set it at common hosts.

Who this happens to

  • Your own mail server (a VPS or a dedicated server) where nobody set the PTR record.
  • A server that sends over IPv6, where the PTR was set for the IPv4 address only. A server with an IPv6 address often connects to Gmail over IPv6, so that address needs a PTR record too.
  • An IP that changed, for example after moving to a new server, with the old PTR left behind.

If you send through an email service provider (Mailjet, Brevo, Amazon SES, Google Workspace, Microsoft 365…), they manage PTR records for their IPs. Seeing this error with them is rare; contact their support.

How to check it

The quickest way is the free reverse DNS lookup: enter your sending IP, and it shows the PTR name and whether that name points back to the same IP, for IPv4 and IPv6.

On Linux or macOS, with your sending IP:

dig -x 203.0.113.10 +short

This should print a hostname, for example mail.example.com.. Then check that the name points back to the same IP:

dig mail.example.com +short

Do the same with your IPv6 address if your server has one (dig -x 2001:db8::10 +short and dig AAAA mail.example.com +short).

How to fix it

  1. Set the PTR record at your hosting provider, not in your normal DNS. The PTR record belongs to whoever owns the IP address. It is usually in your server's control panel ("reverse DNS", "rDNS" or "PTR"). Your DNS host (Cloudflare, for example) cannot set it.
  2. Point it to a real hostname you own, such as mail.example.com, not to the provider's default name.
  3. Create the matching A record (and AAAA record for IPv6) so the hostname resolves back to the same IP.
  4. Use the same name in your server's greeting (HELO/EHLO). It is not required by the PTR check itself, but a matching name is the setup filters expect.
  5. Wait for it to update (minutes to a few hours), then send again.

Frequently asked questions

Is 550 5.7.25 a problem with the recipient's address?

No. The address is fine. Gmail refused your server, so every Gmail address bounces the same way until the PTR record is fixed.

Can I set a PTR record in Cloudflare?

Only for IP ranges you own yourself. For a server you rent, the hosting provider controls the reverse DNS of its IPs, so the setting is in their panel.

Does this affect Outlook and Yahoo too?

They check reverse DNS too, and many company mail gateways do the same. Some answer with a generic code such as 550 5.7.0 Local Policy Violation instead. A correct PTR record is one of the basics of the 2026 sender requirements.

Sources