InboxRatio
Check your domain

Glossary term

PTR records: reverse DNS for senders who want to be trusted

What a PTR record is

A PTR (pointer) record is the reverse of ordinary DNS: instead of turning a hostname into an IP address, it turns an IP address into a hostname. Look up mail.yourdomain.com and an A record answers 192.0.2.10; look up 192.0.2.10 in reverse and the PTR record answers mail.yourdomain.com.

Reverse lookups work through a special DNS tree. The IP is reversed octet-by-octet and suffixed with in-addr.arpa (or ip6.arpa for IPv6), so the PTR record for 192.0.2.10 actually lives at:

10.2.0.192.in-addr.arpa.  3600  IN  PTR  mail.yourdomain.com.

The detail that shapes everything else about PTR records: they live in the IP address's DNS zone, not your domain's. Whoever controls the IP block — your hosting provider, your ESP, your ISP — controls the reverse zone. You cannot set a PTR record from your domain's DNS panel, ever. You either set it through the IP owner's control panel or you ask them, and if they say no, that IP cannot carry your reverse DNS identity.

For mail infrastructure, the PTR record is effectively the IP's name tag. Receiving servers look it up on every connection, and what they find — a matching mail hostname, a generic data-center label, or nothing — feeds directly into how much they trust the session.

How a PTR record differs from an A record

The two are mirror images, and the mirror is not automatic.

An A record lives in your domain's zone and maps name → address. A PTR record lives in the IP owner's reverse zone and maps address → name. Creating one does nothing to create the other; they are maintained by potentially different parties in different zones, which is exactly why they drift apart.

Mail receivers exploit the pairing as an identity check called forward-confirmed reverse DNS (FCrDNS): take the connecting IP, look up its PTR to get a hostname, then look up that hostname's A record and confirm it points back to the original IP. Passing the round trip proves that whoever controls the IP and whoever controls the domain agree about the machine's identity — a bar that spam-emitting botnet nodes on residential connections structurally cannot clear.

A PTR without a matching forward record fails FCrDNS and is nearly as suspicious as no PTR at all. When you set one, always verify the loop closes in both directions — a reverse DNS check shows the PTR and whether the forward confirmation holds.

How a PTR record works

When your mail server connects to a receiver, the sequence on the receiving side typically runs:

  1. Note the connecting IP address.
  2. Query the reverse tree for its PTR record.
  3. Resolve the returned hostname forward and compare (FCrDNS).
  4. Compare the hostname against what the client claims in its SMTP EHLO greeting, and against the sending domain.
  5. Feed all of it into the connection's trust scoring — in the strictest configurations, reject the session outright on a missing or generic PTR before a single message byte is transferred.

Getting a correct PTR in place means working with whoever owns the IP:

  • On your own server or VPS: the hosting provider's panel usually has a reverse DNS field per IP. Set it to your mail hostname (mail.yourdomain.com), and make sure that hostname's A record points back at the IP.
  • On a dedicated IP from an ESP: the platform sets the PTR, and the good ones let you customize it to your domain. Ask before buying — a dedicated IP wearing the platform's generic reverse DNS delivers less of what you paid for.
  • On shared pools: the PTR is the platform's, full stop, and its reputation rides on the platform's hostname. Nothing for you to configure, but worth knowing whose name your mail travels under.

One IP should carry one PTR record. Multiple PTRs for a single address are technically representable in DNS and a reliable source of erratic behavior, since receivers pick one unpredictably.

PTR records and your deliverability

For anyone running their own sending infrastructure, the PTR record sits at the front door of every delivery. Google Postmaster guidelines state the requirement about as plainly as the deliverability world ever gets: sending IPs must have valid reverse DNS that passes forward confirmation. Mail from IPs without it faces rejection or heavy filtering at Gmail, and other major receivers apply similar policies with varying strictness.

Beyond mere presence, receivers read the shape of the hostname. A PTR like mail.yourdomain.com says "deliberately configured mail server". One like ec2-192-0-2-10.compute-1.amazonaws.com or 192-0-2-10.dynamic.isp.example says "nobody configured this machine for mail" — and generic, dynamic-looking reverse DNS patterns are themselves a filtering signal, since fleets of compromised machines carry exactly those names. Same IP, same mail, different placement, purely on the label.

The PTR also plays a quiet role in how your traffic aggregates in reputation systems. Receivers and blocklist operators group traffic by reverse-DNS naming patterns, so infrastructure that identifies itself consistently builds coherent history in a way anonymous addresses do not.

If you send only through a hosted platform, all of this is the platform's homework — done, competently or not, on your behalf. It becomes yours the day you point any system that sends mail (an app server, a monitoring box, a self-hosted anything) directly at the internet.

Limitations and failure modes

The cloud-default PTR. The most common failure by volume: an application sends mail directly from a cloud instance whose reverse DNS is the provider's auto-generated hostname. Much of it bounces or lands in spam, and the logs dutifully record the rejections nobody reads. Either set proper FCrDNS (where the provider allows it — many restrict port 25 and reverse DNS on purpose) or relay through a service whose infrastructure identity is already in order.

The unclosable loop. PTR set to mail.yourdomain.com, but the forward A record was never created, points at a load balancer, or points at a different IP in the cluster. FCrDNS fails while the PTR looks fine in isolation. Check both directions after every infrastructure change.

You don't control the zone. On many ISP connections and some cloud plans, reverse DNS is simply not customizable. No workaround exists at the DNS level; mail from such addresses needs to route through a relay with a proper identity.

EHLO mismatch. The hostname your server announces in its SMTP greeting should match its reverse DNS. Servers cloned from images often greet with a leftover internal name (localhost.localdomain being the classic), undermining an otherwise correct PTR.

Stale after renumbering. Infrastructure moves, the new IP gets an A record, and the old PTR — in a zone owned by the previous provider — lingers or the new IP's reverse entry never gets set. Reverse DNS belongs on the migration checklist next to the MX records.

A good PTR is a floor, not a credential. Spam operations that rent clean IP space configure FCrDNS too. Passing reverse DNS checks removes a reason to reject you; it earns no positive trust on its own.

Related terms

Dedicated IP, IP reputation, SMTP, MX record, sender reputation, SPF record, domain reputation.

Frequently asked questions

How do I check the PTR record for my IP? Run the IP through the reverse DNS checker, which resolves the PTR and verifies the forward confirmation. From a terminal, dig -x 192.0.2.10 returns the raw record.

How do I set a PTR record for my domain? You don't — that is the trap in the question. PTR records belong to the IP, and only the IP's owner can set them. Find the reverse DNS setting in your hosting provider's panel, or open a ticket with whoever allocated the address.

What is forward-confirmed reverse DNS? The two-way check receivers run: IP → PTR → hostname → A record → back to the same IP. Both directions must agree. A PTR whose hostname does not resolve back to the IP fails the check.

Is a PTR record required to send email? Effectively yes, for direct sending. Google's sender documentation requires valid reverse DNS, and other large receivers filter or refuse connections without it. If you send only through an ESP, the platform's infrastructure carries the requirement for you.

What should my PTR record actually say? A real hostname under your sending domain — mail.yourdomain.com, out1.yourdomain.com — with a matching A record. Avoid anything that looks auto-generated or contains the bare IP octets.

Can one IP have multiple PTR records? DNS permits it; mail operations punish it. Receivers pick one unpredictably, so verification becomes a coin flip. One IP, one PTR, one matching forward record.

If any system you run sends mail straight to the internet, spend the two minutes: resolve its IP with the reverse DNS checker and make sure the loop closes on your own domain's name.

Sources