Managing SPF and reverse DNS in Exchange Server (Part 1)

If you would like to be notified of when Anderson Patricio releases the next part in this article series please sign up to our MSExchange.org Real Time Article Update newsletter.

Introduction

Exchange Server has been constantly improving itself throughout the years and nowadays the customers can chose between on-premises, cloud or hybrid environments and get the integration working in a matter of minutes using the built-in wizards which make our lives much easier. It does not matter which scenario you have implemented in your company, you still need to work on the SPF and reverse DNS, and in this first article of the series we will focus on the SPF record, starting with a simple introduction and then showing tools to check and configure in your environment.

SPF Records (Sender Policy Framework)…

The SPF (Sender Policy Framework) can be divided in two separate process. The first one is the administrator defining the SPF information on its Public DNS, which are the servers/partners that can send messages on behalf of its domain. The second part is on the side of the SMTP server that receives a message, which should check the SPF record of the receiver to make sure that the message that is being received is from an approved server/service and based on the results an action can be taken, such as receive the e-mail, discard the message or quarantine.

The SPF framework is widely used nowadays and probably you have configured that on your own environment. Microsoft has a wizard to help customers manage their SPF records and on the initial page of the wizard an image explaining how the SPF works (Figure 01).

Image
Figure 01 (This image is courtesy of Microsoft)

If you run the SPF Record Wizard, the third step (Figure 02) will allow the administrator to select which servers/IP, default action and all sort of settings that can be added to a basic SPF configuration, and the result will be an SPF record that can be used on the Public DNS.

Image
Figure 02

Checking SPF…

There are tons of sites to validate DNS records on the Internet, and the author’s preference is to use either the old school nslookup utility or the website mxtoolbox.com.

We are going to select a domain for the testing, in this article we are going to use Canada.ca and using MXToolbox.com we just need to enter spf:Canada.ca and wait for the results (Figure 03). Based on the answer we know that only servers listed as MX records are the ones that can officially send e-mails from that domain.

Note:
The special character before the all string at the end of the SPF information tells us what the receiver SMTP server should do in case a message is received from a server that is not identified on the SPF record. Here is quick reference for each character:

  • -all my favourite, only the servers configured on the SPF are the ones that send messages
  • +all even if the server is not listed, the message may be legitimate
  • ~all that is a soft –all, because this message may be valid however it is discouraged by the domain
  • ?all neutral, there is no statement if the message is legitimate or not

Image
Figure 03

If you prefer the old school nslookup utility, then the first step is to use a Public DNS resolver, and we are going to use the one from Google, which is the easiest to remember. Another good thing of using a Public DNS resolver is to avoid a split-brain DNS zone internally giving you the wrong information. Open nslookup on your workstation/server and enter these following commands.

Server 8.8.8.8

After that, we need to filter the query just for TXT records.

Set type=txt

Then, type the domain name

Canada.ca

Because the previous command provided the SPF and as part of the results was that all MX records for that domain are allowed to send messages, then our next logical step was to check which servers are the MX records. The entire list of commands used are shown in Figure 04.

Set type=mx

Canada.ca

Image
Figure 04

SPF records with multiple sites and/or vendors…

An SPF record is a TXT record and by definition, each string on the DNS should not have more than 255 characters, although we can create more than one string of 255 characters for the same entry, it will be almost impossible to convince your DNS provider and get that implemented. If you are in a situation where the size of the SPF record is getting close to 255 limits, then a solution is to use the include: clause to get around that limitation.

Using the scenario depicted in Figure 05, where we have several sites with an Exchange Server deployed, and this kind of scenario is common where the remote locations have limited bandwidth. It is also common for them to their own Internet links instead of MPLS/VPN to send messages to the Internet.

Besides of the pain of creating a reverse DNS for each one of the sites, the next logical step is to adjust the SPF record to make sure that all servers that send messages are properly defined in the SPF record.

Image
Figure 05

The SPF record is flexible and we could summarize saying that any server that has an entry of type A on the Public DNS is allowed to send a message for example, and the SPF record could be as simple as v=spf1 a –all. In that scenario each site has an A record entry for their local OWA and the previous SPF suggestion would not be a big deal. However, this approach allows any server that has an A entry to send messages as your domain, and that may be a security issue (even though you still have the firewall to block servers of using 25 port which we are going to discuss later on in this series).

Some environments prefer to be more restrictive and allow only the Public IP of the Exchange Servers, and we can do that using the ip4: clause, it would be something like this: v=spf1 ip4:99.99.99.98 –all, and that is easy to deploy when you have a few sites.

The limit of 255 characters will impose a challenge to a larger environments where all Public IPs combined will surpass that limit. An option for this kind of scenario is to use the parameter include:<TXT-Record> and add the IPs on that entry (each new SPF will have the same limit of 255) but that increases your range significantly.

In the scenario above, we could create a TXT record for each continent for our company (in this case we are using msitpro.ca as an example), something like spfEU.msitpro.ca, spfSA.msitpro.ca and spfNA.msitpro.ca and for each one of those entries we would add the SPF information

v=spf1 ip4:xx.xx.xx.xx ip4:yy.yy.yy.yy ip4:ww.ww.ww.ww ip4:zz.zz.zz.zz –all

Then, on the SPF record we would use, include to reference those previous TT record created:

V=spf1 include:spfEU.msitpro.ca include:spfNA.msitpro.ca include:spfSA.msitpro.ca –all

Looking at the forward lookup zone on the DNS, the results will be similar to figure 06.

Image
Figure 06

If we use MXToolbox.com to retrieve the information, the first attempt running txt:domain.ca format will bring just the SPF, and the reason being is that all other TXT entries have a name associated to them (look at the host column on the previous picture). Then, in order to list the information from the other entries, we need to run txt:name.company.ca as shown in Figure 07 (located in the block at the bottom).

Image
Figure 07

Even if you do not have a larger environment the utilization of include: clause could be useful. Some companies ask third-party vendors to send surveys to their employees or customers and all messages sent from that company will have your company’s e-mail address.

To increase the success rate of getting the survey on the end-users mailboxes those third-party companies will ask you to change your SPF record to include their IP address, this way even though they are not sending messages from your mail servers, they want to represent you to the Internet. Using include: parameter we could create beforehand a new TXT record called vendors.company.ca and keep their IP address for the required time.

Conclusion

In this first article, we covered the basics of SPF and how to use some free tools (Microsoft SPF Wizard, nslookup and MXToolbox.com) to validate the SPF configuration. We also checked how to use include: clauses to support environments with several servers.

If you would like to be notified of when Anderson Patricio releases the next part in this article series please sign up to our MSExchange.org Real Time Article Update newsletter.

About The Author

1 thought on “Managing SPF and reverse DNS in Exchange Server (Part 1)”

  1. The SPF (Sender Policy Framework) can be divided in two separate process. The first one is the administrator defining the SPF information on its Public DNS, which are the servers/partners that can send messages on behalf of its domain. The second part is on the side of the SMTP server that receives a message, which should check the SPF record of the >>> receiver <<<< (must be SENDER??? )) to make sure that the message that is being received is from an approved server/service and based on the results an action can be taken, such as receive the e-mail, discard the message or quarantine.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top