Reverse DNS and PTR records for email

Reverse DNS answers the mirror of the usual question: given an IP address, what hostname does it belong to? For email it is a first-impression check that runs before any content or authentication is examined: the receiving server looks up the connecting IP's PTR record, and what it finds, a meaningful mail hostname, a generic ISP label, or nothing, shapes how the rest of the conversation is treated. Sending IPs without proper reverse DNS get scored down or refused outright, and the fix is one record plus one matching forward entry.

How the check works

1# 1. Reverse: what does the IP claim to be?
2dig -x 198.51.100.42 +short
3# out1.mail.example.com.
4
5# 2. Forward: does that name point back?
6dig A out1.mail.example.com +short
7# 198.51.100.42
8
9# Match in both directions = forward-confirmed (FCrDNS)

The two-step matters because a PTR alone is trivially claimable by whoever controls the address space; the forward confirmation proves the domain owner agrees. Receivers run exactly this pair on every inbound connection, and Gmail's sender guidelines state the requirement plainly: sending IPs must have valid reverse DNS that matches a forward lookup. Beyond passing the check, the hostname itself communicates: out1.mail.example.com announces deliberate mail infrastructure, while a generic label like 198-51-100-42.dynamic.isp.net announces a residential connection, which is the profile of botnet spam and is filtered accordingly.

Who sets it, and how

PTR records live in the address owner's zone, not yours: the hosting provider, cloud platform, or ISP that allocated the IP controls the in-addr.arpa entry. Every serious platform exposes it, as a console field (Hetzner, OVH), an API setting (AWS via request or resource attribute, depending on service), or a support request. The forward half, the A record for the chosen hostname, lives in your own DNS and is yours to publish. Set both when infrastructure is provisioned, and re-verify whenever IPs change, since the PTR does not migrate with your workload.

Practice and pitfalls

Name the host meaningfully under your organizational domain, and let the MTA announce the same name in its HELO/EHLO greeting: PTR, forward record, and HELO agreeing is the coherent identity receivers want, and some run the comparison explicitly. One PTR per sending IP is the norm; multiple PTRs confuse more than they help. The recurring pitfalls: cloud IPs recycled with a previous tenant's PTR still attached, IPv6 sending paths without PTR coverage while receivers hold IPv6 to the stricter standard (Gmail rejects on it), and infrastructure moves where the new IPs simply never got records because the checklist lived in someone's head.