How is 550 5.7.25 different from 550 5.7.1 or 5.7.26?

Different layers, checked at different times. 5.7.25 (RFC 7372, 'Reverse DNS validation failed') is about the *sending IP* — its PTR record, evaluated the moment the connection opens, before your message or its From header even matters. 5.7.1 is a policy refusal, usually an SPF hard-fail or a DMARC reject. 5.7.26 means SPF and DKIM both failed to authenticate the domain. You can have perfect SPF, DKIM, and DMARC and still hit 5.7.25 — because 5.7.25 never looked at your domain. It looked at the IP.

I set a PTR record and Gmail still rejects me. Why?

Because a PTR alone isn't what Gmail validates — it validates FCrDNS (forward-confirmed reverse DNS). The IP's PTR must name a hostname, and that hostname's A/AAAA record must resolve back to the same IP. If your PTR points to mail.example.com but mail.example.com resolves to a different address — an old server, a load balancer, a CDN edge — the reverse half is set but the forward half doesn't confirm it, and Gmail treats that as a failure. Both directions have to agree.

Where do I actually set the PTR record?

Not at your domain registrar, and not in your normal DNS panel. PTR lives in the reverse zone (in-addr.arpa for IPv4, ip6.arpa for IPv6), which is controlled by whoever owns the IP block — your cloud provider, VPS host, or ISP. You set it in their console or by opening a support request. If you're on shared hosting or a shared egress IP, you often can't set it at all, which is its own answer: you need an IP you control.

Views: 16

550 5.7.25: Fix Gmail's Reverse DNS (PTR) Rejection

550 5.7.25: Gmail rejected your mail — the sending IP's PTR is missing or mismatched. Check PTR, forward match, and FCrDNS. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Your mail to Gmail bounces with 550-5.7.25 and a line that reads, verbatim: “The IP address sending this message does not have a PTR record setup, or the corresponding forward DNS entry does not point to the sending IP address.” Nothing reached the inbox, and no amount of tuning SPF, DKIM, or DMARC will move the needle — because Gmail rejected the connection before it ever considered your domain. This is an IP problem, not a domain problem.

Symptoms

The bounce carries 550-5.7.25 and text about a missing PTR record or a forward DNS entry that doesn’t match the sending IP.
It started or worsened after early 2024, when Google tightened enforcement of its sender requirements and began rejecting where it used to shrug.
SPF, DKIM, and DMARC all check out — yet Gmail (and often Yahoo and Outlook) still reject.
Mail from your main platform delivers; mail from a new VPS, a cron script, or a freshly spun-up cloud instance bounces.
dig -x <your-sending-ip> returns NXDOMAIN, a generic provider hostname, or a name that resolves somewhere else entirely.

What 550 5.7.25 Actually Means

Read the code as two facts. The 550 is the SMTP reply (RFC 5321): a permanent failure — retrying the identical connection from the same IP won’t help. The 5.7.25 is the enhanced status code, and RFC 7372 defines it precisely as “Reverse DNS validation failed”: the sending client’s IP address failed a reverse DNS check that the receiver’s policy requires.

What Gmail requires isn’t just a PTR record. It’s FCrDNS — forward-confirmed reverse DNS. Two lookups have to agree:

The reverse lookup on the sending IP (dig -x <ip>) returns a PTR record naming a hostname.
The forward lookup on that hostname (dig A <hostname>) resolves back to the same IP you started with.

If either half is missing, or the two point at different addresses, the round trip doesn’t close, and Gmail reads that as an unauthenticated sender. The reason big receivers insist on this is old and boring: a legitimately-run mail server sits on an IP whose owner bothered to set matching reverse DNS. A botnet host on a hijacked residential IP almost never does. FCrDNS is a cheap, decades-old signal that separates the two — and 5.7.25 is what you get when you land on the wrong side of it.

Top 3 Causes

The sending IP has no PTR at all. A new VPS or cloud instance ships with either no reverse DNS or the provider’s generic default (ec2-…, vps-…, static-…). Neither names your mail host, so there’s nothing to forward-confirm. The tell: dig -x <ip> returns NXDOMAIN or an address you didn’t set.
The PTR exists but doesn’t forward-confirm. Your reverse DNS names mail.example.com, but mail.example.com resolves to a different IP — an old server you migrated off, a proxy, a CDN edge, or a load balancer in front of your real sender. The reverse half is set; the forward half contradicts it. The tell: dig -x gives a clean name, but dig A <that-name> doesn’t return your sending IP.
You’re on an IP you don’t control. Shared hosting, a shared SMTP egress, or a container platform hands you an IP whose PTR belongs to the provider and can’t be changed. The tell: the PTR is the host’s generic name, your support tickets go nowhere, and the fix isn’t a record — it’s a different sending path.

Diagnose with DechoNet

Reverse DNS Lookup takes your sending IP and shows the PTR record it resolves to — the fastest way to see whether reverse DNS exists and what hostname it claims, before you go arguing with a provider.
Email Check pulls your domain’s SPF, DKIM, and DMARC in one pass, so once the IP side is clean you can confirm the domain side isn’t hiding a second, separate bounce reason.

Resolution Checklist

Find your actual sending IP — the one your mail server connects out from, taken from the bounce’s Received chain, not your website’s A record. They’re often different.
Run Reverse DNS Lookup (or dig -x <ip>) and confirm a PTR exists and names your mail hostname — not the provider’s default.
Run dig A <that-hostname> and confirm it resolves back to the exact sending IP. Both directions must match for FCrDNS to pass.
Set or correct the PTR with the IP’s owner — your cloud/VPS console or ISP support — not your domain registrar.
Make your mail server’s HELO/EHLO hostname match the PTR name; a mismatch there feeds the same reputation checks.
Re-test, then allow 24–48 hours for reverse-zone changes to propagate before assuming it’s still broken.

When to Escalate

If you’re on a shared or provider-locked IP you can’t set a PTR for, stop fighting the record. Move to a host that gives you a dedicated IP with reverse-DNS control, or send through an authenticated relay whose IPs already pass FCrDNS.
If PTR and forward confirmation both check out and Gmail still returns 5.7.25, capture the full bounce and check the IP against major blocklists — at that point the reverse DNS is fine and the problem has moved to IP reputation, which is a different fix.