Sorted out authentications? Check. Built a domain reputation? Check. Avoided spam filters at all costs? Check. The list of things for improving deliverability goes on and on. Let’s add one more thing to the list then because PTR records can make a difference too. What are they about? How do you add them properly? Let’s see!
What are PTR Records?
PTR records (short for Pointer Records), also known as reverse DNS records, are used to perform a Reverse DNS lookup.
As you probably know, DNS (Domain Name System) is sort of a phonebook for the Internet. It stores an enormous amount of information about millions of registered domains. To access its (virtual) pages, you must perform a DNS lookup of a given domain.
This is typically done by browsers right after you type in an email address. With a DNS lookup, they can quickly understand that the https://mailtrap.io address actually represents the 188.8.131.52 IP address. This result is called an ‘A Record’.
A PTR Record is obtained in the opposite fashion. By performing a Reverse DNS lookup (rDNS), a server can resolve an IP address to obtain a domain or a hostname.
Why are PTR records important?
An email travels across the servers (MTAs) on the way to the recipient’s email client. Before it’s delivered to an inbox, most email providers enforce one simple test; they run a DNS lookup simultaneously with a Reverse DNS lookup and compare whether the results match.
If they don’t, or a DNS PTR record simply doesn’t exist, an email is likely to be sent to spam or even discarded.
PTR Records are a defense used by email servers against spammers, especially those using fraudulent domain names (let’s say, mailtrop.io).
If the records are configured for mailtrap.io, resolving an IP address with a PTR lookup (Reverse DNS lookup) won’t point to a real domain. This, as a result, will send up a red flag for an MTA and will likely lead to an email being discarded.
That’s why it’s important to have a PTR record added to your domain’s DNS if you use it to send mass emails.
PTR records are also important for marketers and their analytical tools, such as Google Analytics. As a website owner, you can easily see which IP addresses visit your pages.
The numbers themselves would be rather meaningless, but thanks to Reverse DNS lookup, you can see the hostnames or domains of visitors. And this can give you some valuable information.
Let’s now learn how to add a PTR record to a domain’s DNS.
How to configure PTR records in DNS records?
Same as when you add a regular A record, the steps for adding a PTR record also very much depend on your web hosting provider. For some, you should be able to add one in your admin panel.
For others, you might need to reach out to the support team so they can set this up for you. We’ll assume you’re able to add PTR Records yourself.
To do so, you’ll first need to define a Reverse DNS zone. By definition, a zone is a separate portion of a domain namespace in DNS. A zone is directly related to the size of your IP network.
Let’s use one of Mailtrap’s domains, smtp-124-128-171-35.mailtrap.live, as an example. Its IP (184.108.40.206) uses a traditional IPv4 protocol (using an X.X.X.X structure), so there are 255 IP addresses available – 220.127.116.11, 18.104.22.168 and so on until 22.214.171.124.
If we need an address for the entire zone, we omit the last digit and reverse the order of numbers. The address of our PTR record would be 128.171.35.in-addr.arpa. If we were to create a PTR record for only one address, we would use 126.96.36.199.in-addr.arpa.
What’s up with in-addr.arpa in each address? It’s a second-level domain suffix that’s added to all the addresses in IPv4 as PTR records are stored in .arpa top-level domain. If you used a more common IP in the IPv6 system, a PTR Record’s address would end with ip6.arpa.
Add a PTR record following these rules. Then, check if there’s a match. smtp-124-128-171-35.mailtrap.live should point to 188.8.131.52 (A record) while 184.108.40.206.in-addr.arpa should point to smtp-124-128-171-35.mailtrap.live (PTR record).
If this is the case for your domain’s DNS, you can say you’ve reached a Forward-confirmed reverse DNS (FCrDNS).
A PTR record should look like this:
Can I have multiple PTR records?
By definition, a PTR record can only point to one hostname. But what if you want to have multiple PTR records for a single IP address? This could work when you have several domains registered, each pointing to the same IP address (and displaying the same website when entering an address).
To get the PTR records right, you’ll want to resolve this IP address for each of these domains – otherwise, you won’t have a match.
DNS doesn’t restrict the number of entries you can have, but having multiple PTR records is not recommended. Software running mail servers often expects only one entry for each IP address. When it retrieves it, it starts treating it as a canonical name for a given hostname.
As a result, if multiple PTR records are defined for a single IP address, during a Reverse DNS lookup, a server may just pick one at random. And that one might not necessarily match the A record.
When adding MX records to DNS, you can specify their priority. No such feature is available for PTR records.
As a result, adding multiple PTR records for an individual IP doesn’t make you look any more credible in the virtual eyes of ISPs. Quite the opposite; in fact, it might result in a failed verification of A/PTR records and lower the chances of your email getting delivered.
How to check if PTR records are set up properly?
To check if PTR records are set up properly, you have two main options:
- query the domain name servers from your computer;
- use online tools that check PTR records immediately.
Let’s start with the first and more time-consuming option. To check PTR records manually, you can use dig and nslookup commands from Windows, Linux, or macOS.
Both dig and nslookup work the same way with these operating systems. To illustrate how these commands would query DNS servers step-by-step, we’ll use the Mailtrap domain we mentioned above, smtp-124-128-171-35.mailtrap.live (IP: 220.127.116.11) which has PTR records set up, and Example.com (IP: 18.104.22.168) which doesn’t.
The first step is to open the command prompt from the operating system.
On Windows, press start → type in command prompt → press open.
On Linux, open the dash → type in terminal → press open.
On macOS, press command + space → type in terminal → press open.
Once you’re done, you can proceed with the commands.
How to check PTR records with the dig command?
dig PTR 22.214.171.124.in-addr.arpa and press enter. Here, you should enter the PTR record you set up according to the rules we discussed above. You’ll see all the PTR records below the ‘ANSWER SECTION’.
Jane@Janes-MacBook-Pro ~ % dig PTR 126.96.36.199.in-addr.arpa ; <<>> DiG 9.10.6 <<>> PTR 188.8.131.52.in-addr.arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16425 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;184.108.40.206.in-addr.arpa. IN PTR ;; ANSWER SECTION: 220.127.116.11.in-addr.arpa. 300 IN PTR smtp-124-128-171-35.mailtrap.live. ;; Query time: 79 msec ;; SERVER: 192.0.2.0#24(192.0.2.0) ;; WHEN: Thu Dec 01 14:21:02 2022 ;; MSG SIZE rcvd: 103
If you were to type in the PTR record that doesn’t exist (as with example.com), the ‘ANSWER’ would indicate 0, and the ‘AUTHORITY SECTION’ would show only SOA records (which contain the zone’s administrative data).
Jane@Janes-MacBook-Pro ~ % dig PTR 18.104.22.168.in-addr.arpa ; <<>> DiG 9.10.6 <<>> PTR 22.214.171.124.in-addr.arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19834 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;126.96.36.199.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 216.184.93.in-addr.arpa. 292 IN SOA ns1.edgecastcdn.net. noc.edgecast.com. 1589310095 3600 600 604800 600 ;; Query time: 72 msec ;; SERVER: 192.0.2.0#24(192.0.2.0) ;; WHEN: Thu Dec 01 14:28:01 2022 ;; MSG SIZE rcvd: 126
dig -x 188.8.131.52 and press enter. The results will be the same as with the previous command.
Jane@Janes-MacBook-Pro ~ % dig -x 184.108.40.206 ; <<>> DiG 9.10.6 <<>> -x 220.127.116.11 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19899 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;18.104.22.168.in-addr.arpa. IN PTR ;; ANSWER SECTION: 22.214.171.124.in-addr.arpa. 300 IN PTR smtp-124-128-171-35.mailtrap.live. ;; Query time: 91 msec ;; SERVER: 192.0.2.0#24(192.0.2.0) ;; WHEN: Thu Dec 01 14:30:35 2022 ;; MSG SIZE rcvd: 103
How to check PTR records with the nslookup command?
nslookup -debug 126.96.36.199. The PTR record will be indicated under ‘ANSWERS’ and ‘Non-authoritative answer’ sections.
Jane@Janes-MacBook-Pro ~ % nslookup -debug 188.8.131.52 Server: 192.0.2.0 Address: 192.0.2.0#24 ------------ QUESTIONS: 184.108.40.206.in-addr.arpa, type = PTR, class = IN ANSWERS: -> 220.127.116.11.in-addr.arpa name = smtp-124-128-171-35.mailtrap.live. ttl = 173 AUTHORITY RECORDS: ADDITIONAL RECORDS: ------------ Non-authoritative answer: 18.104.22.168.in-addr.arpa name = smtp-124-128-171-35.mailtrap.live. Authoritative answers can be found from:
If the PTR records weren’t configured, the ‘ANSWER’ field would be empty and there would be a remark “** server can’t find 22.214.171.124.in-addr.arpa: NXDOMAIN” right at the end.
Jane@Janes-MacBook-Pro ~ % nslookup -debug 126.96.36.199 Server: 192.0.2.0 Address: 192.0.2.0#24 ------------ QUESTIONS: 188.8.131.52.in-addr.arpa, type = PTR, class = IN ANSWERS: AUTHORITY RECORDS: -> 216.184.93.in-addr.arpa origin = ns1.edgecastcdn.net mail addr = noc.edgecast.com serial = 1589310095 refresh = 3600 retry = 600 expire = 604800 minimum = 600 ttl = 600 ADDITIONAL RECORDS: ------------ ** server can't find 184.108.40.206.in-addr.arpa: NXDOMAIN
nslookup -type=PTR 220.127.116.11 or
nslookup -type=PTR 18.104.22.168.in-addr.arpa and you’ll see PTR records right away. The results will be the same with both commands.
Jane@Janes-MacBook-Pro ~ % nslookup -type=PTR 22.214.171.124 Server: 192.0.2.0 Address: 192.0.2.0#24 Non-authoritative answer: 126.96.36.199.in-addr.arpa name = smtp-124-128-171-35.mailtrap.live. Authoritative answers can be found from:
If the PTR records weren’t set up, you’d see the remark “** server can’t find 188.8.131.52.in-addr.arpa: NXDOMAIN”
Jane@Janes-MacBook-Pro ~ % nslookup -type=PTR 184.108.40.206 Server: 192.0.2.0 Address: 192.0.2.0#24 ** server can't find 220.127.116.11.in-addr.arpa: NXDOMAIN
Other ways of checking PTR records
Alternatively, you can check PTR records with online tools such as MxToolbox, NsLookup, whatsmydns, and others. To do so, you just need to type in your domain address or your IP and press enter. You’ll see the results immediately.
With MxTookbox, you’ll have to conduct a reverse lookup to find data about PTR, while NsLookup has a dedicated PTR record search. Whatsmydns is slightly advanced as it allows you to choose which DNS server you want to query.
How to test email deliverability after configuring PTR records?
Configuring PTR records doesn’t necessarily mean that your emails will be delivered to the recipient’s inboxes. Sure, it’s a good ‘anti-spam’ measure, but it’s not the only one. To make sure your emails aren’t getting lost in spam folders, it’s important to test deliverability.
Traditionally, QAs would create loads of dummy emails and send test messages to see whether the emails would get delivered to the inboxes. This method is already outdated as it contains the risk of spamming users.
Today, most developers and QAs rely on safe testing tools, such as Mailtrap Email Sandbox which is a platform that can trap testing emails and check the most important deliverability aspects: spam score and blacklists.
The Email Sandbox provides a detailed spam report that contains the overall spam score along with the main test points. Each point is further explained to clarify where the problem may be.
Email Sandbox also checks your IP address against most common blacklists such as PSBL, Barracuda, Lashback, Spamcop, etc. This way, you can see which resources blacklisted your IP and quickly take the steps for unlisting.