Gmail 4.7.23 or 5.7.25: prove PTR and forward DNS point back to the same sending IP

Separate the transport fact from reputation guesses

Google requires sending IP addresses to have a PTR record whose hostname also resolves forward to the same public IP. Gmail documents 4.7.23 for temporary rate limiting and 5.7.25 for blocking when this forward/reverse relationship is missing or inconsistent.

For Gmail’s reverse-DNS errors, examine the public IP that actually opens the SMTP connection. The PTR record for that address should resolve to a hostname, and that hostname should resolve forward to the same sending IP. This forward-confirmed reverse DNS relationship is different from the From domain, DKIM signing domain, or the MX records used to receive mail. Small operators often edit the wrong DNS zone because they own the message domain but not the outbound IP. If a hosted provider owns the IP, the provider controls PTR. If you run your own relay on a dedicated address, your network or IP provider usually delegates or configures the reverse zone.

How a green checker can still hide the problem

Looking up example.com is not the test. PTR applies to the public IP that opened the SMTP connection, and the returned host can be a provider-controlled name that is different from the From domain or MX host.

The 4.7.23 and 5.7.25 families should not be collapsed into “Gmail hates my domain.” A temporary rate-limited response and a stronger blocking response indicate different queue behavior even when both point toward PTR/FCRDNS requirements. Repeated retries from the same broken IP do not create the missing DNS relationship; they just add traffic to an unresolved infrastructure problem. Likewise, creating a random PTR name is insufficient if its A or AAAA record does not map back correctly. Use the exact diagnostic text and the connecting IP from the SMTP log so the investigation starts at the transport identity Gmail evaluated.

Recreate the failure with one controlled path

Capture the IP from the SMTP diagnostic or received headers, perform a reverse lookup to obtain the PTR name, then query that exact name for A or AAAA records and confirm the original IP is among the results.

A clean test is mechanical. Query PTR for the outbound IP. Take the returned hostname and query its A and, if relevant, AAAA records. Confirm that one of those forward answers contains the original sending address. Then verify that the SMTP service actually uses that IP in production; NAT, smart hosts, and provider relays can make a local interface address irrelevant. After DNS is correct and caches have expired, send a low-volume controlled message to Gmail and preserve the SMTP response plus received headers. That demonstrates the receiver is observing the corrected path instead of only proving that your own resolver sees the new record.

Make the smallest reversible change

If you control the IP, coordinate the PTR with the address owner and make the forward record consistent before increasing traffic. If a mailbox provider owns the IP, open a provider ticket with the exact Gmail code and IP instead of editing unrelated DNS records.

Do not change SPF, DKIM, DMARC, From addresses, and sending volume all at once when the error specifically names PTR or forward DNS. Repair the transport DNS first and let queued mail retry according to normal policy. If you share an IP and cannot control reverse DNS, move the stream only through a provider path that publishes valid rDNS rather than inventing records in your own forward zone. Keep the IP, PTR hostname, forward answer, provider owner, and verification timestamp in the operator log. That turns a future 4.7.23 incident into a quick comparison instead of another broad deliverability guessing session.

A practical mailbox or domain example

A server at 203.0.113.20 can reverse to mail.example.net, while mail.example.net points to 203.0.113.21. Both records exist, but the loop is inconsistent and Gmail can still flag the connection.

When the sending IP is shared, document that limitation explicitly. A small sender may have no ability to change PTR even though the message domain’s DNS is fully under its control. In that case, open a provider ticket with the exact IP, current PTR, forward lookup, timestamp, and Gmail diagnostic rather than repeatedly editing SPF or DKIM. If the provider rotates the outbound IP, repeat the forward/reverse check on the new path before concluding the incident is fixed. For self-hosted relays, keep hostname choice stable and ensure the HELO/EHLO identity is sensible alongside rDNS, but do not conflate those checks with DMARC alignment. The operational benefit of a transport map is that each identity has an owner: PTR belongs to the IP reverse zone, A/AAAA belongs to forward DNS, SPF belongs to the envelope policy, and DKIM/DMARC belong to message-domain authentication.

The minimum useful change record

Store the sending IP, PTR answer, forward answer, TTLs, Gmail code, first failure time, and a fresh successful delivery after the correction. That evidence separates a DNS repair from a coincidental recovery in reputation.

Conditions that should remain unknown or retryable

Do not change SPF, DKIM, or DMARC merely because the word “DNS” appears in the error. Those controls authenticate domains in the message; PTR verifies the infrastructure identity of the connecting IP.

Field checklist

• Capture the raw evidence for Gmail 4.7.23 5.7.25 PTR forward reverse DNS mismatch before editing DNS, queue state, or mailbox metadata.
• Confirm the cited mechanism using gmail-guidelines, gmail-faq rather than a generic deliverability score.
• Keep a known-good control case so the failing layer can be compared without changing several variables at once.
• Apply the narrow repair described for Gmail 4.7.23 or 5.7.25: prove PTR and forward DNS point back to the same sending IP and preserve a rollback or retry path.
• Repeat the original failing test after the change; do not substitute a different checker as proof of recovery.
• Store timestamp, affected identity, raw result, action taken, and the post-change result in the operator log.