What is a PTR record? Fixing Gmail's 550 5.7.25 email error

A PTR record is reverse DNS: it maps an IP address back to a hostname, the mirror image of an A record. Mailbox providers look it up on every SMTP connection to verify that the sending server is who it claims to be, and Gmail now hard-rejects mail from IPs whose PTR is missing or mismatched — that is the 550 5.7.25 error. If you send through an ESP such as Resend or SendGrid, the PTR belongs to the ESP's IPs and is maintained for you. If you run your own mail server, it is set with your hosting provider — not in your domain's DNS — which is exactly why so many otherwise well-configured senders miss it.

What a PTR record is (and what FCrDNS adds)

An A record answers "which IP does this hostname point to?" A PTR record answers the opposite: "which hostname does this IP belong to?" PTR records don't live in your domain's zone. They live in dedicated reverse zones — in-addr.arpa for IPv4, ip6.arpa for IPv6 — which are delegated to whoever owns the IP address: your ESP, your hosting provider, or your cloud vendor. That one fact explains most PTR failures. You can audit your domain's DNS from top to bottom and never touch the record that matters.

Receivers don't just check that a PTR exists. The standard they apply is forward-confirmed reverse DNS (FCrDNS): the round trip has to close.

1. The sending IP has a PTR record resolving to a hostname.
2. That hostname has an A (IPv4) or AAAA (IPv6) record.
3. That forward record resolves back to the same sending IP.

Google's sender guidelines require exactly this — valid forward and reverse DNS records on sending domains and IPs. A PTR that points at a hostname with no forward record, or whose forward record points somewhere else, fails FCrDNS and is treated as if there were no PTR at all — often worse, because a broken round trip looks like an attempt to forge an identity.

There is a third property receivers check alongside the round trip: the HELO/EHLO banner — the hostname your server announces when it opens an SMTP connection — should match the PTR hostname. A banner/reverse-DNS mismatch is a classic misconfiguration signal; Microsoft goes as far as rejecting a server that introduces itself with the wrong name (550 5.7.506 Access Denied, Bad HELO) and describes that pattern as characteristic of spambot behaviour.

So three things must agree:

IP 203.0.113.10  --PTR-->  mail-a1.acme.com
mail-a1.acme.com --A-->    203.0.113.10        (FCrDNS closes)
SMTP banner: EHLO mail-a1.acme.com             (banner matches)

Why PTR became Gmail's biggest rejection driver

Almost every Gmail compliance checklist published since the 2024 sender requirements covers the same items: SPF, DKIM, DMARC, one-click unsubscribe, spam-rate ceiling. Reverse DNS rarely appears. Part of the reason is structural — the PTR isn't in your domain's DNS, so no SPF/DKIM/DMARC setup flow ever surfaces it, and no DMARC checker can see it.

For years nobody could measure what that omission cost, because SMTP rejection detail existed only in ESPs' private mail-server logs. That changed when Google began including SMTP rejection data in DMARC aggregate reports around July–August 2025. Al Iverson (Spam Resource) and Scott Ziegler (Valimail) analysed the newly visible rejection corpus across the Black Friday / Cyber Monday 2025 period and published the finding in January 2026: "The largest single driver of rejections was infrastructure" — specifically, sending IPs with broken or missing PTR records. By that analysis, Gmail alone rejected tens of millions of messages for this reason within a matter of weeks.

Two details make this more useful than the usual deliverability scare statistic:

• The requirement isn't new — the enforcement is. Google has required valid reverse DNS for years. What changed is that Google warned in November 2025 that sender-requirement enforcement was ramping up, and from December 2025 the previously soft-failing PTR check started returning permanent rejections. A large population of senders had been quietly non-compliant the whole time, and the enforcement flip exposed them all at once.
• The blocked mail was largely legitimate. These weren't shady senders on shady lists — they were ordinary senders failing a basic infrastructure check that nothing in their tooling monitored. Iverson's analogy: a mail server on an IP without reverse DNS is a car driving around without a license plate.

Whether enforcement has tightened further during 2026 is not publicly documented. As of August 2026, the December 2025 behaviour — hard rejection — is the baseline to assume.

The exact error, and how other providers treat missing PTR

The Gmail rejection string reads, verbatim:

550-5.7.25 The IP address sending this message does not have a PTR record
550 5.7.25 setup, or the corresponding forward DNS entry does not match
           the sending IP.

Gmail also has a temporary sibling, 451 4.7.23 — the same diagnosis, but deferred and retried rather than permanently rejected. If you're seeing 4.7.23 deferrals, treat them as the warning shot before the 5.7.25 wall.

Provider	Treatment of a missing or mismatched PTR
Gmail, IPv4	Documented requirement; enforced as hard 550 5.7.25 rejections since December 2025, with 451 4.7.23 as the temporary form
Gmail, IPv6	Stricter still: the sending IPv6 address must have a PTR whose hostname resolves back via AAAA to the same address, and SPF or DKIM must pass — a missing v6 PTR is effectively fatal, not merely a negative signal (OneUptime's write-up of the policy)
Microsoft (Outlook.com / M365)	Publishes no missing-PTR code, but rejects HELO/hostname misconfiguration outright with 550 5.7.506 and broadly distrusts anonymous cloud IP ranges, which a generic or absent PTR advertises

The IPv6 asymmetry deserves emphasis, because dual-stack servers often send over IPv6 without their owners realising. Google's rationale is that IPv6 address space is too vast for per-IP reputation, so it leans harder on DNS and cryptographic proof of identity instead. On IPv4 a missing PTR degrades your standing; on IPv6 it ends the conversation.

How to check yours in 60 seconds

First find the IP your mail actually leaves from. For a self-hosted server that's your public IP; for an ESP, send yourself a message and read the last external hop in the Received: headers. Then:

# 1. Reverse: does the IP have a PTR?
$ dig +short -x 203.0.113.10
mail-a1.acme.com.

# 2. Forward: does that hostname resolve back to the same IP?
$ dig +short mail-a1.acme.com A
203.0.113.10

If the answers match, FCrDNS closes and you're done. The two failure modes look like this:

# Failure 1: no PTR at all — exactly what 550 5.7.25 complains about
$ dig +short -x 203.0.113.10
                       # empty answer / NXDOMAIN

# Failure 2: PTR exists, but the round trip doesn't close
$ dig +short -x 203.0.113.10
mail.acme.com.
$ dig +short mail.acme.com A
198.51.100.7           # different IP -> FCrDNS fails -> treated as no PTR

If you send over IPv6, repeat both checks with the IPv6 address (dig -x accepts it directly) and an AAAA lookup — the v6 path needs its own PTR, and a correct v4 record earns no partial credit. To confirm the HELO banner matches the PTR hostname:

openssl s_client -connect mail-a1.acme.com:25 -starttls smtp 2>/dev/null | head

One thing no domain-based tool can do is run this check for you from the domain alone. WarmEnvelopes' domain checker verifies the records that do live in your domain's DNS — SPF, DKIM, DMARC, MX — and is deliberately honest about the boundary: a PTR belongs to the sending IP, not the domain, so it can only be verified against the IP your mail actually leaves from.

How to fix it: it depends on who owns the IP

Reverse DNS delegation follows IP ownership, not domain ownership. Whoever holds the IP block holds the reverse zone, so the fix is different for every setup:

Your setup	Who controls the PTR	What you do
Shared ESP IP pool (Resend, Postmark, SendGrid shared, Mailgun shared)	The ESP	Nothing — reputable ESPs maintain correct FCrDNS on their pools. Verify once, then stop worrying
Dedicated IP at an ESP	The ESP, on request	Ask them to point the PTR at a hostname on your domain (e.g. mail.acme.com), and publish the matching A record yourself
Own MTA on a VPS or cloud VM	Your hosting provider	Set the PTR in the provider's control panel — it is almost never set correctly by default
Own IP allocation (RIPE/ARIN)	You	You run the in-addr.arpa / ip6.arpa zone yourself: full control, full responsibility

If you send through an ESP's shared pool, this article is reassurance rather than a task list. The ESP owns the IPs, so FCrDNS is their job, and at any reputable provider it's done. This is also the division of labour WarmEnvelopes is built on: warmup mail goes out through your own Resend account, so the IP-level reverse DNS is Resend's responsibility — your job is the domain-level records.

If you have a dedicated IP at an ESP, note that the fix is a two-party operation. The ESP writes the PTR into their reverse zone; you publish the forward A record on your domain so the round trip closes. Forget the forward half and FCrDNS still fails.

If you self-host, you're in the population that the December 2025 enforcement hit hardest — senders who set up SPF, DKIM and DMARC correctly and never touched reverse DNS, because nothing in that setup flow mentions it. Three classic failure shapes:

1. No PTR at all. Most VPS control panels have a reverse-DNS field that starts empty or must be requested. Fill it in with your mail hostname.
2. The provider's generic default. A PTR like static.10.113.0.203.clients.example-cloud.com may technically round-trip, but it identifies an anonymous cloud VM rather than a mail server, won't match the HELO banner your MTA presents, and advertises exactly the cloud-range anonymity that receivers like Microsoft already distrust. Replace it with a real hostname on your own domain, with a matching A record and matching HELO.
3. Silent breakage after an infrastructure change. A provider renumbering, an IP reassignment, or a migration can orphan a previously correct PTR. Nothing alerts you; the rejections just start.

While you're in there: if you cannot guarantee full IPv6 FCrDNS plus authentication, disable IPv6 on your MTA and send over IPv4 only. A correct IPv4-only sender beats a broken dual-stack one every time.

Finally, monitor it. Spam Resource's diagnosis of why tens of millions of messages bounced is that DNS gets treated as a one-time setup task — configured once, checked never. Re-run the two dig commands after any infrastructure change, and put a quarterly reminder on the calendar.

One adjacent note, since DNS audits tend to surface it: MTA-STS and TLS-RPT records are sometimes recommended in the same breath as PTR. They are worthwhile but unrelated — optional controls that enforce TLS on your inbound mail, not an outbound identity check — and they do not substitute for a valid PTR in any way.

Rejected vs. spam-foldered: know which problem you have

550 5.7.25 is a rejection at the SMTP door — the message never reaches a spam folder, and your ESP will report it as bounced, not delivered. That makes it a fundamentally different problem from poor inbox placement, and a more tractable one: the check is evaluated against live DNS on each connection, so once the corrected records have propagated, the rejections should stop — there is no reputation sentence to serve for the misconfiguration itself.

If your mail is being accepted but landing in the spam folder, PTR is not your primary suspect — that's a reputation or content problem, and the diagnostic path is different; start with why are my emails going to spam. And if you're building out a sending domain properly, reverse DNS is one line item in a longer stack of authentication, list hygiene and gradual volume — the full picture is in how to improve email deliverability.

The ordering matters more than most guides admit: no amount of domain warmup compensates for an IP that fails FCrDNS, because the mail is refused before any reputation signal is even consulted. Fix the infrastructure first. Then build the reputation.