PTR Records and Reverse DNS: Why Mail Servers Need Them

A PTR record maps an IP address back to a hostname, which is the exact reverse of the A and AAAA records you set every day. Where an A record answers "what is the address for mail.example.com," a PTR record answers "what name belongs to 203.0.113.25." This reverse lookup is the backbone of email reputation: mailbox providers such as Gmail, Yahoo, and Microsoft check it before they accept your mail, and a missing or mismatched PTR is one of the fastest ways to land in spam or get rejected outright.

Reverse DNS lives in two special zones. IPv4 lookups happen under in-addr.arpa and IPv6 lookups happen under ip6.arpa. The trick that confuses people is that the address is written backward inside those zones, because DNS reads names from most specific on the left to least specific on the right, while IP addresses are written the other way around.

How a reverse lookup name is built

For an IPv4 address, you reverse the four octets and append in-addr.arpa. The address 203.0.113.25 becomes the query name 25.113.0.203.in-addr.arpa, and the PTR record there holds the hostname.

$ dig -x 203.0.113.25 +short
mail.example.com.

$ dig 25.113.0.203.in-addr.arpa PTR +short
mail.example.com.

The -x flag is a convenience that builds the reversed name for you. Both commands above are identical queries. For IPv6 the same idea applies but at the nibble level: expand the address fully, drop the colons, reverse all 32 hex digits, put a dot between each, and append ip6.arpa.

$ dig -x 2001:db8::25 +short
mail.example.com.

# the query name dig builds looks like:
# 5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

Who controls reverse DNS

This is the single biggest surprise for newcomers. You do not set a PTR record in your own domain's zone. The in-addr.arpa and ip6.arpa zones are delegated down from the regional internet registries to whoever owns the IP block, which is almost always your hosting provider, cloud platform, or ISP, not you.

• On a VPS or dedicated server, you usually set the PTR in the provider control panel, often labeled "reverse DNS" or "rDNS" on the IP or instance.
• On AWS, Google Cloud, or Azure, reverse DNS for sending IPs is set through a provider-specific request or form, sometimes gated behind sending-reputation checks.
• If you own a full block, the registry delegates the reverse zone to your nameservers and you publish the PTR records yourself.
• On shared hosting, you typically cannot change it at all, which is one reason serious senders move off shared IPs.

Forward-confirmed reverse DNS (FCrDNS)

A PTR record on its own is not enough. Mail servers run a two-way check called forward-confirmed reverse DNS, or FCrDNS. The receiving server takes your connecting IP, looks up the PTR to get a hostname, then looks up the A or AAAA record for that hostname and confirms it points back to the same IP. If the loop closes, you pass. If any link is missing or disagrees, you fail.

There is a third piece that ties it together: the hostname in your PTR should match the name your mail server announces in its SMTP HELO or EHLO greeting. When the PTR, the forward A record, and the HELO name all agree, you present a clean, consistent identity that receivers trust.

Why this matters more than ever

FCrDNS used to be a nice-to-have. It is now a hard requirement for bulk senders under the published guidelines from Google, Yahoo, and Microsoft. If you send meaningful volume and your sending IP lacks a matching PTR, your mail can be deferred or rejected before your SPF, DKIM, or DMARC are even evaluated. Reverse DNS is effectively the doorman, and the authentication records are the conversation that follows only if the doorman lets you in.

Reverse DNS also shows up in other places: SSH and server logs that resolve client IPs to names, some rate-limiting and abuse systems, and traceroute output that labels each hop. A clean PTR makes your infrastructure easier to read and easier to trust.

Setting it up correctly

Follow this order so the forward and reverse sides agree from the start.

1. Pick the canonical hostname for the sending IP, for example mail.example.com.
2. Create the forward A record (and AAAA if you send over IPv6) pointing that hostname at the IP.
3. Ask your IP provider to set the PTR for the IP to that same hostname.
4. Configure your mail server so its HELO/EHLO greeting uses the same hostname.
5. Wait for propagation, then verify both directions.

$ dig -x 203.0.113.25 +short
mail.example.com.
$ dig mail.example.com A +short
203.0.113.25

If both commands agree, your FCrDNS is sound. One caution on IPv6: if your server can originate mail over IPv6, it will likely be judged on its IPv6 PTR, so make sure the AAAA and the ip6.arpa PTR exist and match. A common failure is a perfect IPv4 setup paired with a missing IPv6 PTR, which trips receivers that prefer IPv6.

Troubleshooting a failing check

• No PTR returned. The reverse zone has no record for your IP. Contact your IP provider to set it, since you cannot add it in your own zone.
• PTR exists but FCrDNS fails. The hostname in the PTR has no forward record, or the forward record points to a different IP. Align the two.
• Generic PTR. Many providers default to an auto-generated name such as 203-0-113-25.provider.net. It may technically pass FCrDNS, but a branded name that matches your domain reads as far more legitimate to filters.
• Stale answers after a change. Reverse zones have TTLs too, so an edit can take time to appear everywhere.

Confirm it is live everywhere

Because reverse DNS is controlled upstream and cached with its own TTL, a change you request may show instantly in one place and lag in another. After you update a PTR or its matching forward record, check that both directions resolve consistently across the internet with the Valla DNS propagation checker. For the authentication layer that sits on top of a clean PTR, the Valla DNS /learn/ guides on SPF, DKIM rotation, and reading DMARC reports walk through the rest of the deliverability stack.