Gmail refused your message because the IP address that delivered it has no reverse DNS (PTR) record, or the PTR record names a hostname that doesn’t resolve back to that IP. Check the address below, then get the PTR record set by whoever owns the IP: your hosting company, cloud provider or ISP.
Last verified 1 October 2026.
The bounce your server returns usually quotes Gmail’s reply like this:
550-5.7.25 The IP address sending this message does not have a PTR record setup, or the corresponding forward DNS entry does not match the sending IP. As a policy, Gmail does not accept messages from IPs with missing PTR records.
Google’s own error reference describes the code as: “This message was blocked because the sending IP address doesn’t have a PTR record, or the forwarding DNS entry doesn’t reference the sending IP address. Gmail requires that sending IP addresses have a PTR record.”
Gmail runs two lookups on the IP that connected to it, and both must succeed:
mail.example.com. Google: “The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname.”This is about the server’s IP address, not your domain. SPF, DKIM and DMARC can all pass and the message is still refused.
Google’s error reference lists two temporary codes for the same problem. Your server retries these, but the messages stay deferred until reverse DNS is fixed:
451 4.7.23 The sending IP address for this message doesn’t have a PTR record, or the PTR record’s forward DNS entry doesn’t match the sending IP address. To protect users from spam, your email has been temporarily rate limited.
421 4.7.0 The IP address sending this message does not have a PTR record, or the corresponding forward DNS entry does not point to the sending IP. To protect our users from spam, email sent from your IP address has been temporarily rate limited.
Sources: Google, Email sender guidelines (Infrastructure configuration requirements: IP addresses); Google Workspace, Gmail SMTP errors and codes (checked 1 October 2026).
Enter the IP address from the bounce (IPv4 or IPv6; how to find it). The lookups run in your browser against public DNS: the PTR record of the IP, then the A or AAAA record of every hostname it names, the same two checks Gmail describes.
A pass means the IP meets Gmail’s reverse DNS rule. Delivery also depends on SPF, DKIM, DMARC and the IP’s reputation.
What this can and can’t tell you: it reads reverse and forward DNS right now, through Cloudflare’s public resolver (Google’s when Cloudflare’s fails), and follows CNAMEs in the reverse zone (classless delegation, RFC 2317). It can’t see which IP a past message used, or what Gmail’s resolvers had cached when it bounced. It checks up to five PTR hostnames. Notes about generic-looking hostnames are advice, not part of Gmail’s rule.
The IP that matters is the one that connected to Gmail, which is the public address of the last server your message left from. To find it:
[203.0.113.25] or [2001:db8::25]. The bounce’s diagnostic section also names the server that tried to deliver it (look for Reporting-MTA or the host that generated the bounce).Received: line added by the receiving provider shows the server that connected to it, for example from mail.example.com (mail.example.com [203.0.113.25]).Check IPv6 too. If the server has an IPv6 address, it may connect to Gmail over IPv6, and then that address needs its own PTR record and AAAA record. Google notes that an IPv6 error “could mean that the PTR record for the sending server isn’t using IPv6.” A server with good IPv4 reverse DNS and none on IPv6 is a common cause; either add the IPv6 PTR or make the mail server send over IPv4 only.
The PTR record lives in the reverse DNS zone of the IP address (in-addr.arpa for IPv4, ip6.arpa for IPv6), and that zone belongs to whoever owns the address. Adding a “PTR” record at your domain’s DNS host has no effect. The fix is in your hosting, cloud or ISP account, or a support ticket.
Choose a name on a domain you control, such as mail.yourdomain.com, and create an A record (and an AAAA record for an IPv6 address) pointing to the sending IP. AWS and Azure require this forward record before they accept the PTR. Google’s guidelines recommend reverse DNS “that point[s] to your domain”; a provider’s default name can satisfy the forward check, but your own name is better practice.
az network public-ip update --resource-group MyGroup --name MyIp --reverse-fqdn mail.yourdomain.com. If the IP has no PTR yet, Azure also requires a DNS name label on it (add --dns-name mylabel). The name must resolve to that IP. Azure-owned IPv6 addresses can’t have a PTR (Azure guide).mail.yourdomain.com). You can’t add a PTR record separately (DigitalOcean docs).Set the mail server’s hostname, the name it sends in EHLO, to the PTR hostname. Gmail’s 5.7.25 check doesn’t compare them, but SMTP (RFC 5321) expects the EHLO name to be a hostname that resolves, and one consistent name avoids problems at other receivers.
Then check again here. How soon a change shows depends on your provider and on how long resolvers cache the old answer, so if the old result persists, try again later before resending.
If you use Google Workspace, Microsoft 365, Amazon SES, SendGrid or another sending service, Gmail sees their servers, which have reverse DNS in place. A 5.7.25 bounce then means something is delivering directly from its own IP instead: a self-hosted mail server, a website or app with its own SMTP, a printer or scanner, a backup or forwarding server. Point that system at your provider’s SMTP relay (with authentication) and the PTR of its own IP no longer matters to Gmail.
Reverse DNS is one requirement among several. Gmail also expects SPF or DKIM on every message, and bulk senders need SPF, DKIM, DMARC, TLS and a low spam rate. Grade your domain with the free DMARC, SPF and DKIM checker, and see the Gmail, Yahoo and Microsoft bulk sender requirements.
No. A PTR record lives in the reverse DNS zone of the IP address (in-addr.arpa for IPv4, ip6.arpa for IPv6), which belongs to whoever owns the address: your hosting company, cloud provider or ISP. Records you add at your domain’s DNS host don’t affect it. You set the PTR in the provider’s control panel or ask its support team.
Not for 5.7.25. Google’s rule is that the IP has a PTR record and that the hostname it names has an A or AAAA record pointing back to the same IP. Google’s sender guidelines also recommend reverse DNS that points to your domain, so a name such as mail.yourdomain.com is the better choice when you can pick it.
When you send through a provider, Gmail sees the provider’s servers, and those have working reverse DNS. A 5.7.25 bounce means something sent the message directly from its own IP: a self-hosted mail server, a website or app with its own SMTP, a printer or scanner, or a forwarding server. Check the IP in the bounce and point that system at your provider’s relay or fix its PTR.
Both report the same problem: no PTR record, or a PTR hostname whose forward DNS doesn’t point back to the sending IP. 550 5.7.25 is a permanent rejection. 451 4.7.23 is temporary rate limiting, so your server retries, but the messages keep being deferred until the reverse DNS is fixed.
Google doesn’t document how Gmail treats an IP with more than one PTR record. The safe setup is a single PTR record whose hostname resolves back to the IP.