If you administer a mail server, do you know if your reverse PTR (‘pointer’, aka Reverse DNS) record is set up correctly?  If you don’t know, then probably not.  It’s not one of those things that happens ‘automagically’ when you run through the Exchange 2000/2003/2007, Sendmail or <insert name of any other mail-handling software> installation process.

One way you can tell if your reverse PTR is NOT set up correctly is if you regularly have delayed our bounced email when sending messages to aol.com, rr.com, or hotmail.com.  Those are some of the higher profile domains which do reverse lookups on connecting mail servers.  And they are not very forgiving.  If your PTR record is not set up correctly, they and others will delay or reject messages from your mail server IP address.

So, let me give a quick overview of how the reverse lookup process works in the context of sending an email, and what you can do to make sure your PTR exists and is correct.

When you send an email:

  1. Your mail client submits a message to the server; if it is for a non-local address, your server puts it in the outbound SMTP queue.  Let’s say your email address, the source, is aaron@source.com it’s going to john@destination.com.   For the purpose of this post, I’ll assume you are not using a smarthost.
  2. Your server performs a DNS query to find the MX records for destination.com.  It gets a response like ‘mail.destination.com’
  3. Your server resolves the MX record mail.destination.com to its IP address, which we will say is
  4. The SMTP service on your server then makes a connection to on TCP port 25.  For our example, the WAN IP address of your mail server will be
  5. SMTP then ‘introduces itself’ (using EHLO or HELO) and provides the receiving server with its name.  THIS is something that was probably configured during the installation of your mail server, and is typically mail.source.com or something similar.  So, at this point, the receiving mail server, mail.destination.com, sees an incoming SMTP connection from a server at claiming to be mail.source.com.  How does the server at mail.destination.com know that the sending mail server is really who it says it is?  That is where the reverse lookup comes into play.
  6. The receiving server at mail.destination.com takes the connecting IP address,, and does a reverse lookup on it.  A reverse lookup is a DNS query that is looking for a specific type of record, called a PTR.  It is called a reverse PTR because, during the DNS query process, an IP address is resolved to a name.
  7. The reverse DNS lookup on results in a response that is (hopefully) “mail.source.com”.  Notice that the response matches what the sending server said that it was in the introduction in step 5.  This is ideal.
  8. Next, the destination server takes that response and does a regular forward lookup on it.  So it just finds the ‘A’ record for mail.source.com.  That query should return an IP address that matches the source IP, in our case
  9. At this point, the reverse lookup process is complete.  The receiving mail server is satisfied that the sending server is who it says it is and allows the connection to proceed.  The destination server may actually allow the sending server to specify the source and destination email addresses before performing the reverse lookup; this depends on how the server was set up by the administrator.

Now, how can you make sure reverse lookups done on your mail server IP address go as smoothly as outlined above?

Gather the following information:

  • Find out how your mail server is introducing itself when it is connecting to other mail servers.  This is a setting in the SMTP server properties (‘Send Connector’ in Exchange 2007) and is likely going to be ‘mail.yourdomainname.com’ or something like that.  Again, it was probably set when Exchange (or other mail-handling software) was installed.  More technically, this is the name being given along with the EHLO or HELO command when your server connects to another mail server.
  • Look up the current IP address associated with the name you found in the item above.  If you looked on your Exchange server send connector and found that it was set to use mail.source.com, just ping that address and see what IP address you get.  Depending on how your internal DNS is set up on your network, you may get an internal address when doing this.  You need to know the external IP address that is given in response to a query for the name, so you may have to do this step from a computer outside your network.
  • Find out the WAN IP address that your mail server is using to send email.  One fairly reliable way to do this is just to get on your mail server and go to www.whatismyip.com.  Another way would be to look at the NAT rules on your firewall to see what address traffic from your mail server is being translated to on the outside.
  • Look up the current reverse PTR record for your mail server IP address.  A couple of websites that I use for that are MXtoolbox and ZoneEdit.  Often, the result you get here will be the default for your ISP, and may look like this:  cpe-71-123-67-229.hot.res.rr.com.  That is bad.

Armed with this information, you can now determine whether you are in good shape, or if you need to take action.

Verify everything is Ok or fix the problem:

  1. Does the WAN IP of your mail server already have a valid reverse PTR record that matches your domain?  Or, does it look like my example, cpe-71-123-67-229.hot.res.rr.com.  Typically, the most difficult thing to get changed is the reverse PTR record.  These are usually controlled and created/changed by your ISP (Time Warner Cable, AT&T, Comcast, etc.).  There are different ways to request that a reverse PTR be set or changed depending on the provider.  It can be as simple as sending an email to reverserequest@twccs.com (for Time Warner), to having to sacrifice your first-born child (for AT&T).  Just kidding, although for some reason, AT&T has made it exceptionally difficult in the past to get a reverse PTR set up.  I’ve had to go so far as to have AT&T host the DNS records for my domain in order to have them host a simple reverse PTR record for me.  Bottom line, go to your provider and ask for the process to create or change a reverse PTR record, and go from there.  All administrative overhead aside, the technical information they will need to set it up will be the WAN IP address of your mail server and what you want the record response to be.  In our example case, we would have provided them with as the WAN IP and told them that we wanted the reverse PTR for that IP to be “mail.source.com” (without the quotes).
  2. When you ping your EHLO address, mail.source.com, does the IP that is resolved match the WAN IP address of your mail server?  If not, you can fix this in a couple of ways.  Either change the ‘A’ record for mail.source.com to be the IP address of your mail server, or change the WAN IP address of your mail server.  Obviously, you should be careful when changing DNS records or IP addresses.  Make sure you get someone else in your IT group involved for a sanity check so you can make sure you are not going to be causing some other problem trying to fix this one!
  3. Is your SMTP server EHLO address set to a valid external DNS name?  In our example, I used mail.source.com.  However, I have seen mail servers configured to use ‘sbserver.domainname.local’, which is not a valid DNS name on the Internet.  In this case, you will have to set your EHLO address to something similar to the example; something that likely matches your domain name.

That’s it!  If you went through all this and your reverse PTR was already in good shape, great!  If not, then I hope that this helped you to find your way.  It was painful for me when I learned this, because I did it the hard way.  Thanks for reading.

Posted via email from Aaron Johnstone

7 Replies to “Reverse PTR Troubleshooting”

  1. This is a great writeup of how important the PTR record is for your mail server. We will be happy to RT this article to our followers so that they can benefit from this topic as well.

    Also we wanted to thank you for recommending our site to look up PTR records, we are always happy to see our tools being used! If you have any ideas for new tools that would help you on our site, please let us know!


    1. Thanks! I hope it is helpful to someone else. mxtoolbox has been among the 2 or 3 places I rely on for checking DNS-related issues for several years now, so I’m glad to recommend you to others.

    1. what browser are you using? Internet explorer mobile? Safari on an iPhone? the only mobile browser i have tried this site on is Safari on iPhone and it renders normally.

Leave a Reply

Your email address will not be published. Required fields are marked *