Exchange 2007 Mail Flow (DNS Records, Connectors, and TLS)

A lot of people are confused as to how exactly you should configure DNS for Exchange 2007.  But this isn’t just limited to DNS, but how do you set up your Send Connectors, Receive Connectors, how both connectors relate to DNS and the SMTP banner, and how to allow your Connectors to advertise TLS to the outside world.

That’s what the purpose of this article is for.  What FQDN should we assign to our connectors, what FQDN to add to our certificate to allow us to advertise StartTLS to the outside world to provide an increased chance that SMTP communications will be encrypted, and how to set up our DNS to ensure that our SMTP has a better chance to be accepted by the Receiving Server.

DNS A (HOST) Record

The first thing we want to do is configure an A record for our MX record to point to.  The MX record is a type of record which specifies that for a specific domain, you should contact a specific A record to send mail to.   Another name for an A record is a HOST record. When utilizing Windows DNS, the MX record will point to an A record.  For purposes of this lab, I will be showing you how to all DNS records via Windows DNS.  The first thing we will want to configure is an A record.  We will name this smtp.shudnow.net.  This A record will be pointing to the Public IP Address of the service that is accepting your mail.

Now why did I say mail service instead of mail server?  Well, there are services out there such as Exchange Hosted Services or Postini that will accept mail for your domain.  This is not your mail server.  Instead, your A record points to these hosted services which provide message hygiene services that then send appropriate messages directly to your Mail Server.

There are a couple benefits of utilizing these hosted mail hygiene services.  These include:

• These services handle PTR records
• They contain a team of spam experts to ensure services are at an optimal state
• Datacenter redundancy
• Always up to date antivirus definitions
• They take care of the spam/antivirus which in return reduces the amount of viruses and spam that hits your network which can significantly reduce the amount of bandwidth coming into your environment

In our shudnow.net zone, let’s go ahead and create an A record for smtp.shudnow.net that points to 10.20.30.40.  This IP Address will be the Public IP Address that points to our Exchange Server.

Note: This is not any real IP address that I own.

You can create this A record by Right-Clicking our zone and choosing New Host (A) record.

We’ll enter the smtp name and set the IP address to 10.20.30.40.

We should successfully see our A record in our list of DNS entries.

DNS MX Record

Now that we have an A record, we will want to create an MX record to point to our A record.  An MX record is essentially a record that other mail servers will look for to see what server accepts mail for the domain the sending server is trying to send to.  So for instance, if someone sends a mail to [email protected], the sending server will look for the MX record of shudnow.net.  The MX record will show up as smtp.shudnow.net because the MX record points to the A record of smtp.shudnow.net.  The sending server will now do an IP address lookup of smtp.shudnow.net and obtain the IP Address and then establish a connection over port 25 to our receiving server.

In our shudnow.net zone, let’s go ahead and create an MX record.

You can create this MX record by Right-Clicking our zone and choosing Mail Exchanger (MX) record.

We will configure our MX record as such.  The reason we leave the top text field blank is because we are accepting mail for shudnow.net and we’re creating the MX record directly in shudnow.net.  If we were creating this MX record in the shudnow.net zone but were accepting mail for a child such as child.shudnow.net, we’d put in the word “child” in this text field.

We should succefully see our MX record in our list of DNS entries.

You can now see, doing an NSlookup query for the MX record of shudnow.net will successfully show the result as smtp.shudnow.net which points to 10.20.30.40.  And for those that are curious, we get the, “Can’t find server name for address…” because I don’t have a reverse lookup zone configured.

DNS PTR Record(s) and SMTP Banner(s) (Send/Receive Connector FQDNs)

A PTR record isn’t “always” necessary but there are some domains out there that will block you if you do not have a PTR record configured.  Take a look here.  According to Microsoft, the following domains will block you if you do not have a proper PTR record configured: AOL.com, Qwest.net, Mindspring, Earthlink, and Hotmail.  Sometimes the receiving domain will even block you if the PTR does not match the SMTP banner.  This is very rare though.  Now, some of you may be thinking, what is the SMTP banner?

When you telnet to your server over port 25, it will reply with “mail server communication speech.”  In the case of Exchange 2007, there are Receive Connectors and Send Connectors.  Because we made a connection to our mail server, our Exchange 2007 Server answered via the Receive Connector.

You will never want to modify the Default Receive Connector away from any of the following three names or you’ll have routing issues:

• Blank
• NetBIOS
• Server FQDN

Instead, to modify the FQDN of the Receive Connector as I have, you must create a new Receive Connector with the Intended Use of Internet.  You can find the Receive Connectors in Server Configuration > Hub Transport > Receive Connector. This Connector will allow Anonymous Connections (not Relaying) while your Default Receive Connector will be utilized for internal routing.

Now you may want your Sending server to utilize the same smtp.shudnow.net name for sending.  In this case, we can create a Send Connector with our smtp.shudnow.net name.  You can find Send Connectors in Organization Configuration > Hub Transport > Send Connectors.  You won’t see any Send Connectors here by default since all Send Connectors to other Hub Transport Servers are hidden and are known as IntraOrg Connectors.

So let’s say our Sending Server is the same as our Receiving Server.  We can go ahead and create our PTR record so that 10.20.30.40 points to smtp.shudnow.net.  That way when we send to another server, that receiving server will see the communication coming from smtp.shudnow.net.  The receiving server will also see the communication coming from 10.20.30.40.  It “may” do a Reverse DNS lookup (checking PTR record) for 10.20.30.40.  It will see the smtp.shudnow.net name and pass the test.

Now here’s one thing to take into consideration. The majority of receiving servers out there just want there to be a PTR record point to a valid A record and it’s happy.  It’s seldom where a mail server will require the PTR record to match the SMTP banner.  But it’s still a good practice to have them match up if you can.

StartTLS

All Exchange 2007 by default is encrypted using TLS.  By default, Exchange 2007 utilizes self-signed certificates to utilize TLS.  I’m sure you guys/gals have heard this quite a bit.  But you may be wondering… how?  Well, I’ll tell you how.  There’s something called X-AnonymousTLS and StartTLS.  X-AnonymousTLS is utilized between Hub Transport Servers and between Edge Transport Servers and Hub Transport Servers (authentication only).  StartTLS is used for SMTP Clients, Domain Security, and when talking with Internet Mail Servers.

I won’t go into X-Anonymous much other than the fact the process of using a specific certificate is a bit different than what happens when advertising StartTLS.  You can check out this article to see the process.

For StartTLS, part of the process for selecting the certificate is by taking a look at what the Receive Connector FQDN is.  By default, it’s set at the FQDN of the server.  For example, in my lab my Hub Transport Server is SHUD-EXC1.  Because of this, the Receive Connector is set to SHUD-EXC1.shudnow.net.  During the certificate selection process, it will look for a certificate that contains the SHUD-EXC1.shudnow.net.

Now let’s not forget that you may have different Receive Connectors.  For example, if you have an Internet Only Receive Connector, SMTP communication with that connector will utilize a certificate that contains the FQDN set on that connector.

Now you may be thinking, how is Exchange 2007 secure by default if the StartTLS process looks for a certificate that matches the connector name?  Well, if no certificate is found, it’ll still revert to using a self signed certificate to offer StartTLS.  So, this is exactly how Exchange 2007 utilizes StartTLS by default.  So if you do want it to use an FQDN to advertise StartTLS, when you get a certificate from a third party vendor, include the name you want your SMTP banner set at.  Either way, your server should still offer StartTLS.

DNS Sender Policy Framework (SPF)

SenderID is an anti-spam technology that Exchange has on by default.  I won’t go into too much detail on how SenderID works and can be configured as Brian Tirch over at Exchange Genie does a great job at explaining it in addition to other Exchange Anti-Spam options.  You can check out his article here.  In short, SenderID will check for an SPF record from the receiving domain.  An SPF record will contain a list of servers that are allowed to send from a specific domain.

Many organizations do not set up SPF and because of that, SenderID is less restrictive when it retrieves an e-mail.  My domain @shudnow.net does have an SPF record set up for my mail servers.  Because of that, if you were to try to load up a server and send mail as @shudnow.net, that would be a huge red flag since I do have an SPF set up and your mail server is not on my SPF record.

Our current examples so far have used the example IP of 10.20.30.40.  So let’s set up an SPF record for this IP.  To help you out with the process, you can follow this web driven wizard here.

Let’s begin with Step #1 (duh!).  Enter your domain that you are setting up the Policy Framework for.  For this example, I will use “thisisatestdomain.com.”  The reason I am using this domain instead of shudnow.net, because as I said, I already have an SPF.  This wizard will detect that and not allow me to create a new one, but rather edit existing servers.

Since it didn’t find an SPF, it prompted us to let us know “No SPF Record Found”  and let’s us continue.

The next page has various options that you should go through and configure as you see fit.  One of the options I am configuring is Outbound Mail Server Addresses.

Once we have done this, we will obtain the information to put in our TXT file which we will publish in DNS.

So now going back to our InternetDNS server, we will go to our thisisatestdomain.com domain and publish our SPF record.  Most of the time, you’ll have a Service Provider that hosts external DNS.  If this is the case, all you need to do is submit a request to them to create an SPF and include a list of your sending servers.

You can create this TXT record by Right-Clicking our zone and choosing TEXT (TXT) record.

Choose TEXT (TXT)

We’ll need to put in the SPF Text information retrieved from the wizard.

We now have our SPF (TXT) Record created which helps people prevent spoofing your domain name in the future.