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 contoso.com 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 mail.contoso.com.
To configure the FQDN for a send connector, use the below command:
Set-SendConnector -Identity <your send connector name> -Fqdn mail.contoso.com
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 mail.contoso.com 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 mail.contoso.com ([10.11.12.13]) by SNT004-MC4F54.hotmail.com with Microsoft SMTPSVC(7.5.7601.23143);
Wed, 16 Sep 2015 15:19:44 -0700
From: Mark Gossa <mark@domain.co.uk>
To: "testaccount5@hotmail.co.uk" <testaccount5@hotmail.co.uk>
Subject: Test message
Thread-Topic: Test message
Thread-Index: AdDwzbfKL2L+k954QZi2AJ9SWoqGZA==
Date: Wed, 16 Sep 2015 22:19:15 +0000
Message-ID: <10FD0B967AE6B84F8DE916DA4FE260AAEE2A1A72@svr01.gossa.co.uk>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [1.2.3.4]
Content-Type: multipart/alternative;
boundary="_000_10FD0B967AE6B84F8DE916DA4FE260AAEE2A1A72svr01gossacouk_"
MIME-Version: 1.0
X-Mailcore-Auth: 10864898
X-Mailcore-Domain: 1251740
Return-Path: mark@domain.co.uk
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 10.11.12.13 and the resulting address is mail.contoso.com.
Conclusion
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.