PTR record: reverse DNS and its role in mail delivery

PTR record (Pointer record) is a DNS record in the reverse zone that maps an IP address to a hostname. A regular A-record resolves names to IPs. PTR goes the other way: given an IP, it returns a hostname. This lookup is called reverse DNS lookup, or rDNS.

Why PTR matters for email

When your mail server connects to a recipient's server, the recipient sees your IP. The receiving server queries the PTR record for that IP. No PTR, or a PTR pointing somewhere unrelated to your sending domain, looks suspicious.

Gmail, Yahoo, Mail.ru, and Outlook.com all reject or quietly spam-folder mail from servers with no PTR. This check runs before SPF, DKIM, and DMARC — it is one of the first things a receiving server does.

How the reverse DNS zone works

PTR records live in a dedicated reverse zone, not your regular domain zone. For IPv4 that zone is in-addr.arpa. The IP address is written with its octets reversed:

IPv6 uses the ip6.arpa zone, with each nibble of the address reversed individually. The record ends up longer, but the mechanics are the same.

Who controls PTR records

PTR records are set by whoever owns the IP address, not the domain owner. That is usually your hosting provider or data center. Hetzner, DigitalOcean, AWS, and OVH all expose a "Reverse DNS" or "rDNS" field in the server control panel where you enter the hostname for your IP.

If you rent a VPS to send mail, setting the PTR is the first thing to do after installing your MTA. Even a perfectly configured SPF and DKIM setup will not save you from rejections if the PTR is missing.

Forward-confirmed reverse DNS (FCrDNS)

Some mail systems run a double check: first rDNS (IP to hostname), then a forward DNS lookup (hostname back to IP). When both results agree, that is called FCrDNS (forward-confirmed reverse DNS) and it increases trust in the sender.

Example: IP 198.51.100.25 has PTR mail.example.com. The A-record for mail.example.com returns 198.51.100.25. The loop is closed, FCrDNS passes.

If the PTR points to mail.example.com but the A-record resolves to a different IP, the check fails. This happens when a server moves and the A-record is updated but the PTR at the hosting provider is not.

PTR rules for mail servers

• PTR must exist. A missing PTR is the most common reason new servers get rejected outright.
• The hostname should be meaningful. A PTR like "198-51-100-25.provider.net" looks like a dynamic IP and raises flags. Use something like mail.example.com or smtp.example.com.
• Avoid generic patterns in the name. Strings like "static", "client", "dhcp", or "dsl" in a PTR signal a residential connection. Mail providers filter those IPs.
• FCrDNS should pass. The PTR and A-record must point to each other.

PTR and email validation

When a validator checks an email address it inspects the DNS infrastructure of the recipient domain, including MX records and their IPs. The recipient's PTR does not affect validation directly, but your own server's PTR matters if you are sending SMTP requests to verify addresses.

Many mail servers check the PTR of a connecting client before processing the RCPT TO command. No PTR means the server may close the connection with a 550 or 421 error, and the address never gets verified.