Reverse DNS for mail servers

Reverse DNS maps an address back to a name, through a PTR record in the in-addr.arpa or ip6.arpa tree. It is published by whoever controls the address block — your hosting provider or ISP — and not in your own zone, which is why it is the DNS record most often missing.

It matters most for *sending*. A large number of receivers refuse or heavily penalise mail from an address with no PTR, or with a PTR that looks automatically generated from the address itself in the way residential and dynamic ranges do. Many also check forward-confirmed reverse DNS: the PTR must give a name, and that name must resolve back to the same address.

This check looks at the hosts named in your MX records, which are the servers that *receive* your mail. Those are frequently the same machines that send it, which is why it is worth reporting — but if your outbound mail leaves by a different route, the addresses that matter for deliverability are that route's, and they are not visible from your MX records.

PTR is set by whoever owns the address block, through your hosting provider's control panel or a support request. You cannot publish it in your own zone.

Make it forward-confirm: set the PTR to a real hostname, and make sure that hostname has an A or AAAA record pointing back to the same address.

Use a name that matches the HELO name the server announces, and that belongs to your domain rather than the provider's generic template. mail.example.com is right; 203-0-113-45.static.example-isp.net is what receivers are penalising.

Do this for IPv6 as well. A server with a working IPv4 PTR and no IPv6 one will deliver perfectly until the day the receiving side prefers AAAA.