How it works
Regular DNS turns names into addresses; reverse DNS goes the other way. For IPv4 the PTR record lives in the in-addr.arpa zone with the address reversed: 203.0.113.25 becomes 25.113.0.203.in-addr.arpa and points to something like mail.example.com. IPv6 uses the ip6.arpa zone.
The reverse zone belongs to whoever runs the IP network, meaning the hosting or access provider, not the domain owner. You therefore set the PTR record in your host’s control panel or ask the host to do it, not at the domain’s DNS provider.
Receiving mail servers usually check forward-confirmed reverse DNS (FCrDNS): the name in the PTR record must resolve back to the same IP through an A or AAAA record. Ideally it is also the name the server announces in the SMTP greeting (HELO or EHLO).
Why it matters
Without a PTR record, or with one that does not confirm back, many receivers reject the mail or score it as spam. Gmail requires valid forward and reverse DNS for the sending IP from all senders.
Generic names like static-203-0-113-25.provider.example look like a residential or dial-up line to spam filters and cost points as well. After a server or IP move the PTR is often missing because nobody thought to set it at the new host.
How to prevent it
- Have your host set a PTR to a stable hostname such as mail.example.com for every IP that sends mail.
- Create an A or AAAA record for that hostname pointing to exactly that IP so forward-confirmed rDNS passes.
- Configure the mail server to announce the same name in HELO or EHLO.
- Do not forget IPv6: if the server also sends over IPv6, every IPv6 address needs its own PTR.
- Make the PTR a fixed item on the checklist for every server or provider change.
How DomainWarn detects it
The reverse DNS check resolves all MX hosts of the domain and checks, for every IPv4 and IPv6 address, whether a PTR record exists and whether its name resolves back to the address. A missing PTR opens the “Reverse DNS missing” incident after two runs, a name that does not point back opens “Reverse DNS mismatch”; the findings explain that the operator of the IP network sets the PTR. A changed PTR shows up as a change in the timeline.
The check covers the inbound mail servers from the MX records. If the domain sends through other servers, such as the shop’s web server or a newsletter service, the mail test checks the actual sending IP along with its PTR and HELO name.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.