Thursday, 17 September 2015

Exchange 2007, 2010, 2013, 2016: Reverse DNS configuration

In order to ensure that your email is not rejected by some recipients, you will need to configure reverse DNS entries (PTR records) for your SMTP servers. Reverse DNS is used to confirm that the SMTP server sending the email is the who it claims to be.

The way this works is when a receiving email server has a new incoming connection from a sending server, it checks the IP. A reverse lookup is done on the IP and according to the results, the email may be marked as spam or delivered.

Background information

According to RFC 7001, below are the possible results of reverse DNS lookups:

Pass: To pass the reverse DNS test, the reverse and forward lookups should both return results and be in agreement. This means that reverse lookup on your IP provides a hostname which then provides the same IP when a forward lookup is done.

Fail: A fail will be returned if the results are not in agreement or where there is no A or PTR record.

TempError: DNS couldn't complete due to a temporary error e.g. a response code of SERVFAIL which means there is a problem with the DNS server.

PermError: No PTR record is available and a repeated lookup will be unlikely to provide different results.

Setup of reverse DNS

To configure reverse DNS for your SMTP servers, go through the steps below:

1) Identify the correct servers to configure reverse DNS for

Exchange 2007 - 2010 servers use hub transport and edge transport servers to send email to external recipients. Exchange 2013 uses either the client access or mailbox server to send the email depending on whether you are using the FrontendProxyEnabled parameter on your send connector. More information is here.

Reverse DNS is not required for internal Exchange 2013 mailbox servers or Exchange 2007-2010 hub transport servers which will not communicate with recipient email servers directly. It's only required on edge transport servers, smart hosts and any hub transport/mailbox servers that will send email directly to the internet.

To work out which, if any, hub transport/mailbox servers will communicate with recipient email servers, first check to see if you are using a smart host by using the below command on a single line:

Get-SendConnector | ? {$_.Enabled -eq $true} |  fl Name,Enabled,SmartHostsString,SourceServers

If all send connectors are using smart hosts then each of these smart hosts needs to have reverse DNS configured. 

If any send connectors are not using smart hosts then make a list of all source servers configured on the send connector and configure reverse DNS for these.

2) Configure the send connector FQDN

By default, the FQDN that is used on a new Send Connector is the FQDN of the server. When a lookup on the public IP of the server is done, this needs to match the FQDN of hte server. If you use a different internal namespace to your external name space e.g. contoso.local internally and externally then this cannot work as you'd need to have a reverse DNS entry for your public IP pointing to svr01.contoso.local which is not possible. 

Configure your send connector FQDN to be a public name which you can configure both forward and reverse DNS lookups for. In this example, we'll use the name 

To configure the FQDN for a send connector, use the below command:

Set-SendConnector -Identity <your send connector name> -Fqdn

For smart hosts, review the documentation available from your vendor to set the FQDN.

3) Configure the reverse DNS records

Once done, create the required public reverse DNS records (PTR records). You need to ensure that the public IP of each of the servers you listed in step 1 has a reverse DNS record that points to the configured FQDN. You'll need to use your DNS provider to do this.

4) Configure forward DNS records (A records)

Some mail servers check that the reverse lookup on your IP provides a hostname which then provides the same IP when a forward lookup is done. In this case, you should also ensure that an A record exists for the FQDN and that one of its IPs is your email server's public IP. Again, you'll need to use your DNS provider to do this.

3) Test your configuration

To test you have configured reverse DNS correctly, send an email from a mailbox in your organization to another email address where you have access to the message headers. I would recommend setting up a test account on each of the main email providers like hotmail, gmail and AOL. AOL is particularly useful as they reject email that fails the reverse DNS test. 

Once you have sent the email, open up the received email and then view the message headers.

You should see the below highlighted section:

Received: from ([]) by with Microsoft SMTPSVC(7.5.7601.23143);
  Wed, 16 Sep 2015 15:19:44 -0700
From: Mark Gossa <>
To: "" <>
Subject: Test message
Thread-Topic: Test message
Thread-Index: AdDwzbfKL2L+k954QZi2AJ9SWoqGZA==
Date: Wed, 16 Sep 2015 22:19:15 +0000
Message-ID: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative;
MIME-Version: 1.0
X-Mailcore-Auth: 10864898
X-Mailcore-Domain: 1251740
X-OriginalArrivalTime: 16 Sep 2015 22:19:44.0609 (UTC) FILETIME=[CA42ED10:01D0F0CD]

This shows that the recipient email server has done a reverse DNS lookup on your IP of and the resulting address is


In this post, we've looked at how reverse DNS is used to determine the sending SMTP server is the server it is reporting to be. In conjunction with SPF records, these two approaches can resolve most issues where email sent from your organization is rejected due to being marked as spam.


  1. Dear Mark,

    i am using smart host to send email in my Company .
    is there require to create reverse DNS if so , where create it


  2. Also i am using in FQDN In Send connector but my External Address is this setting it give me error in server logs but working since 2 years ago.

    1. Hi Mohammed,

      If you manage the smart host then you need to set up reverse DNS for the public IP of the smarthost. If you're using an external cloud based smart host managed by a third party then they will manage reverse DNS. In the case of a smarthost, Exchange doesn't need to have reverse DNS configured unless it has a secondary send connector configured to send email out to the internet directly should the smarthost fail.

      Let me know if you have any further questions.

  3. Hi mark,

    i checked message header in the recipient every thing is fine as mentioned.

    i have small problem i got error in Server log:

    Microsoft Exchange could not find a certificate that contains the domain name in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector outbound connector with a FQDN parameter of If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-Exchange Certificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

    the sending emails is okay , in FQDN i type DNS for hosting company but this Name is not in Certificate please advise


  4. Hi Mohammed,

    If you're sending out email through a smarthost then you need to configure reverse DNS on the smarthost and not the Exchange server. If you're using a smarthost provided by a 3rd party then most likely they would have configured reverse DNS already and you don't need to configure it on Exchange.



  5. DNS Lookup provides a report on DNS records for a specified domain or hostname.
    DNS Lookup