550 5.7.25 Error: Missing PTR Record and How to Fix It

A 550 5.7.25 bounce means the receiving server looked up your sending IP's reverse DNS (its PTR record) and either found nothing or found a hostname that doesn't point back to the same IP. Gmail is the main source of this bounce, and it treats it as a permanent rejection. The fix is a DNS change, but usually not in your domain's DNS: the PTR record belongs to whoever owns the IP address.

It has nothing to do with your content or your reputation. Fix the PTR and the bounces stop.

What the bounce says

The version you'll most often see in real Gmail bounce logs:

550-5.7.25 [203.0.113.7] The IP address sending this message does not
550-5.7.25 have a PTR record setup, or the corresponding forward DNS entry
550-5.7.25 does not point to the sending IP. As a policy, Gmail does not
550-5.7.25 accept messages from IPs with missing PTR records.

Google's own error reference words it slightly differently (the sending IP "doesn't have a PTR record, or the forwarding DNS entry doesn't reference the sending IP address"). Same code, same meaning.

Gmail's softer cousin, 451 4.7.23, says the same thing but rate limits instead of rejecting. Treat it as a warning.

Microsoft 365 uses 5.7.25 for IPv6 only. Its documented deferral reads:

450 4.7.25 Service unavailable, sending IPv6 address [2001:db8::25]
must have reverse DNS record.

What it means

A PTR record is reverse DNS: it maps an IP address back to a hostname, the opposite of a normal (forward) lookup.

Gmail's sender guidelines require every sender, at any volume, to have valid forward and reverse DNS. Specifically, the sending IP needs a PTR record that resolves to a hostname, that hostname needs an A (or AAAA) record, and that A record has to point back to the same sending IP. This round trip is called forward-confirmed reverse DNS, or FCrDNS. If any leg is missing or points somewhere else, you get 5.7.25.

Yahoo requires the same for all senders, and Microsoft requires it for mail to Microsoft 365 over IPv6. The reason is simple: botnets usually send from IPs with no PTR or a generic one like 203-0-113-7.dynamic.example.net. A real mail server has a real hostname.

Common causes, most likely first

You're sending from a server nobody set a PTR for. A new cloud VM, a VPS, a self-hosted Postfix box or an on-prem relay. Cloud providers and hosting companies often leave the PTR blank or generic until you ask.
The PTR and A record don't match. The PTR says mail.example.com, but mail.example.com points at a different IP (often the old server after a migration), or doesn't exist at all.
IPv6 is going out without anyone noticing. The server has IPv6 enabled and the receiving side has an AAAA record for its MX, so the server prefers IPv6. The IPv4 address has a perfect PTR. The IPv6 address has none.
Mail is leaving from an IP you didn't expect. A NAT change, new firewall or failover link means outbound mail leaves from a different public IP than the one you set up.
DNS that only works some of the time. One nameserver for the reverse zone is broken or slow, so some messages bounce and others don't.

How to fix it

Find the exact sending IP. It's usually in the bounce in square brackets. If it isn't, check the Received headers of a message from that server with the header analyzer. Note whether it's IPv4 or IPv6.
Check the reverse lookup. Run dig -x 203.0.113.7 +short (or Google's Admin Toolbox Dig with the PTR option). You want a hostname back, like mail.example.com., not nothing and not a generic dynamic-looking name.
Check the forward lookup. Run dig A mail.example.com +short (or AAAA for IPv6). It must return the exact sending IP.
Set or fix the PTR with the IP owner. You can't add a PTR in your domain's DNS zone. The reverse zone belongs to whoever holds the IP block: your cloud provider (most have a reverse DNS setting in the console or require a support ticket), your hosting company or your ISP. Ask them to set the PTR to a hostname you control.
Make the forward record match. In your own DNS, create or update the A (or AAAA) record for that hostname so it points to the sending IP.
Deal with IPv6 explicitly. Either give the IPv6 address its own PTR and matching AAAA record, or configure the mail server to send over IPv4 only. In Postfix that's inet_protocols = ipv4. Don't leave it half set up.
Retry the mail. A 550 isn't retried automatically. Once DNS has propagated, resend.

✨

Pick a hostname under a domain you control and actually send from, like mail.example.com. Receivers like to see the PTR "reflect your domain name in some way," as Yahoo puts it, and a generic provider hostname doesn't.

How to confirm it's fixed

Run both lookups again from a machine outside your network, and make sure they agree. Then send a test to a personal Gmail address, open it, and choose "Show original." The message should arrive, and the Received line Gmail added (the topmost one) should show your hostname next to the IP. If 5.7.25 or 4.7.23 keeps appearing intermittently, check that every nameserver for the reverse zone returns the same answer.

While you're at it, run the domain through the email checker. A server that was missing a PTR is often missing SPF or DKIM as well, and that's the next bounce in line (550 5.7.26).

How to keep it from coming back

Add "set PTR and matching A record" to the checklist for any new server, IP or cloud region that will send mail.
When you migrate servers, update the A record and the PTR together, and remove the PTR from the old IP.

When to get help

If the PTR checks out from where you're sitting and Gmail still says it doesn't, or you can't tell which IP your mail is actually leaving from, it's worth having someone trace the path with you. Get in touch.

FAQ

Can I add a PTR record in my domain's DNS?

No. PTR records live in the reverse zone of the IP block, which is controlled by whoever owns the IP: your ISP, cloud provider or hosting company. You set the matching A record in your own DNS, and ask them to set the PTR.

Does the PTR hostname have to match my From domain?

No. Gmail checks that the PTR exists and that its hostname resolves back to the sending IP. A hostname under your own domain is better practice, but a mismatch with the From domain alone won't cause 5.7.25.

I use Google Workspace or an ESP. Why am I seeing this?

Their IPs have proper PTRs, so something is sending around them. Common culprits are a website or app server sending mail directly, a scanner or on-prem relay, or a server forwarding mail. Look up the IP in the bounce to find out whose it is. If you're not sure how to read the rest of the bounce, see how to read a bounce message.

Is 5.7.25 a blocklist listing?

No. Nothing to request removal from. It's a DNS check that runs on every connection, and it passes as soon as the records are right.

550 5.7.25: Sending IP Has No PTR Record