Quick answer
Gmail 5.7.25 means Gmail blocked the message because the sending IP address did not have a valid PTR record, or the PTR hostname did not resolve back to the same sending IP. Check the actual SMTP sending IP from the bounce, header, ESP logs, or mail server logs. Do not check only the website IP, apex domain, or inbound MX host.
Gmail 5.7.25 is about the sending IP's reverse DNS
Google's sender guidelines FAQ maps 5.7.25 to a sending IP address that lacks a PTR record or has forward DNS that does not reference the sending IP. The related temporary code is 4.7.23; the permanent block is 5.7.25.
This is an infrastructure error, not a content issue. Rewriting the subject line or changing the From display name will not fix a PTR failure. The relevant question is whether the IP that connected to Gmail has reverse DNS and matching forward DNS.
Identify the actual SMTP sending IP first
PTR troubleshooting starts with the sending IP. That IP may not be obvious from the domain name.
If you use Google Workspace, Microsoft 365, Postmark, SendGrid, Mailgun, a CRM, or a newsletter platform, the sending IP may belong to that provider. If you run your own mail server, the sending IP is usually the public IP of that SMTP server or outbound gateway.
The bounce text may include the IP Gmail evaluated. If a related message was delivered, the headers may show the connecting server path. Provider dashboards or SMTP logs can also show the outbound IP.
Do not assume the website server is the sender. Do not assume the inbound MX host is the sender. MX tells the world where to deliver mail to your domain; PTR for 5.7.25 concerns the system that sends mail out.
Check PTR and forward DNS as a pair
Google's sender guidelines say the sending IP address must match the IP address of the hostname specified in the PTR record. The same section describes reverse DNS as PTR from IP to hostname, and forward DNS as A or AAAA from that hostname back to the same IP.
In practical terms:
- The sending IP should have a PTR record.
- The PTR hostname should be a stable hostname, not a generic or missing value.
- That hostname should have an A or AAAA record.
- The A or AAAA record should resolve back to the same sending IP.
PTR records are DNS records defined in the DNS system described by RFC 1035. For email delivery, the operational requirement is the forward-confirmed reverse DNS relationship, not just "some PTR exists."
If you use an ESP, check provider responsibility
If a third-party ESP sends the message, you may not control the PTR record directly. The ESP controls its sending IPs and reverse DNS. In that case, open a provider ticket with the exact Gmail bounce and the sending IP.
Do not add random DNS records at your domain registrar hoping to fix provider-owned reverse DNS. PTR records are delegated through the IP address owner, not the domain owner.
If you use a dedicated IP at an ESP, the provider may let you choose or configure a branded hostname. If you use a shared IP pool, the provider usually manages PTR and forward DNS for the pool.
If you run your own mail server, fix the IP owner side
If you control the sending server, the PTR record is usually configured through your VPS, hosting provider, cloud provider, ISP, or IP address owner. Your domain's DNS zone cannot directly set reverse DNS for an IP block it does not own.
Use a hostname that resolves back to the sending IP and matches your mail infrastructure. Avoid using a bare website hostname if it points somewhere else. After the provider updates PTR, check both reverse and forward lookup from outside your network.
If the bounce mentions IPv6, verify IPv6 reverse DNS too. Google's sender guidelines explicitly call out IPv6 authorization errors when PTR and authentication are not correct.
What Relaymetry can check
Relaymetry can check domain-level DNS and can explain why PTR matters. It can also check a provided IP address if the future route accepts one or the bounce exposes one.
Without the actual sending IP, a domain-only report can only flag likely context: MX hosts, SPF-authorized providers, blacklist posture, and general DNS health. It cannot prove the exact PTR relationship Gmail evaluated for the SMTP connection.
How to fix Gmail 5.7.25
- Keep the full Gmail bounce text.
- Extract the sending IP if the bounce includes it.
- If the IP belongs to an ESP, send the bounce to the ESP.
- If you control the IP, configure PTR through the IP owner or hosting provider.
- Confirm the PTR hostname resolves back to the same IP with A or AAAA.
- Check both IPv4 and IPv6 if the sender uses both.
- Send a controlled test after DNS changes propagate.
- Continue with SPF, DKIM, and DMARC checks after PTR is fixed.
What this does not prove
Fixing Gmail 5.7.25 proves only that the reverse-DNS failure path has been addressed for the sending IP. It does not prove SPF passes, DKIM passes, DMARC aligns, Gmail reputation is healthy, or accepted mail will land in the inbox.
Relaymetry cannot prove the exact PTR state Gmail saw unless the actual sending IP is known. A domain-only lookup is not enough for message-specific PTR proof.