Configuring Reverse DNS for Exchange
Having issues sending e-mail to aol.com, hotmail.com, other
ISPs and some companies? If so there is a good chance that a
reverse DNS or a PTR record
does not exist for the Exchange server, or other server, that is sending your e-mail
to the Internet. About a few months ago I noticed that messages to aol.com
were just sitting in the queue. After the timeout period I would get a NDR
messages for these e-mails. It turns out that the IP address that is actually
transmitting the e-mail, in my case a firewall, didn't have a valid PTR record
in my ISPs DNS server.
Let me start by going over how messages are transmitted and how
DNS actually work, in relation to e-mail. In most environments a firewall is
between the sending mail server and the Internet. In such a case, the sending
mail server might have an IP address of 10.10.10.20 but the external address of
the firewall is 206.10.10.10. When a message is sent out from the mail server
it is transmitted though the firewall and the firewall actually establishes the
connection with the destination server(s). If the destination server is
configured to do a reverse DNS lookup it will query the DNS server responsible
for the 206.10.10.13 IP address. If this IP address is the property of your
ISP, which is normally the case for most organizations, they will have a DNS
server that has generic or no reverse lookup (PTR) entries for their IP
addresses. If entries do exist they will normally be something like
host-206-10-10-13.adslcustomers.qwest.net.
In most cases multiple DNS servers are actually involved in
the transmission of e-mails. But there are two key ones that provide
authoritative information on the host\domain names and IP addresses of mail
servers. One is responsible for responding to the reverse lookup quires by IP,
used by the receiving mail server. The other one responds to forward lookups
by host or domain name, used by the sending mail server. When someone sends
e-mail to a domain name, company.com for example, the sending mail server
queries its DNS server for the IP addresses of the MX record for company.com. In most cases, this DNS server will not know about company.com and will need to
forward the request to a DNS server that knows about company.com. Normally
this request for information will be sent to the DNS servers hosting the
root zone for the
Internet, in this case ".com". The responding root DNS server will then provide
the requesting DNS server with the IP address of the DNS server responsible for
company.com. The requesting DNS server will then query that IP address for the MX records for company.com. The responding DNS server at company.com will then
return the IP addresses for the SMTP server, firewall, or device that handles
incoming e-mail for company.com. The sending mail server will then attempt to
transmit the message to the MX record entry with the lowest priority. A single
DNS server could be used to handle both forward and reverse DNS queries, if the
ARIN and domain registration information
is configured correctly, discussed in more detail later.
Given the example above, one or more DNS servers are host
records related to the 206.10.10.13 IP address. These DNS servers should have
mail (MX), host (A), and pointer (PTR) records. When a message is sent from
company.com to hotmail.com the receiving server at hotmail.com will do a
reverse lookup on the sending IP address, 206.10.10.13. This query is handled
by the DNS server that handles lookups for the 206.10.10.x, or a larger, IP
block. It should then return the PTR record for 206.10.10.13, which should be
something like mail.company.com. For more information see
How Reverse DNS Works. Some
receiving mail servers, like hotmail's, and/or spam filtering solutions request
this reverse lookup on the sending servers IP address, which is the only thing
in a message that can't be spoofed by a spammer. If a PTR record doesn't exist
for the sending IP address the messages maybe blocked or flagged as spam. In
addition, if the PTR record doesn't match the sending servers FQDN,
mail.company.com for example, the message may also be blocked or flagged as
spam.
Therefore, you need to make sure that the FQDN used by the
sending mail server matches the PTR record for the IP address that actually
transmits the messages to the Internet. If you do not own your IP addresses or
don't have control over your reverse lookup zone for your IPs you will need to contact
your ISP. I know Qwest.net, my ISP, allows their customers with static IP
addresses to create PTR records in their DNS servers or to forward reverse
lookups to another DNS server that their customer controls. The DNS server
that handles domain queries can also be hosted by your ISP, the
registrar for
your domain name, by yourself, or elsewhere. To find out the DNS server that
is handling queries for your domain check your registration information for
your domain name at your domain registrar, a minimum of two DNS servers are
required by most registrars. To check the reasonable party for your IPs goto:
http://ws.arin.net/whois. Chances are that
your IP address will be owned by a "super ISP" who then leases it to another
ISP, who probably then leases it to yet another one. For example, my IP
addresses shows as being owned by Beyond The Network America, Inc, who controls
63.216.0.0 63.223.255.25. But I know Qwest.net actually controls the reverse
DNS servers for my IP addresses. So Qwest either leases the IP blocks they use
from Beyond or another ISP that then leases them from Beyond.
The steps below will cover configuring Exchange to use the
correct domain and FQDN values and the configuration of DNS. These settings
will all help prevent e-mail being sent by your servers from being blocked or
flagged as spam. By default Exchange will use the AD domain name that the
server exists in. So if your AD domain name is company.local, Exchange will
use <server name>.company.local for the FQDN in all outgoing messages. This FQDN is put in the header of all messages and is set to the receiving mail
server, so it is essential that it is configured correctly.
Message
header example:
In the above example "mail.altered.com" is the FQDN sending
mail server. 63.227.36.13 is the IP address of the sending server. All
information in an e-mail header and message can be faked except the IP
addresses. This is why all almost all spam filtering procedures do some level
of checking on the IP addresses.
Configuring Exchange to use the correct domain and host name
The first step in making sure your Exchange server is
configured correctly is to check the fully-qualified domain name setting on the
SMTP protocol.
- Open
Exchange System Manager and navigate to <Org>\<Administrative
Group>\Servers\<Outgoing Exchange server>\Protocols\SMTP
- Right
click on "Default SMTP Virtual Server" and choose properties
- Click on
the Delivery tab
- Click the Advanced
button
- Enter in
your primary SMTP domain name in the "Masquerade" domain field and the
FQDN for the server
If you do not set the masquerading domain name, Exchange will use
the AD domain name for server. "altered.local" and pinky.altered.local for the
FQDN for example. Both of these are invalid on the Internet and would trigger
most spam filtering software.
The FQDN should match the PTR record created in the DNS server
the responses to reverse name lookups for the IP address that actually sends
the mail to the Internet.
The "Perform reverse DNS lookup on incoming messages" is an
optional setting that is used by some spam filtering software. This setting
only affects the handling of incoming messages.
- Click OK
twice
