Welcome back to our DNS records management series which highlights Domain Name Systems and how to use them. In the past we’ve covered Strange DNS Issues, then Getting Started with DNS Records and also Understanding MX Records.
Our series continues with this post focused on PTR Records, otherwise known as the Pointer Record, by explaining what it is, what you can be using them for, how to configure them and why you should even bother. At the end, I will point you in the direction of a great tool to use.
Domain Name System’s PTR Records
PTR Records are quite a bit different from most DNS records in several respects. I won’t go into all of them, just the important ones. First of all, PTR Records are not configured by the owner of the domain name and are the only relevant records that this is true for. Secondly, they do not follow the typical resolution chain that most records follow. Finally, they are an extended record, which means that they are not required for normal DNS operations.
Despite all this, they are still extremely important, specifically for email as we will now cover.
What are PTR records used for?
PTR Records are used to answer RDNS, (reverse DNS), queries. When sending email, to prevent spam, many email systems require the email server delivering the mail to pass an RDNS check.
What is the RDNS check doing? It’s taking your IP address from the server sending the mail and attempting to resolve this back to the name of the server. Since many spammers use false addresses and/or IP spoofing, they will not be able to pass an RDNS check and will automatically be refused mail delivery. However, this means that the mail server will only accept mail from a server with a PTR Record that matches the sending mail server, which can block legitimate email as well.
It’s an aggressive policy to be sure, but one implemented by many public mail hosts. Chances are if your emails are not making it to AOL, Comcast, or Road Runner email addresses, but making it almost everywhere else, the problem is you need a PTR Record.
How do I configure a PTR Record?
If you are the usual end user, you don’t. This is configured by who owns the IP address, usually an ISP or hosting provider. You may need to enter a request to have one added to the appropriate party, (owner of your mail server’s IP address). If you are the owner of the IP address, then add the PTR Record to your DNS structure in the following format:
First you must add a record for your IP Range, (a class C address range would be 3 octets), as shown below. Also note that all PTR Records are entered in reverse, (in the example, the address is actually 24.240.192).
Take note to add the .in-addr.arpa as that is the common format. Now you must enter the actual PTR Record for your specific domain as shown below.
Notice that this is the same format as before, only specifies the full IP address, (written backwards), as well as resolves this to the FQDN of your mail server. In the example above, the IP address of our mail server is 220.127.116.11, and mymailhost.mymail.local is the FQDN, (fully qualified domain name), of our mail server.
*If you only own one IP address and not an IP address range or block, then only the last step is truly necessary.
How does this work?
IP addresses are typically tracked in a global database known as ARIN. When ARIN leases a block of IP addresses to a company, (typically an ISP), this is noted in the database and able to be queried back to the ISP. When the ISP leases the IP to a hosting company or end user, they SHOULD enter this into their DNS database showing that you are now the owner of the address, range or block.
When an email is sent to an address whose server requires PTR, the RDNS query is initiated. It reads the IP address of the sending email server and queries this in reverse. The query will first reach out to ARIN, who will direct it to the ISP, who will then direct it to the hosting provider or end user where the PTR Record must exist. This tells the receiving email server that the sending email server is indeed who they say they are, as the owner of the IP is claiming the mail server, and the mail server is claiming that IP.
If this seems a bit abstract or difficult to grasp, it’s because it is so drastically different from how other DNS Records are managed. This means that you can understand how the other DNS Records work completely, but still have no idea how PTR and RDNS works or where the records are managed. It is truly Reverse DNS and aptly named.
This Reverse DNS Lookup tool is the best RDNS Lookup I have found that shows each step and hop of an RDNS Lookup and will help to troubleshoot issues if you indeed have your PTR Record configured and it is not being “picked up” by receiving mail servers. Since it illustrates each hop, where the request dies will be who you will need to contact to address the issue. Unfortunately, this tool does require an email registration, but is worth it if having problems with PTR specifically. Other tools are available for other record types without needing registration, so I would only suggest using this tool for PTR problems specifically.
We have a few more DNS records to address in upcoming blog releases but we’re in the home stretch now. As always, thank you for reading!