Exchange Send Connector EHLO and DNS data, rDNS, PTR, MX, SPF, TXT, ‘A’ record!
Posted by shauncroucher on March 12, 2010
Exchange 2007 / 2010 DNS Data
Purpose of this article
Throughout the online technical support community it is so common to find administrators struggling to figure out what DNS records need to be configured to allow reliable inbound and outbound SMTP services. This article has been written to clear up a few myths that I’ve heard and to clarify what is required, and what is not.
My Top 5 Myths
1) DNS changes take 24-48hrs to update\propagate around the internet.
This is such a common myth it has to make my number 1 spot. The truth is that DNS records don’t propagate in the true sense of the word, there is no automatic process that pushes these records anywhere. The myth originates from the ‘caching’ mechanism which is used within the DNS framework. A brand new DNS record (of any type) should be available as soon as the change is made to the domain zone (usually the hosting company do this or you have a web portal to make changes and there may be a delay here with actually processing your request – check with your hosting provider). Once this change is made, it will be live everywhere. Now, there may be a delay if you change the details of a record such as adding a MX record or changing the ‘A’ record associated with a MX record, the delay will be as long as the TTL (time to live) value for that record and this is usually 1-3hrs. There are some exceptions where your ISP may cache the results for longer than the TTL on your records but this is quite rare nowadays and the vast majority of DNS changes will be seen within 4 hours to be honest. You can check with your hosting company (or go to http://my-addr.com/domain-hostname-dns-records/isp-country-geo-ip-location/online-nslookup-tool/domain_info.php) and type your domain to see the TTL in seconds for your DNS records.
2) Your MX record needs to match your reverse DNS (aka PTR) record
This is just not true. The pointer record (PTR) can also be known as the reverse DNS (rDNS) record and it does not need to match your MX records at all, it is really as simple as that. Imagine a company that use a third party hygiene service like messagelabs (where they have changed the MX records to the messagelabs servers), they may still use their own servers to send mail, and they wouldn’t want to change their PTR to match messagelabs as this would go against general DNS principles entirely (see RFC 1912).
3) The IP you send mail out with also needs to allow inbound port 25 access
I can only think that this myth originated from the anti-spam technique of checking if the domain name specified in the MAIL FROM (the sender domain) field have any infrastructure to support inbound mail. This test will not check to see if the connecting IP allows inbound SMTP, it will use the domain name to do a DNS lookup of the MX records to see if they exist, and sometimes will also try to connect to the MX to see if it accepts connections. The idea behind this method is to give weight to the domain name belonging to a legitimate sender. It is not as commonly used as other methods of anti-spam but the point here is that the sending IP does not need to accept inbound SMTP at all. The important thing is to make sure you have valid MX records in place that accept mail for your domain.
4) You need to setup SPF for your domain for reliable mail delivery
If you do not want to use SPF records for your domain (which are used to tell other servers the locations you permit mail from your domain to originate from), it will have no negative consequence for mail delivery. In other words, you don’t need a SPF record for reliable mail delivery. However, the presence of a SPF record may help add weight to the mail being legitimate and can help others when they decide if your email is a SPAM message or not.
5) You need to setup a PTR record for your domain for reliable mail delivery
PTR (or rDNS) records are setup for a IP address. The in-addr.arpa namespace is to allow you to query for an IP address and the answer you receive is a PTR record. It is not possible to setup a PTR record for a domain because a domain is not an IP address.
Inbound Mail (The MX record) requirements
Assuming you do not use a hygience server and wish to setup your mail servers so that mail from the outside world is delivered directly to your servers, you need to make sure you have MX records publishing for your domain name. The MX record needs to be setup with the hosting company who look after your public DNS records (those for your public domain name such as example.com).
The fastest and easiest way to find out what your MX records are is to use the command prompt and a DNS query tool of your choice, such as nslookup or DIG. I will use nslookup in this example as we are talking about Exchange and nslookup ships as part of the Microsoft operating system.
Open command prompt and type the following (replacing example.com with your domain):
nslookup -q=mx example.com
now, you should receive a response which looks similar to this:
nslookup -q=mx example.com.
Address: <YOUR DNS SERVER IP OR NAME>
example.com MX preference = 10, mail exchanger = mail.example.com
example.com nameserver = ns1.example.com
example.com nameserver = ns2.example.com
(you may not be provided with the nameserver details, but should definitely have the MX record result as above).
Note the preference there, it should be a positive number above O (a priority of O can cause issues with some sending servers)
Now you should check that the mail exchanger (mail.example.com) points to your external IP address, you can do this by simply pinging the name from the command prompt and seeing what IP is resolves to. Now assuming you have port 25 open and directed to the mail server you are good to go.
Outbound Mail Requirements
There is a lot more to consider with DNS when you are sending outbound mail, and if you don’t check this, you may find yourself with outbound mail delivery problems.
The Reverse DNS (or PTR) record
It is true that the IP address you use to send outbound mail MUST have a reverse DNS record and this reverse DNS record should refer to the primary domain name you use to send mail (its fine if you use multiple domain names when sending mail). To check if you have a rDNS record in place, you first need to find out what your outbound mail IP is. The most reliable way of doing this is to take a look at the headers of an outbound email. You should see in the headers where the email leaves your company and gets accepted by the receiving end. You should note the IP address that is used.
Once you have the IP address, it is very easy to check the rDNS, simply run a ping from the command prompt with the -a switch.
ping -a 126.96.36.199
Make sure you use your public IP address here, and not the internal IP.
You will need to speak with the people who have been delegated the DNS responsibility for your IP address’s PTR record and this will in most cases be your ISP.
You should also make sure that you have a matching ‘A’ (aka hostname or subdomain) record in your domain DNS zone (contact your domain hosting company) that matches the PTR record you have created. This allows for a forward-confirmed rDNS (where the PTR for an IP has a corresponding ‘A’ record configured in the domain zone that also points to the IP).
The HELO\EHLO hostname
Not strictly DNS data, but certainly related.
When a Mail Transfer Agent (MTA) such as Microsoft Exchange starts a SMTP conversation with another MTA, it will use a ‘HELO\EHLO’ hostname as a greeting. Some MTA’s will check this hostname to see if it matches the rDNS entry. If they do not match, the mail may be rejected. For this reason it is important that the Send Connector is using the correct FQDN to send mail. You can clarify what this is by using the Get-SendConnector as below:
Get-SendConnector | ft Id*,fq*
This will show you the FQDN used and the Identity of each connector.
You can use the Set-Sendconnector to set this to the public rDNS.
Set-SendConnector <Identityname> -Fqdn <rdns.example.com>
It’s as simple as that. (you can use the Exchange Management Console if you prefer, Org config –> Hub –> Send connectors)
Sender Policy Framework (SPF)
As I mentioned in my list of common myths, SPF is not a requirement for reliable mail delivery and is totally optional. SPF can be a little confusing for the uninitiated. There are two parts to SPF, firstly you can configure your own mail server to ‘check’ SPF data when receiving mail to see if the sender has permitted the sending server to send mail as that domain. Secondly, there is setting up SPF data for your domain name so that others can check that mail they receive is coming from a source you specify as ‘permitted to send as your domain name’
I will be talking about the creation of SPF records in your domain’s DNS zone. As with the ‘A’ record you configured to match the rDNS, you will need to appoach the people who manage your domains DNS records to get a SPF record set up. Every DNS record has a ‘type’ such as ‘A’, ‘PTR’, ‘MX’. The type that is used for SPF is ‘TXT’. TXT records can be used for other purposes as well, but are the type that SPF is designed to check for. There is a plethora of ways that you can configure your SPF record to identify which servers are permitted to send mail for your domain, the easiest ways are by providing IP addresses, or if you use the same server to send and receive mail, you can just specify the ‘MX’ record.
To specify a list of IP addresses that are allowed to send mail using your domain:
“v=spf1 ip4:188.8.131.52 ip4:184.108.40.206 ~all”
To specify the server that is referenced in your MX record as the only server permitted to send you can use:
“v=spf1 mx ~all”
You might be wondering what the ~ is before all, and this just means “treat this list as authorised, but if you see mail coming from somewhere else, it MIGHT still be legitimate, but you should mark it as suspicious”. You can use a hyphen ‘-’ which means “If it isn’t on the list, you should reject it outright”, but I wouldn’t recommend this as there are still issues with SPF such as when mail is forwarded from another server and you will find using a HARDFAIL such as ‘-’ will cause legitimate mail being refused.
There is a handy tool you can use to help you create the SPF record – see : http://old.openspf.org/wizard.html and answer the questions to assist you with the record creation. You will then need to apply this to your zone file with the help from your domain hosting solution provider.
http://tools.ietf.org/html/rfc5321 - SMTP Request for Comments publication
http://www.faqs.org/rfcs/rfc1912.html - RFC1912 – Common DNS Operational and Configuration Errors
http://www.ietf.org/rfc/rfc4408.txt - RFC 4408 – Sender Policy Framework