Publishing SenderID records for Exchange SP2 IMFv2

First of all, what in the world is SenderID? SenderID is Microsoft's implementation of the SPF (Sender Policy Framework). There, all clear, right? Lets move on.

The cryptic name and acronym basically describe a framework implemented through the DNS system to provide additional authenticity to messages relayed through certain servers. Many SPAM messages you receive are "forged" which is a term describing an email that looks like it was sent by someone else. One of the first instances of forging on the Internet was called a "Joe Job" and involved a spammer that sent thousands of messages to the newsgroup and made it appear as if the messages came from an innocent party, in this case Joe Doll of joes.com. Over the years we have seen a huge increase in "joe jobs" and perhaps even your own domain may have appeared to be sending out spam. I for one have received spam I apparently sent to myself. And no, I don not sleep-walk or sleep-spam, thank you :)

To combat the problem Microsoft and SPF sent a series of proposals to create a standard for defining which hosts are allowed to send email on behalf of certain domains. If your business owns an Exchange mail server and that is the only mail server that relays mail for yourbusiness.com, would it not be great if other servers could just reject messages from other servers that pretend to be you? Well, in order for that to happen there needs to be a standard by which mail servers can differentiate legitimate mail from your server and reject forged mail sent from other locations. The answer to that is SenderID/SPF which despite major objections at IETF (Internet Engineering Task Force, body establishing Internet standards) has become the standard for matching valid senders with valid mail relay servers. Here is an overview of how SenderID works:

Determining your SenderID records

The first step is actually doing the research on how your mail flows. You must be very careful how you define your SenderID records because a typo could effectively eliminate your ability to reach other SenderID users for days.

So how does your email get to the Internet? Start making the list. The first and obvious choice is the IP address of your mail server which most of your users relay their messages through. Are you sending messages through a third-party smarthost, for example your ISP? If so, add that too. Are there any other services, such as your hosted CRM or fulfillment center, that send email using your domain name? Get those and add them as well. The more complex your mail configuration, the more difficult it will be to document all servers but once you do there will be very little others can do to effectively spoof your domain.

Creating a list is the most difficult step of the process and requires a lot of research. However, if you only own one mail server that does not use any other exotic configurations this is a very simple process. For example, my own domain (owncorp.com) sends messages from only one Exchange server: 72.29.99.222. Research done.

SenderID record syntax

Now that you have the list of mail servers you're ready to put together your SenderID record. The record itself is very simple and it looks like this:

Let's break it down. The first part of that line (owncorp.com) is the name of my domain that I am publishing SenderID for. The second part (TXT) is the type of the DNS record, since SenderID records are published through the DNS (Domain Name Server) system. Next comes the actual content of the record between the quotes. First (v=spf1) is the version of the SenderID protocol. Second is the listing of the IP addresses (inbound mail servers, subnets, or nothing at all) that are defined for this record. Finally there is an action (-all) which tells the remote server what to do with the message should it come from severs other than those specified in the record.

Now, lets look at a few examples to just get an idea of how things work.

Notice that in the above example there are no IP addresses, no subnets, no MX records. This record would designate that there should never be any mail coming from owncorp.com. This domain simply does not send mail. Now lets say I wantd to only allow my own inbound mail servers to send mail:

Now in the above example there is only one decleration for the possible source: "mx". What this means is that the messages coming from owncorp.com domain should only be accepted from the mail servers that accept my inbound mail (or in DNS: my MX mail exchangers). Pretty simple and, easy to track. Use the MX if you're offloading your mail onto your ISP who may from time to time change the IP address of their mail servers.

The above example includes two IP addresses that owncorp.com mail can originate from. It is the address of my Exchange server for direct delivery, and my ExchangeDefender smarthost. Pretty simple. But what if I didn't know the address of my smarthost, what if it was a few dozen servers and I only know the range. Do I have to sit there and enter 100 different a:... things into my DNS?

I just saved you a TON of time. Instead of specifying my smarthosts one by one, I declared the entire range by using the ip4 record with a /24 netmask. This way my SenderID will cover every single IP address on that entire Class C of the Internet.

Now I know you're wondering what that (-all) means. Well, its simply a result. It is what the remote mail server should do with the message once it is evaluated against your SMTP record. For example, the -all says that if the message came from anywhere other than the list of servers I provided it should be deleted. There are other options. You can also pass (+all) the message, softfail (~all), be neutral (?all) or do nothing at all. Additional results can also be TempError and PermError but those are a bit beyond the scope of this article.

Publishing your SenderID record

Now that you've created your SenderID record it is time to publish it. SenderID records are TXT records in the DNS system and must be published in your forward lookup zone file (owncorp.com in my case). Find your primary DNS server and open the DNS console by going to Start > All Programs > Administrative Tools > DNS.

When the DNS console opens first find your DNS forward lookup zone. Mine is owncorp.com. Click on it.Right click in the details panel and click on Other New Records.

Scroll down and select the Text(txt) record and click Create Record.

Type in your SenderID record in the Text field and click OK. Thats it!

Your zone will now include a Text record that contains your SenderID/SPF policy. The zone will update and you'll be done. The SenderID will not go into effect immediately because DNS updates take a while to propagate (up to 72 hours) so be patient.

Thats all there is to it. To make the rule creation business a little bit easier please consider udsing the Microsoft SPF Record Wizard. Yes, we went through all that discussion about rules for absolutely nothing, unless you consider the delivery of your email to be important. The problems with SenderID/SPF do not come from the record itself, but how you defined it - so without doing the due dilligence of finding and locating all your mail relay and partners, you will not be able to create a reliable SenderID/SPF record. If you did the research, its a brease - a four step one at that!

Read my other Exchange articles:

Publishing SenderID records for Exchange SP2 IMFv2
Enabling IMF 2 in Exchange 2003 SP2
Changing Exchange 2003 Store Database Limits
Exchange 2003 SP2 for SBS
Modifying the Outlook Web Access Login Page
Disabling NDR (non-delivery reports) on Exchange 2003
Setting up Exchange 2003 as an ATRN Client
Setting up Exchange 2003 as an ATRN Server

Additional Resources

Microsoft SenderID/SPF Record Wizard