Rejected before authentication even runs.

/ TL;DR

/ 01

What reverse DNS is

Forward DNS answers "what IP is this hostname?" — you give it mail.example.com and an A record returns an address like 203.0.113.25. Reverse DNS answers the opposite question: "what hostname is this IP?" You give it the address and it returns the hostname, stored in a PTR record.

The reverse mapping lives in a special corner of DNS: an IPv4 address is written backwards and appended with .in-addr.arpa, so 203.0.113.25 becomes a lookup for 25.113.0.203.in-addr.arpa, whose PTR record names the host; IPv6 uses the parallel .ip6.arpa zone.

For most of the internet this lookup is a background convenience for logging and diagnostics. For email it's sharper: a basic identity check that receiving servers run on every connection, and one legitimate senders pass while much spam infrastructure doesn't bother to. That asymmetry is why reverse DNS carries so much weight in whether your mail is accepted.

/ 02

Who controls the PTR record

This is where most people get stuck, because a PTR record isn't set where every other DNS record is set. Your forward records — A, AAAA, MX, TXT, and the SPF, DKIM, and DMARC entries built on them — live in your domain's zone, controlled by your registrar or DNS host. A PTR record lives somewhere else entirely: in the reverse zone for the IP address, which is controlled by whoever owns that IP block.

For nearly everyone running their own mail, that owner is the hosting provider, VPS provider, cloud platform, or ISP that assigned the address. So you can't simply add a PTR the way you add an SPF record in your DNS panel — you request it from your IP provider. That's a reverse-DNS or IP-management section in their control panel if they offer self-service, or a support ticket if they don't, asking them to point your sending IP at your chosen mail hostname. The major clouds each have their own console flow for it: it's a specific setting in AWS, Azure, and Google Cloud rather than something in your domain's DNS.

If you're unsure who controls an IP, a WHOIS lookup names the organization to contact. The practical takeaway: stop hunting for the PTR setting in your registrar's dashboard — it's never there — and go to the source of your IP. Getting this straight saves the most common wasted hour in reverse-DNS setup.

/ 03

Forward-confirmed reverse DNS

Having a PTR isn't quite enough on its own; what receivers want is forward-confirmed reverse DNS, or FCrDNS, and understanding why explains most of what follows. A plain reverse lookup is one step: IP to hostname. FCrDNS adds a second, confirming step: the receiver takes the hostname your PTR returned and looks up its forward record, checking whether that resolves back to the very same IP it started with.

The second step matters because a one-way PTR proves nothing about control. Anyone can ask their provider to point a PTR at mail.bigbank.com to look legitimate — but they can't also make mail.bigbank.com's A record resolve back to their own IP, because they don't control that domain. The forward confirmation closes that loophole, so a passing FCrDNS check is real evidence that whoever set the PTR also controls the matching hostname.

This is why providers verify FCrDNS rather than merely checking a PTR exists, and why a half-configured setup fails: a PTR whose hostname's A record points elsewhere, or doesn't resolve, is nearly as weak as no PTR. Both directions must agree — so setting up reverse DNS means setting up both halves, the PTR at your provider and a matching A record in your own zone.

/ 04

The three-way HELO match

There's a third element beyond the PTR and the A record: the name your mail server announces when it connects. Every SMTP conversation opens with a HELO or EHLO greeting carrying a hostname — the server introducing itself. Receivers compare that greeting against your reverse DNS; best practice is a three-way match where all of them name the same host:

When those three agree, your server presents one consistent identity, and that consistency is itself a trust signal. When they disagree — the server greets as mail.example.com but the PTR still shows the provider's default vps12345.hosting.com — receivers read the mismatch as poor server hygiene or an attempt at spoofing, and some reject on it outright. This is the error that shows up in deliverability tests as "reverse DNS does not match the SMTP banner."

A common worry is what to do when one IP sends for several domains. You don't need a different greeting per domain: choose one primary mail hostname, make the PTR, the HELO, and that hostname's A record all agree on it, and every domain sending through the IP is fine. The identity being verified is the server's, not each individual sender domain's — the domains authenticate separately through SPF, DKIM, and DMARC, which sit a layer above this one.

/ 05

Layer zero, and the mandate

The reason reverse DNS matters so much is when it's checked. SPF, DKIM, and DMARC operate on the envelope and message, after a connection is established. Reverse DNS is checked earlier, at the moment the connection opens, which makes it effectively layer zero of the authentication stack. If the PTR check fails, the receiver can refuse the connection before your authentication is ever consulted — all that SPF and DKIM work never gets a chance to matter.

And this stopped being merely a reputation nudge and became a hard rule. When Google and Yahoo introduced their bulk-sender requirements — announced in early 2024, enforced from April — a valid PTR with forward confirmation was on the required list for anyone sending large volumes to their users. Microsoft followed for high-volume senders in May 2025, routing non-compliant mail to Junk. Then in late 2025 Gmail escalated from temporary deferrals to permanent 550 rejections for messages from IPs without valid reverse DNS. The dedicated bounce for it is a 550 5.7.25.

So in 2026 a missing or broken PTR isn't a soft risk costing a few points of placement — across the three largest providers, it's a connection-level rejection. That reframes reverse DNS from optional polish into baseline infrastructure, sitting alongside SPF, DKIM, and DMARC rather than beneath them. Our authentication guide covers the layers above; this is the one they all rest on.

/ 06

The generic-PTR trap

Here's the catch that surprises people who think they're covered: having a PTR record isn't the same as having a good one. Hosting providers routinely assign a default reverse-DNS entry to every IP, something like 50-113-0-203.static.provider.net or a variant with "dynamic" in it. That record exists and technically forward-confirms — but it's treated as almost as bad as no PTR at all.

The reason is what that pattern signals. A hostname built from the IP and the provider's domain is the fingerprint of unmanaged or residential address space — the kind of IP botnets and throwaway servers spam from. Receivers pattern-match on it, and many reject generic or dynamic-looking rDNS outright. Your legitimate mail inherits the reputation the default hostname advertises.

The fix is to replace the default with a clean, branded mail hostname — mail.yourdomain.com — and align it with a matching forward record and your HELO greeting, exactly the three-way match from earlier. One honest caveat that saves a lot of effort, though: if you send through an established email service provider rather than your own server, the sending IPs belong to them and they manage clean PTR records for those IPs — reverse DNS is handled, and there's nothing for you to configure. This whole concern applies specifically to running your own mail infrastructure, which is also where a dedicated IP matters, since one IP maps to one PTR and you want that one to be yours.

/ 07

Setting it up and verifying

Putting it together is a short, ordered sequence. First, make sure your mail hostname — say mail.example.com — has a forward A record pointing to your sending IP, in your own DNS. Second, request the PTR from your IP provider, asking them to point that IP at the same hostname. Third, set your mail server's HELO or EHLO greeting and SMTP banner to that hostname, as a fully qualified name, so all three agree. Then verify from the outside before trusting it:

Two traps catch people even after the records look right. The first is IPv6: Gmail often prefers connecting over IPv6, so if you have an IPv4 PTR but no IPv6 one, Gmail may reach an address with no reverse DNS and reject while other providers, using IPv4, accept — check which address a bounce actually names, and set PTRs for both families you send over. The second is mundane: the most common "reverse DNS isn't working" complaint turns out to be a blocked outbound port 25, so confirm it's open before debugging DNS for hours. Also allow time — changes can take hours to a day to propagate.

After setup, treat it as something that can drift: cloud providers occasionally remap or reset records, and a silent FCrDNS break costs deliverability with no obvious cause, so a periodic check earns its place. Our reverse DNS check confirms your PTR resolves and forward-confirms in one step, and the domain health scanner shows it beside your authentication records. When a connection-level rejection like a 550 5.7.25 appears, our bounce codes guide helps you read it. Keeping reverse DNS aligned as your infrastructure changes is part of the standing operation we run.

/ 08 — FAQ