Gmail PTR / reverse DNS failures: fixing 4.7.23 and 5.7.25 for IPv4 and IPv6 senders

When Gmail returns 4.7.23 or 5.7.25, the problem is usually narrower than it first appears. This is not a generic “your reputation is bad” message. It is Gmail complaining that the sending IP does not have acceptable reverse DNS, or that the reverse DNS does not map back cleanly to the same public IP.

That requirement applies to both IPv4 and IPv6 senders. And for IPv6, Google also calls out a related block message about IPv6 PTR records and authentication, which is why dual-stack senders need to check both address families instead of assuming the IPv4 setup covers everything.

Google documents this in its Email sender guidelines, the newer Email sender guidelines FAQ, and the live Gmail SMTP errors and codes reference.

The short version

If you want the practical fix first, it is this:

1. identify the exact public IP that opened the SMTP connection to Gmail
2. confirm that IP has a PTR record
3. confirm the PTR record points to a hostname you control or intentionally use
4. confirm that same hostname resolves forward to the same sending IP with A for IPv4 or AAAA for IPv6
5. if you send on both IPv4 and IPv6, repeat the test for both

If any of those checks fail, Gmail has a good reason to keep deferring or blocking the mail.

What 4.7.23 and 5.7.25 actually mean

Google's wording is fairly direct:

• 4.7.23 is a temporary rate limit because the sending IP does not have a PTR record, or the PTR record's forward DNS entry does not match the sending IP
• 5.7.25 is the harder version of the same problem: Gmail is blocking the message because the sending IP does not have acceptable PTR / forward DNS setup

So the 4xx versus 5xx distinction matters here just like it does for Gmail's authentication errors:

• 4.7.23 means “fix this, then try again later”
• 5.7.25 means Gmail is done waiting and is blocking the traffic

The underlying defect is still basically the same class of issue.

What Gmail expects from reverse DNS

Google's sender guidelines describe two linked checks:

1. the public IP address of the sending SMTP server must have a PTR record that resolves to a hostname
2. that same hostname must resolve back to the same public IP address used by the sending server

That second part is the part many teams miss.

Having some PTR record is not enough. Gmail wants forward-confirmed reverse DNS. In plain English: reverse lookup from IP to hostname, then forward lookup from hostname back to the same IP.

Example of a healthy IPv4 setup:

192.0.2.25 -> mail-out.example.com
mail-out.example.com -> 192.0.2.25

Example of a healthy IPv6 setup:

2001:db8:100::25 -> mail6.example.com
mail6.example.com -> 2001:db8:100::25

Example of a broken setup that triggers Gmail complaints:

192.0.2.25 -> oldhost.example.net
oldhost.example.net -> 198.51.100.44

That is exactly the kind of mismatch Gmail is talking about.

Why this fails so often in real environments

PTR failures are common because reverse DNS is not managed in the same place as your normal domain zone.

For many senders, the A, AAAA, MX, SPF, DKIM, and DMARC records live in the organization's DNS provider, but the PTR record is controlled by:

• the VPS provider
• the cloud provider
• the ISP
• the colocation provider
• the ESP that owns the shared or dedicated sending IP

This is why admins sometimes insist “DNS is correct” while Gmail still returns 4.7.23 or 5.7.25. The forward zone was updated, but the reverse zone for the actual sending IP was never changed.

IPv4 and IPv6 need separate validation

Dual-stack environments create a predictable trap: IPv4 is configured cleanly, but IPv6 is half-finished or inherited from the host provider.

Google's sender guidelines explicitly say that for IPv6 authorization errors, the PTR record for the sending server may not be using IPv6 correctly. Its SMTP error reference also includes this separate IPv6 block text:

550 5.7.1 This message does not meet IPv6 sending guidelines regarding PTR records and authentication.

Operationally, that means:

• your MTA might prefer IPv6 outbound when a Gmail MX has AAAA
• Gmail will evaluate the IPv6 sending IP, not your nicer-looking IPv4 setup
• SPF, DKIM, and DMARC can be fine, but Gmail can still reject the connection path because the IPv6 infrastructure identity is not acceptable

If mail leaves from both address families, you need both of these to be true:

• the IPv4 address has valid PTR plus matching forward A
• the IPv6 address has valid PTR plus matching forward AAAA

A practical check sequence

This order usually finds the problem quickly.

1. Confirm which IP actually sent the mail

Do not assume the documented relay is the real egress host. Check the MTA logs, provider logs, or a Gmail SMTP reply that includes the source IP.

This matters especially when:

• outbound traffic is NATed
• a smart host or relay sits in front of the application server
• IPv6 is preferred automatically
• one provider signs the mail but another provider actually transmits it

2. Check reverse DNS on that exact IP

Use the Google Admin Toolbox Dig tool or another DNS tool and query the PTR for the real sending IP.

What you want to see is a stable hostname, not no answer and not a generic provider placeholder you did not intend to send with.

3. Check the hostname forward lookup

Once you have the PTR hostname, look up that hostname forward:

• use A for IPv4
• use AAAA for IPv6

The result should point back to the same public sending IP.

4. Check that the hostname is still current

A lot of Gmail PTR problems come from infrastructure drift:

• the server moved to a new IP
• the hostname was repointed but the PTR was left behind
• the provider recycled the IP assignment
• the MTA started sending from a different interface

The DNS records may all exist, but they no longer describe the real path used in production.

5. Re-test after the DNS change propagates

After correcting PTR or forward DNS, send a fresh test message to Gmail and watch whether the error changes from hard block to temporary deferral, or disappears entirely.

If the PTR problem is gone but mail is still failing, the next likely checks are authentication and alignment. Gmail bulk sender error codes explained is the natural follow-up at that point.

Common broken patterns

Here are the failure modes seen most often.

No PTR at all

The IP simply has no reverse record.

Result: Gmail treats the sending host as under-identified and may return 4.7.23 or 5.7.25.

PTR exists, but points to an unrelated hostname

Example:

2001:db8:100::25 -> vps-25.provider.invalid

That may be technically present, but it may still be the wrong identity for production outbound mail, especially if the hostname does not resolve back properly or reflects a stale assignment.

PTR hostname does not resolve back to the same IP

This is the classic forward-confirmed reverse DNS failure.

Example:

192.0.2.25 -> mail.example.com
mail.example.com -> 192.0.2.99

Everything looks named, but the identity chain is broken.

IPv6 PTR missing while IPv4 is fine

This one catches teams during migrations or when enabling IPv6 on the host without fully preparing outbound mail.

If the MTA connects over IPv6, Gmail judges the IPv6 address. A correct IPv4 PTR does not rescue a broken IPv6 path.

Shared ESP or relay IP where you do not control PTR

If your provider owns the sending IP, you usually cannot fix this locally. You need the provider to correct the reverse DNS or move you to a correctly configured sending IP.

What not to confuse with PTR fixes

PTR is important, but it does not replace message authentication.

You still need SPF, DKIM, and for bulk sender traffic to personal Gmail accounts, DMARC as Google requires. PTR tells Gmail the server IP has a sane network identity. It does not prove the message is authorized for the visible sender domain.

So it is possible to fix 4.7.23 or 5.7.25 and then run directly into:

• 4.7.27 / 5.7.27 for SPF failure
• 4.7.30 / 5.7.30 for DKIM failure
• 4.7.32 / 5.7.32 for DMARC alignment failure

If those concepts are mixed together in your current troubleshooting, DMARC troubleshooting with real headers and Return-Path vs From: practical implications help separate them cleanly.

A minimal remediation checklist

Use this when the goal is just to get Gmail accepting the traffic again.

1. identify the real egress IPv4 and IPv6 addresses
2. create or correct PTR for each sending IP
3. make sure each PTR hostname resolves back to the same IP with matching A or AAAA
4. verify the MTA is actually sending from those corrected IPs
5. if a provider owns the IP, open the ticket there rather than only editing your own zone
6. send a new test message to Gmail and keep the full SMTP response
7. if Gmail moves on to another error code, fix the next concrete issue instead of assuming PTR is still the blocker

Bottom line

Gmail's 4.7.23 and 5.7.25 errors are usually about one thing: the sending IP does not have a trustworthy reverse-DNS identity chain.

For IPv4, that means PTR plus matching forward A. For IPv6, that means PTR plus matching forward AAAA, and it also means checking whether your MTA is silently preferring IPv6 for delivery to Gmail.

Once the real sending IP is identified and both sides of the DNS mapping are corrected, these failures are often much easier to clear than broader reputation problems.