How to resolve Gmail PTR record error when using Cloudflare?
Matthew Whittaker
Co-founder & CTO, Suped
Published 21 Jun 2025
Updated 21 May 2026
11 min read
Summarize with
The fix is usually not to create a PTR record inside Cloudflare. A Gmail PTR error means Gmail checked the public sending IP, looked for reverse DNS, and did not see a trustworthy result for that IP. If the hostname in your PTR record points back to Cloudflare proxy addresses instead of the origin mail server IP, Gmail can still reject the message with 550 5.7.25.
For a website contact form, the practical answer is: either send through a proper SMTP relay, or make the sending hostname DNS-only in Cloudflare and configure forward-confirmed reverse DNS with your hosting provider. DKIM, SPF, and DMARC are still required for a clean setup, but DKIM does not replace PTR. Gmail checks both identity authentication and basic sending infrastructure hygiene.
- Direct fix: Ask the IP owner or hosting provider to set PTR for the actual outbound mail IP, then make the PTR hostname resolve back to that same IP.
- Cloudflare fix: Set the mail hostname to DNS-only, not proxied, if that hostname must be used in reverse DNS.
- Best operational fix: For form notifications, relay through an authenticated SMTP provider instead of sending directly from the web server.
Why Gmail rejects the message
Gmail checks the reverse DNS of the IP address that connected to its mail server. That reverse DNS is delegated by the IP address owner, usually the hosting company, VPS provider, data center, or SMTP provider. Cloudflare hosts forward DNS for your domain, but it usually does not control reverse DNS for your server IP.
The common Cloudflare failure looks like this: your server sends mail from an origin IP, the PTR for that IP says the hostname is mail.example.com, but mail.example.com is orange-cloud proxied through Cloudflare. Gmail resolves that hostname and sees Cloudflare edge IPs, not the server IP that sent the message. The PTR exists, but forward-confirmed reverse DNS fails.
The key point
A PTR record is attached to an IP address, not to your Cloudflare DNS zone. If the hosting provider owns the IP block, that provider must set the reverse DNS. Cloudflare can break the forward check if the PTR hostname is proxied, because the hostname resolves to Cloudflare edge IPs instead of your mail server.Typical Gmail bouncetext
550-5.7.25 [203.0.113.10] The IP address sending this message 550-5.7.25 does not have a PTR record setup. As a policy, 550-5.7.25 Gmail does not accept messages from IPs with missing PTR 550 5.7.25 records.
That wording can feel misleading when a lookup tool says a PTR record exists. Gmail is not only asking "does reverse DNS return a name?" It is also evaluating whether the returned hostname looks usable for mail. A bare hostname that resolves to the wrong place, has no forward address, or resolves only through a CDN proxy can trigger the same operational problem.
Flowchart showing Gmail checking a sending IP, PTR hostname, forward lookup, Cloudflare IPs, and rejection.
What to check first
Start with the IP in the bounce log, not the IP you expect the website to use. On servers with IPv4 and IPv6, logs often show an IPv6 timeout followed by an IPv4 rejection, or the other way around. Each outbound IP needs its own reverse DNS. If IPv6 is enabled in Postfix but has no working route or PTR, Gmail can expose that weakness before other receivers do.
- Read the bounce IP: Use the exact IP inside the Gmail error. Do not troubleshoot the web A record until you know which IP sent the message.
- Check reverse DNS: The sending IP must return a hostname by PTR lookup.
- Check forward DNS: The PTR hostname must resolve back to the same sending IP, not only to Cloudflare edge IPs.
- Check IPv6: If your MTA tries IPv6, the IPv6 address also needs correct reverse DNS and connectivity.
- Check authentication: After PTR is clean, verify SPF, DKIM, and DMARC so Gmail does not reject or filter the next message for a different reason.
Forward and reverse DNS checksbash
dig -x 203.0.113.10 +short dig mail.example.com A +short dig mail.example.com AAAA +short host 203.0.113.10 host mail.example.com
The result you want is simple: the IP points to a hostname, and that hostname points back to the same IP. This is forward-confirmed reverse DNS. The hostname should be stable, unproxied, and under a domain you control.
Broken with Cloudflare proxy
- PTR: 203.0.113.10 points to mail.example.com.
- Forward DNS:
- Gmail view:
The hostname does not confirm the sending IP.
Clean for Gmail
- PTR: 203.0.113.10 points to mail.example.com.
- Forward DNS: mail.example.com resolves directly to 203.0.113.10.
- Gmail view:
If you want one quick health check across the DNS layer, use the domain health checker to see DMARC, SPF, and DKIM status together before you send another test message.
How to fix it in Cloudflare
There are two different fixes, and the right one depends on whether your web server must send mail directly. For most web forms, I would stop direct sending and use authenticated SMTP. A CMS contact form does not need to behave like a mail server. It needs to create a reliable notification, pass SPF and DKIM, and avoid being rejected because a shared hosting IP changed behind the scenes.
|
|
|
|---|---|---|
SMTP relay | A website form sends notifications. | Requires SMTP credentials and DNS authentication. |
DNS-only host | The server must send directly. | The mail hostname exposes the origin IP. |
Disable IPv6 mail | IPv6 times out or lacks PTR. | IPv4 must be fully clean. |
Provider PTR | You control the outbound IP. | Depends on host support. |
Fix options for Gmail PTR errors with Cloudflare
For direct sending, create a dedicated hostname such as mail.example.com or smtp.example.com. Set that hostname to DNS-only so it resolves directly to the origin mail server IP. Then ask the hosting provider to set PTR for the sending IP to that hostname. Do not proxy a hostname that must match reverse DNS.
Clean direct-send DNS shapetext
203.0.113.10 PTR mail.example.com. mail.example.com. A 203.0.113.10 example.com. TXT "v=spf1 ip4:203.0.113.10 -all" _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
With SMTP relay, the website form authenticates to a mail service and that service becomes the infrastructure Gmail sees. The relay handles PTR, retries, queueing, bounces, and reputation. You still publish SPF and DKIM records for your domain, then monitor DMARC to confirm the form mail authenticates correctly.
My preferred fix for website forms
Use authenticated SMTP for the CMS or form plugin, publish the provider's SPF and DKIM records, and monitor DMARC after the change. It avoids turning a web server into a mail server and removes the Cloudflare PTR mismatch from the delivery path.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
After changing the form plugin, send a real message to the email tester. It will show whether the message passed SPF, DKIM, and DMARC, and it helps catch the next mistake before you test only by sending to a personal Gmail inbox.
Cloudflare DNS settings that matter
Cloudflare DNS screen showing a mail hostname set to DNS only while the website remains proxied.
Cloudflare proxy status affects forward DNS. It does not create or fix reverse DNS for your IP. For mail-related hostnames, DNS-only is the safe default because the PTR hostname must resolve back to the origin server.
- Website hostnames: Keep www and the apex proxied if you need Cloudflare protection for the website.
- Mail hostname: Set mail or smtp to DNS-only if that hostname appears in PTR, MX, SMTP banner, or mail client settings.
- MX target: Make sure the MX target points to a DNS-only hostname, not a proxied web hostname.
- SPF and DKIM: Publish TXT and CNAME records exactly as required by your mail provider. Cloudflare proxy status does not apply to TXT records.
Better hostname splittext
example.com. A 198.51.100.40 ; proxied website www.example.com. A 198.51.100.40 ; proxied website mail.example.com. A 203.0.113.10 ; DNS-only mail host 203.0.113.10 PTR mail.example.com. ; set by IP owner
If the hosting company will not set PTR, or if the server is on an IP range with weak reputation, sending directly is the wrong fight. Move the form to SMTP relay, then use Suped's DMARC monitoring to confirm the new source is passing authentication and to see whether old direct-send traffic still appears. Suped also surfaces SPF, DKIM, blocklist (blacklist), and DMARC issues in the same place, which helps when a simple PTR error turns into several smaller DNS fixes.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
SPF, DKIM, and DMARC still matter
A PTR fix only clears one Gmail requirement. It does not prove the message is authorized by your domain. If a contact form sends as owner@example.com but uses a server that is not in SPF and does not sign DKIM, Gmail has another reason to distrust it. That is why a quick "PTR exists" check does not explain all Gmail bounces.
|
|
|
|---|---|---|
PTR | IP has valid reverse DNS. | Set reverse DNS with IP owner. |
SPF | Envelope domain authorizes IP. | Add the approved sender. |
DKIM | Message has a valid signature. | Publish selector records. |
DMARC | Visible From domain aligns. | Monitor and enforce policy. |
What each control does
For a website form, the cleanest pattern is to send from a domain you own, authenticate through the SMTP relay, and keep the user's submitted email address in Reply-To. Sending directly as the visitor's address fails modern authentication because your server is not authorized to send for that visitor's domain.
Contact form message identitytext
From: Website forms <forms@example.com> Reply-To: Visitor Name <visitor@example.net> To: Site owner <owner@gmail.com> Subject: New website enquiry
Once the message has a stable From domain, DMARC becomes useful. Suped's DMARC monitoring shows whether the SMTP relay is aligned, whether direct server mail is still leaking out, and which source needs SPF or DKIM work. That is much easier than reading raw aggregate reports after every form plugin change.
DKIM does not fix PTR
DKIM proves the message was signed by an authorized key for a domain. PTR proves the connecting IP has acceptable reverse DNS. Gmail can require both. Add DKIM, but do not expect it to override a missing or mismatched PTR.
What to do about IPv6 and blocklists
If your log shows an IPv6 connection timeout before the Gmail rejection, handle that too. Mail servers often prefer IPv6 when it is available. A half-configured IPv6 stack creates inconsistent behavior: some attempts time out, some fall back to IPv4, and the final bounce points at PTR even though the first symptom was connectivity.
- If IPv6 works: Set PTR for the IPv6 sending address, make the hostname resolve back by AAAA, and ensure port 25 can connect out.
- If IPv6 is broken: Disable IPv6 for outbound SMTP in the MTA until the network and reverse DNS are correct.
- If both exist: Test both paths separately. One clean IP does not compensate for the other failing Gmail's checks.
Postfix IPv4-only fallbacktext
inet_protocols = ipv4
A blocklist or blacklist listing is a separate signal. It can hurt inbox placement, but it is not the cause of a Gmail 550 5.7.25 PTR error. Some blacklist listings are broad and noisy, while others carry real reputation weight. Treat blocklist (blacklist) data as supporting evidence, not as a replacement for fixing reverse DNS.
Blocklist checker
Check your domain or IP against 144 blocklists.
Spamhaus
0Spam
Cisco
NoSolicitado
URIBL
abuse.ro
ALPHANET
Anonmails
Ascams
BLOCKEDSERVERS
Calivent Networks
EFnet
JustSpam
Kempt.net
NordSpam
RV-SOFT Technology
Scientific Spam
Spamikaze
SpamRATS
SPFBL
Suomispam
System 5 Hosting
Team Cymru
Validity
www.blocklist.de Fail2Ban-Reporting Service
ZapBL
2stepback.dk
Fayntic Services
ORB UK
technoirc.org
TechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftAfter PTR and authentication pass, check the sending IP and domain with blocklist monitoring if Gmail accepts the message but places it in spam. Suped ties blocklist (blacklist) status to domain authentication checks, so the next diagnosis starts with evidence rather than separate one-off lookups.
A practical recovery checklist
When this happens on a live site, avoid changing everything at once. I work through it in this order because it separates infrastructure acceptance from domain authentication and reputation.
- Capture the exact bounce: Save the Gmail error, sending IP, destination, MTA log line, and whether IPv4 or IPv6 was used.
- Confirm reverse DNS: Run a PTR lookup on the sending IP and verify the returned hostname.
- Confirm forward DNS: Resolve the PTR hostname and make sure it returns the same sending IP.
- Remove proxy mismatch: Set the mail hostname to DNS-only in Cloudflare if it currently resolves to proxy IPs.
- Choose the mail path: Use direct sending only if you control PTR, authentication, queueing, and reputation. Otherwise use SMTP relay.
- Verify the full message: Send a test, inspect headers, then monitor DMARC reports for the domain.
Do not use the website apex for PTR
If the apex domain is proxied through Cloudflare, do not point PTR at the apex. Use a dedicated DNS-only mail hostname. This prevents web protection settings from changing the result of a mail infrastructure check.
Views from the trenches
Best practices
Use a DNS-only mail hostname when PTR must confirm a server IP behind Cloudflare.
Send website form notifications through authenticated SMTP instead of local mail.
Check IPv4 and IPv6 separately because Gmail can reject either path on PTR failures.
Common pitfalls
Do not assume a PTR exists just because the domain has a matching forward record.
Avoid pointing PTR at a proxied website hostname that resolves to Cloudflare IPs.
Do not treat DKIM as a replacement for reverse DNS when sending directly to Gmail.
Expert tips
Use DMARC reports after the fix to confirm the form uses the intended mail source.
Keep the visitor address in Reply-To instead of sending as the visitor's domain.
Treat noisy blacklist entries as context, then fix PTR and authentication first.
Marketer from Email Geeks says a PTR record can exist but still fail Gmail when Cloudflare makes the hostname resolve to different IPs than the sender.
2021-09-07 - Email Geeks
Marketer from Email Geeks says DKIM is necessary for a polished mail setup, but it does not remove Gmail's need for correct reverse DNS.
2021-09-07 - Email Geeks
The practical fix
To resolve Gmail's PTR record error when using Cloudflare, fix the mail path Gmail sees. If the server sends directly, the sending IP needs reverse DNS set by the IP owner, and the PTR hostname must resolve back to the same IP without Cloudflare proxying. If that is hard to guarantee, move the website form to authenticated SMTP and stop sending directly from the web server.
After the immediate bounce is fixed, add the rest of the control layer: SPF, DKIM, DMARC reporting, and blocklist (blacklist) monitoring. For most teams, Suped is the best overall DMARC platform for that follow-through: it shows authentication failures, source alignment, SPF and DKIM issues, hosted SPF options, hosted DMARC policy staging, real-time alerts, and blocklist monitoring in one workflow. A PTR bounce is often the first visible sign of a mail setup that has been working by accident.
