Reverse DNS. The PTR Record Mail Servers Demand

What is reverse DNS?

Forward DNS answers "what IP is mail.example.com?" Reverse DNS answers the opposite: "what hostname is 198.51.100.42?" The answer lives in a PTR record in a special reverse zone (42.100.51.198.in-addr.arpa for IPv4), and crucially, that zone belongs to whoever owns the IP address, your VPS host, cloud provider, or ISP. Your domain registrar and DNS host have nothing to do with it.

When your server connects to a receiving mail server, the receiver immediately looks up the PTR for the connecting IP. Then it does the loop check, forward-confirmed reverse DNS: does the hostname in the PTR resolve back to the same IP? If the PTR is missing, generic, or doesn't confirm, your mail starts the conversation already classified as suspicious, or is refused outright.

Why it matters

• Gmail requires it: Google's sender guidelines mandate a valid PTR that matches the forward lookup. Since the 2024 bulk-sender rules this is enforced with rejections, not just spam-foldering.
• It's the first check in the SMTP conversation: before SPF, before DKIM, before content filtering. Failing it colors everything that follows.
• Generic rDNS is a botnet signature: most spam comes from compromised machines on residential IPs with provider-default PTRs. Receivers pattern-match on this; a default PTR makes your legitimate server look like part of the botnet.

How to check it

# 1. What does the IP's PTR say?
dig +short -x 198.51.100.42
# mail.example.com.

# 2. Does the hostname resolve back to the same IP?
dig +short mail.example.com
# 198.51.100.42  <- must match

Both directions matching is a pass. PTR missing, PTR pointing to a hostname that doesn't exist, or the hostname resolving to a different IP are all failures.

Setting it up, step by step

1. Pick the hostname your mail server identifies as, conventionally mail.example.com, and make sure it matches the HELO/EHLO name in your mail server config (Postfix: myhostname).
2. Create the forward record in your normal DNS: mail.example.com A 198.51.100.42 (and AAAA if you send over IPv6, IPv6 needs its own PTR too).
3. Set the PTR at the IP's owner. This is the step everyone misses. Where to look:
   • Hetzner: Cloud Console → server → Networking → edit Reverse DNS.
   • AWS: for EC2, submit the "request to remove email sending limitations" form which also sets PTR on your Elastic IP.
   • DigitalOcean: PTR is set automatically from the droplet's name, so name the droplet mail.example.com.
   • Google Cloud / Azure: a PTR option on the reserved static IP.
   • Colo / business ISP: a support ticket, or delegation of the reverse zone to your nameservers if you have a whole block.
4. Verify the loop with the two dig commands above, from outside your network.

Common mistakes

1. Leaving the provider default (static.42.clients.hosting.example). Technically a PTR exists, but it screams "nobody configured this machine to send mail."
2. PTR set, forward record forgotten. The loop check fails; you get most of the penalty of having no PTR at all.
3. HELO name disagreeing with the PTR. Receivers compare the SMTP greeting hostname against rDNS. Make all three, HELO, PTR, forward record, agree.
4. Losing the PTR on infrastructure moves. New server, new IP, fresh default PTR. Reverse DNS isn't in your zone file, so it's never in your DNS migration checklist, until deliverability craters a week later.
5. Worrying about rDNS for IPs that don't send. Your web server's IP doesn't need a mail-style PTR. Only IPs that open outbound SMTP connections matter here.

Monitoring rDNS going forward

PTR records sit in someone else's infrastructure, which means they can change without any action on your part: provider migrations, IP reassignments, a support ticket processed wrong. And because nothing in your DNS changed, no DNS-watching tool notices.

DomainsDoc resolves your MX hosts to their IPs and verifies forward-confirmed reverse DNS on every scan, alerting you when a PTR disappears, goes generic, or stops matching, alongside MX, blacklist, SPF, DKIM, and DMARC checks that fail for the same underlying reasons. Add your domain to start; see the pricing page for plans.