This article explains the concept of rDNS (reverse DNS).
Normal DNS queries determine the unknown IP address for a known host name. This is required, for example, for a browser to establish a TCP connection to the correct server when you enter an address into the URL line.
forum.hetzner.de ---> 18.104.22.168
Reverse DNS works in a completely different way; the host name belonging to an IP address is determined.
22.214.171.124 ---> dedi33.your-server.de
As you can see, the host names for forward and reverse lookups do not need to match!
- Trace routes show IP addresses and intelligible host names. This makes it considerably easier to diagnose errors.
- Many mail servers only accept incoming emails if the sender's IP address has a reverse DNS entry.
- Reverse DNS entries can be included in SPF records (Sender Policy Framework — technology for the prevention of spam and virus-containing emails from spoof senders).
The detailed procedure for queries on reverse DNS entries is described in Wikipedia#Reverse DNS Lookup.
This is not possible. Only one host name is assigned to each IP address (except with bizarre PTR round robin tinkering).
Furthermore, it is not important which reverse entries are on the server. The browser only resolves forwards (Name --> IP), and here there can, of course, be several names (e.g. several A records or several CNAME records) which point to an A record.
It is not necessary to have several host names per IP address for operating mail servers. The reverse DNS entry should correspond to the host name of the SMTP server. (Please see the configuration of the respective SMTP server).
If several domains are administrated via an IP address (as is the usual case) a neutral host name can be used which has nothing in common with the customer domains. Spam filters simply check whether the reverse DNS entry matches the HELO host name. This has nothing to do with the domain names or sender addresses from transferred emails.
We recommend the following allocation guidelines:
- The reverse DNS entry should match the host name provided by the mail server while the connection is being created to the corresponding IP address.
- The reverse DNS entry should also resolve "forwards" to the same IP address.
- The reverse DNS entry should not take the form of an automatically generated name, such as
<162-105-133-213-static.hetzner.de>; spam filters might identify these as "spam".
- The domain, which the name derives from, should actually exist. Please do not invent any names.
Example of an unproblematic entry:
srv01.example.com ---> 126.96.36.199 188.8.131.52 --> srv01.example.com
> telnet 184.108.40.206 25 220 srv01.example.com ESMTP ready
Your own name server is only responsible for "forward" resolution.
The owner of the IPexample.com address block, i.e. Hetzner, operates the authoritative name servers for reverse entries.
You can only create reverse DNS entries using the right Robot function. (Look for the menu item
Server -> then click on the server -> and on
IPs -> and click on the text field at right next to the correct
The reverse DNS entry for my server is different from the host name specified in the HELO command of my mail server. Is this a problem?
Example: The reverse DNS entry for the IP address of a server is
<www.example.com>. The mail server on this server logs into the HELO command, but as
Some spam filters grade emails from such senders as "spam", therefore you should avoid this kind of inconsistency. In the above example, the reverse DNS entry and the host name for the mail server could be
<srv01.example.com>. For example,
<www.example.com> could be redirected as a CNAME entry (alias) without any visible effect on
You can perform detailed tests of DNS entries using MXtoolbox.
You can use the Robot-Webservice for this.