Why am I getting Google bounces due to PTR record issues, even though my setup seems compliant?
Published 12 Jun 2025
Updated 9 Oct 2026
15 min read
Summarize with
Updated on 9 Oct 2026: We clarified Gmail PTR troubleshooting with DNS cache checks, IPv6 authentication, and correct retry handling.
Google is bouncing the mail because the sending IP fails its reverse DNS identity check. A setup can pass SPF, DKIM, and DMARC, and still fail this check. Google does not only ask, "does the IP have a PTR record?" It also checks whether the hostname named in that PTR resolves back to the same sending IP. If the hostname points at an old server, a CDN edge, a cloud load balancer, or a different address without including the sending IP, the result looks like a PTR problem even though a PTR record exists.
Google can report the same DNS identity problem as a temporary 4.7.23 deferral or a permanent 5.7.25 rejection for that delivery attempt. Both responses cover a missing PTR record or a forward DNS entry that does not reference the connecting IP. That is why a dashboard can say "SPF pass" and "DMARC pass" while Gmail still defers or rejects the same campaign. These meanings are documented in Google's SMTP error reference.
- PTR exists: The IP has a reverse DNS record, but it points to a hostname with bad forward DNS.
- Forward DNS fails: The PTR hostname has no current A or AAAA record, or its matching address family does not include the sending IP.
- Old DNS remains: A migration left the hostname pointing at a retired mail server or legacy app server.
- Wrong owner asked: The DNS team is checking domain records while the IP owner controls reverse DNS.
Start with the IP in the bounce, follow it to the PTR hostname, then resolve that hostname forward. Google's IP address requirements specify both lookups, so the existence of a PTR record alone does not establish compliance.
Why authentication passes but PTR fails
If the setup seems compliant, the missing piece is usually that compliance was checked at the domain authentication layer, not at the sending IP identity layer. SPF checks whether the connecting IP is authorized for the envelope sender domain. DKIM verifies a signature and the signed message content. DMARC requires passing SPF or DKIM with an authenticated domain that matches the visible From domain under relaxed or strict domain matching rules. PTR is a separate receiver-side hygiene check on the actual IP that connected to Google.
This distinction matters because many email teams only control the visible sending domain and its authentication records. The PTR record sits in the reverse DNS zone for the IP address, under in-addr.arpa for IPv4 or ip6.arpa for IPv6. That zone is usually controlled by the sending platform, hosting provider, or network operator. Adding a PTR to an ordinary domain DNS zone does not configure reverse DNS for the sending IP. The hostname returned by the PTR can sit under your domain, which means your DNS team still has to make the forward A or AAAA record match.
The part most teams miss
Google expects the sending IP to have a PTR record, and it expects the forward DNS for that PTR hostname to include the sending IP. If no address in the matching address family matches, the server fails this check even when SPF, DKIM, and DMARC pass.
- Reverse side: The sending IP must return a hostname through PTR.
- Forward side: That hostname must resolve back to the same sending IP.
- Owner split: The IP provider handles PTR, while the owner of the PTR hostname handles its forward DNS.
What Google is checking
Google's check is easiest to understand as a loop called forward-confirmed reverse DNS (FCrDNS). The receiver sees the connecting IP, asks reverse DNS for the hostname, then asks normal DNS for the IP addresses of that hostname. If none of the returned addresses matches the original sending IP in the same address family, the server does not meet Google's IP address requirement for mail sent to personal Gmail accounts.
Gmail forward-confirmed reverse DNS check linking the sending IP, PTR hostname and matching A or AAAA record.
A complete PTR setup has both directions in place. If the PTR hostname has two A records and neither is the sending IP, the forward check fails. Multiple A or AAAA records are valid when the matching address family includes the sending IP; keep legitimate addresses and remove only stale targets. A hostname resolving only to an old server or cloud edge still fails. The standard reverse IP check defines success by whether the connecting IP is included in the forward results.
|
|
|
|---|---|---|
PTR lookup | Hostname returned | No hostname |
Forward lookup | Includes sending IP | Sending IP absent |
Address family | IPv4 to A, IPv6 to AAAA | Only the other family matches |
Record cleanup | Current target | Only an old target |
Common PTR checks that sit outside normal DMARC pass/fail labels.
How to prove the mismatch
Use raw DNS output before changing records. The Google SMTP response quoted in the bounce or the provider's delivery log should identify the rejected sending IP. Use that exact public IP, not a provider range, private server address, website A record, or inbound MX address. NAT, an SMTP relay, or a rotating IP pool changes which IP reaches Google. Suped's domain health checker checks surrounding authentication DNS issues, but direct reverse and forward lookups diagnose the PTR chain.
IPv4 reverse and forward DNS checksbash
# Documentation placeholders: replace both the IP and hostname # with the values from the failed delivery. # 1. Find the PTR hostname for the sending IPv4 address dig +short -x 192.0.2.25 # 2. Check the A record for the hostname returned by PTR dig +short mail.example.com A # 3. The A result must include 192.0.2.25
If the forward hostname is mail.example.com and it resolves only to an old application server instead of the sending IP, Google has a valid reason to reject. The fix is a corrected A record for IPv4 or AAAA record for IPv6, or a PTR hostname that already points forward to the sending IP. Remove stale targets only after confirming that no active service uses them.
Send a real message through the affected platform to Suped's email tester to inspect its sending IP, authentication results, and reverse DNS. A test delivered to Suped can use a different outbound IP than a Gmail delivery, so confirm the failed Gmail route with its bounce or SMTP log.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
When the sending provider uses a branded subdomain, the hostname in the PTR can sit under your domain while the IP is owned by the provider. That split is where mistakes happen. The provider says the PTR exists. The DNS host says the domain records exist. Google sees that the two records do not complete the same identity loop.
Do not ask the wrong team first
Your public DNS provider usually cannot create PTR for an IP it does not own. Your sending provider cannot always clean up forward A and AAAA records under your domain. Give each owner the specific record they control.
- IP owner: Confirm the PTR hostname for the exact sending IP in the bounce.
- DNS owner: Make the hostname include the sending IP in the matching address family, and remove verified stale targets.
- Mail owner: Retest the Gmail route from the same platform after DNS caches have updated.
Check DNS status and cached answers
An empty dig +short result hides the reason for the failure. Show the response status, record TTLs, and authority section, then compare public resolvers with your local result. A hostname that works only inside a private network or split-horizon DNS setup is insufficient for Gmail. Use the same failed sending IP and its returned PTR hostname for every comparison.
Show DNS status and TTLs through public resolversbash
# Replace these documentation placeholders with the bounced IP # and the hostname returned by its PTR lookup. dig @8.8.8.8 -x 192.0.2.25 +noall +comments +answer +authority dig @8.8.8.8 mail.example.com A +noall +comments +answer +authority # Compare with a second public resolver. dig @1.1.1.1 -x 192.0.2.25 +noall +comments +answer +authority dig @1.1.1.1 mail.example.com A +noall +comments +answer +authority # For IPv6, use the exact IPv6 address and query AAAA instead of A.
|
|
|
|---|---|---|
NOERROR with an answer | DNS answered the query | Check that the PTR hostname resolves back to the sending IP |
NOERROR without the requested record | The name exists but lacks the requested record type | Confirm PTR, A, or AAAA with the record owner |
NXDOMAIN | The queried name does not exist | Check the authoritative zone and cached negative answer |
SERVFAIL or REFUSED | Resolution failed or the query was refused | Investigate authoritative DNS, delegation, and DNSSEC where applicable |
DNS response codes distinguish missing records from lookup failures.
If public resolvers disagree, ask the relevant record owner to check every authoritative nameserver for the reverse zone and the forward zone. Persistent SERVFAIL warrants checking DNSSEC and delegation rather than waiting for a record TTL alone. Google's DNS troubleshooting documentation describes these resolution failures.
A corrected record can remain hidden behind cached old answers. A previously missing PTR or forward record also has a negative cache lifetime, defined by the SOA information in the negative response. RFC 2308 explains this negative caching. Allow the relevant old record TTLs or negative TTL to expire, then test a fresh Gmail delivery. Lowering the new record TTL does not shorten an answer already cached by another resolver.
Check IPv6 separately
A dual-stack mail server can pass every IPv4 check and still connect to Gmail over IPv6. Use the sending address identified in Google's response, not the destination server address printed elsewhere in the log. If that address contains colons, run the reverse lookup against that exact IPv6 address, then confirm that the returned hostname has an AAAA record containing the same IPv6 address. A valid IPv4 PTR and A pair does not cover an IPv6 connection.
Google also documents an IPv6 authorization error under 550 5.7.1 mentioning "PTR records and authentication". When that wording appears, verify reverse DNS and SPF or DKIM for the actual IPv6 sending path. The 5.7.1 code alone has other meanings, so read the full response before choosing a fix.
IPv6 reverse and forward DNS checksbash
# Documentation placeholder: use the exact IPv6 address # shown as the sending address in the Google response. dig +short -x 2001:db8::25 # Check the AAAA record for the hostname returned by PTR dig +short mail.example.com AAAA # The AAAA result must include 2001:db8::25
If the provider cannot set IPv6 PTR
Use the mail server or sending provider's supported setting to stop outbound SMTP from using IPv6 until the provider can create the matching IPv6 PTR. Verify that the outbound setting persists after a reboot or redeployment. Do not assume that deleting an unrelated website AAAA record will change the mail server's outbound route.
- Exact address: Test the IPv6 address printed in the rejection, not the server's IPv4 address.
- Matching family: Use PTR plus AAAA for IPv6, and PTR plus A for IPv4.
- Controlled fallback: Route outbound SMTP over a compliant IPv4 address until IPv6 reverse DNS is ready.
Why PTR bounces can start suddenly
Since February 2024, Google's published requirements for mail sent to personal Gmail accounts have required valid forward and reverse DNS for all senders. Bulk senders have additional authentication and subscription requirements. Google's sender requirements FAQ defines bulk senders as sending close to 5,000 messages or more within 24 hours, counted across the same primary domain, and says enforcement increased starting in November 2025. PTR requirements apply below that volume too.
The common trigger is an operational change. A new sending IP, a platform migration, a retired ecommerce server, a DNS provider move, or an outbound switch from IPv4 to IPv6 can expose a missing or stale record. The next time Google checks the full loop, the sender fails PTR even though the visible authentication records still look normal.
|
|
|
|---|---|---|
IP pool change | New sending IP | SMTP delivery logs |
IPv6 route | Different address family | Bounce IP |
DNS migration | Old target remains | A or AAAA records |
TTL timing | Caches differ | Resolver output |
Shared hostname | Other service uses it | Asset inventory |
Sudden PTR bounces usually come from routing changes or DNS cleanup gaps.
Who needs to fix what
The cleanest way to resolve this is to split the task by ownership. Do not ask everyone to "check DNS". Ask the sending platform or IP owner for the reverse DNS facts, then ask the owner of the PTR hostname to make the forward record match. If the same team owns both sides, the fix is still easier when the two records are treated separately. For shared infrastructure, keep the provider hostname when its reverse and forward DNS are correct; FCrDNS checks the server hostname rather than requiring it to equal the visible From domain.
Sending platform or IP owner
- PTR control: Set or confirm reverse DNS for the exact sending IP.
- IP inventory: Confirm every outbound IP used for the failed Google traffic.
- Hostname choice: Use a stable, publicly resolvable mail hostname that is not shared with a web app.
Owner of the PTR hostname
- Forward DNS: Include the sending IP in the PTR hostname's A or AAAA results.
- Stale records: Remove old A or AAAA records that no longer belong.
- Change control: Verify no active service depends on that hostname.
Message to send to the record ownerstext
Please investigate the failed Gmail delivery at [timestamp and timezone]. Full Google SMTP response: [paste the complete response]. Confirm the public outbound sending IP used for this attempt. For that IP, confirm the PTR hostname and its public DNS lookup status. Then confirm the matching A or AAAA results include that same IP. If they do not, correct the forward record or PTR hostname. Remove only verified stale targets, and confirm the relevant cache TTLs.
Before deleting anything, confirm the hostname is not used by another active service. Old application servers, tracking endpoints, and internal integrations sometimes remain attached to mail-looking hostnames. If another service still needs the old target, move that service to a different hostname first.
For a self-managed server, use a publicly resolvable fully qualified domain name (FQDN) in the SMTP HELO or EHLO greeting, normally the same stable mail hostname used for PTR. RFC 5321 specifies the SMTP hostname rules. Check this as server configuration hygiene alongside the reverse and forward DNS lookups.
What not to change first
Do not start by rebuilding SPF, rotating DKIM keys, or changing the DMARC policy unless the bounce also shows those checks failing. PTR bounces are about the connecting IP identity. Changing unrelated authentication records adds risk and usually leaves the Google 5.7.25 error untouched.
A safe order of operations
- Find the IP: Use the sending IP identified in the Google SMTP response or delivery log.
- Check PTR: Resolve the IP to the hostname.
- Check forward DNS: Confirm the matching A or AAAA results include the sending IP.
- Clean stale targets: Remove old A or AAAA records after confirming ownership and active dependencies.
- Retest delivery: Allow the relevant cached answers to expire, then send a new message to Gmail.
If Google returns 4.7.23, keep affected messages queued with normal retry backoff while correcting DNS; avoid repeated manual retries. A 5.7.25 response rejects that delivery attempt permanently, so resend failed messages after fixing DNS if needed. Fix any authentication failures separately. For deeper background, review what PTR records do and why reverse DNS matters for email sending.
Use Suped to check related authentication issues
Suped's product helps investigate authentication issues alongside a PTR incident. Suped's DMARC reporting maps sending sources present in receiver reports, while automated issue detection and alerts identify related SPF, DKIM, or DMARC failures. DMARC reports are not a complete log of PTR rejections. Use the IP in the Google response and direct DNS lookups for the PTR diagnosis itself.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's DMARC monitoring helps show which reported sending source is failing authentication and whether the issue is isolated or widespread. Check reputation separately if errors change after the DNS fix. Suped's blocklist monitoring checks domain and IP listings across blocklists (blacklists) when PTR bounces appear alongside reputation problems.
Suped cannot set a PTR record for an IP owned by another network. Identify the source, check its reported authentication status, and send the exact connecting IP with the PTR or forward DNS correction to the record owner.
PTR troubleshooting practices
Best practices
Check the PTR hostname forward lookup for the bounced IP before changing authentication.
Keep a DNS migration checklist that includes old mail hostnames and retired A or AAAA records.
Ask the sending provider for the exact public outbound IP used by the bounced Gmail message.
Common pitfalls
Treating a PTR as valid without checking that its hostname resolves back to the sending IP.
Assuming a domain DNS provider can set reverse DNS for a sending IP without delegated control.
Leaving old ecommerce or app server records attached to branded mail hostnames after migrations.
Expert tips
Use the sending IP named in the Google SMTP response rather than a guessed provider range.
Document who owns PTR and forward DNS, and where SMTP delivery logs live, before sending changes.
Retest a live Gmail delivery after the old DNS answers expire, including cached missing records.
Verify Gmail delivery after the DNS fix
Check the reverse and forward DNS for every active outbound IP in the affected route. One successful test does not validate an entire rotating IP pool. For dual-stack servers, verify both IPv4 and IPv6 if both are used for Gmail delivery.
After the DNS change, allow the relevant cached answers to expire, send a fresh message to Gmail, and inspect the new SMTP response. Keep the provider ticket specific: the complete Google response, timestamp with timezone, sending IP, PTR hostname, forward DNS result, and expected matching IP. Record whether the failed connection used IPv4 or IPv6.
The clean fix
A working PTR configuration has a PTR for every outbound sending IP and a publicly resolvable hostname whose matching A or AAAA results include that IP. Gmail also evaluates authentication and sender reputation before accepting a message.
