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 172.67.5.169 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.
Important Note: In 2024, Google and Yahoo are making DNS email authentication #1 requirement for bulk senders.
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 (35.171.128.124) uses a traditional IPv4 protocol (using an X.X.X.X structure), so there are 255 IP addresses available – 35.171.128.1, 35.171.128.2 and so on until 35.171.128.255.
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 124.128.171.35.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 35.171.128.124 (A record) while 124.128.171.35.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:
| Host | Type | Points to: | TTL |
| 124.128.171.35.in-addr.arpa | PTR | smtp-124-128-171-35.mailtrap.live | 5 min |
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: 35.171.128.124) which has PTR records set up, and Example.com (IP: 93.184.216.34) 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?
1. Type dig PTR 124.128.171.35.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 124.128.171.35.in-addr.arpa
; <<>> DiG 9.10.6 <<>> PTR 124.128.171.35.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:
;124.128.171.35.in-addr.arpa. IN PTR
;; ANSWER SECTION:
124.128.171.35.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: 103If 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 34.216.184.93.in-addr.arpa
; <<>> DiG 9.10.6 <<>> PTR 34.216.184.93.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:
;34.216.184.93.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: 1262. Type dig -x 35.171.128.124 and press enter. The results will be the same as with the previous command.
Jane@Janes-MacBook-Pro ~ % dig -x 35.171.128.124
; <<>> DiG 9.10.6 <<>> -x 35.171.128.124
;; 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:
;124.128.171.35.in-addr.arpa. IN PTR
;; ANSWER SECTION:
124.128.171.35.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: 103How to check PTR records with the nslookup command?
1. Type nslookup -debug 35.171.128.124. The PTR record will be indicated under ‘ANSWERS’ and ‘Non-authoritative answer’ sections.
Jane@Janes-MacBook-Pro ~ % nslookup -debug 35.171.128.124
Server: 192.0.2.0
Address: 192.0.2.0#24
------------
QUESTIONS:
124.128.171.35.in-addr.arpa, type = PTR, class = IN
ANSWERS:
-> 124.128.171.35.in-addr.arpa
name = smtp-124-128-171-35.mailtrap.live.
ttl = 173
AUTHORITY RECORDS:
ADDITIONAL RECORDS:
------------
Non-authoritative answer:
124.128.171.35.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 34.216.184.93.in-addr.arpa: NXDOMAIN” right at the end.
Jane@Janes-MacBook-Pro ~ % nslookup -debug 93.184.216.24
Server: 192.0.2.0
Address: 192.0.2.0#24
------------
QUESTIONS:
24.216.184.93.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 24.216.184.93.in-addr.arpa: NXDOMAIN2. Type nslookup -type=PTR 35.171.128.124 or nslookup -type=PTR 124.128.171.35.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 35.171.128.124
Server: 192.0.2.0
Address: 192.0.2.0#24
Non-authoritative answer:
124.128.171.35.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 34.216.184.93.in-addr.arpa: NXDOMAIN”
Jane@Janes-MacBook-Pro ~ % nslookup -type=PTR 93.184.216.34
Server: 192.0.2.0
Address: 192.0.2.0#24
** server can't find 34.216.184.93.in-addr.arpa: NXDOMAINOther 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 Testing, a safe environment to inspect and debug emails with no risks of spamming users with testing emails.
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.
