Protect Your Name and Your Reputation

In an age where e-mail is an all-important tool for business communication, you can't afford to lose service or have your domain name hijacked. If your domain name is spoofed, your company's reputation and image could suffer, perhaps irreparably. The Sender Policy Framework (SPF) was designed to help thwart address forgery and combat phishing. Creating a SPF record for your domain costs nothing, can help improve the deliverability of e-mail and prevent domain spoofing.

E-mail is an insecure and easily forged means of communication, and as such, introduces a number of risks when used as the chief form of messaging for your business. It’s easy to send an e-mail that’s addressed as yours, from a domain that’s not yours, which means that anyone could masquerade as a representative of your organization. If a spammer uses your domain name to send e-mail selling Viagra, your company will be embarrassed and your customers may lose confidence that you can secure your data and communications.

Sender Policy Framework

The SPF is intended to reduce the likelihood of forged e-mail and phishing attacks that appear to originate from your domain. SPF in itself is not designed to prevent spam. E-mail servers that support SPF perform a DNS lookup on the domain name contained in the MAIL FROM and HELO SMTP commands of an incoming message. It then compares the IP address of the received message against a list of IP addresses, as defined in the domain's SPF record. This check provides an authoritative response, as the SPF record in DNS can only be published and modified by the organization that is responsible for the domain.

Sender ID

Sender ID is Microsoft’s antiphishing and spoofing technology, but instead of using the MAIL FROM and HELO commands in the envelope sender address of the SMTP protocol for DNS lookup, it uses an algorithm called Purported Responsible Address (PRA), which attempts to determine a header field in the message itself that contains the sender’s address. SPF and Sender ID perform checks at different layers, although as Sender ID is based on SPF, it can also check SMTP’s MAIL FROM and HELO commands.

Whether you choose to implement Sender ID or the more traditional SPF-check on MAIL FROM and HELO, the record published in DNS does not need to be changed if the MAIL FROM, HELO and PRA domains all match. If not, you need to publish a SPF record for each domain represented.

In addition to SPF, Sender ID also uses so-called Reputation Data to give the sender a rating based on various criteria, such as how much spam has been sent in the past from the domain and information from honey-pot trap accounts. Depending on a sender’s reputation, it’s possible to configure a mail server to block or limit how a message is displayed to the end user. For instance, images or attachments could be blocked based on the Reputation Data. In larger companies, where departments might garner different Sender ID reputations, it’s recommended that you use sub domains for each department. If the marketing department might earn a low Sender ID reputation because it sends a lot of e-mail, a marketing.mycompany.com sub domain could be used to differentiate its Sender ID reputation from the billing department’s (billing.mycompany.com).

Creating SPF Records

Before creating any SPF records on your public-facing DNS server, you should make a list of all outgoing mail servers and domains. Domains that aren’t used for outgoing mail should also have an SPF record, but more about that later. Although automated systems for generating SPF records can be a good starting point, they might not offer the best solution for your needs. I recommend that you try and understand the syntax so you can be in full control.

SPF records are DNS text (TXT) records based on a simple syntax, which you can either write yourself or generate using a web-based wizard. How you add this record to DNS will depend on a number of factors: whether your DNS is hosted internally or by your ISP, and what DNS server you use, for instance. Here are some examples of SPF records and how they affect mail delivery. The aim is to include all servers in the record, either explicitly or implicitly, which are responsible for sending outbound mail for a domain.

More information on the SPF syntax can be found at www.openspf.org, along with a wizard if you are not sure about writing your own record. When you first create a record, you should use the ?all tag at the end of the SPF string until you are certain that mail is being delivered successfully (?all sets neutral matching, and does not strictly enforce the settings).

You should make sure that outgoing mail servers are listed only once in your SPF record. For instance, if the mx tag is used, you don’t need to specify any servers it includes using the ip tag. You should make sure your SPF string doesn’t accidentally specify mail servers that are used only for incoming mail.

Testing Your New SPF Record

Once you’ve added the new SPF record to DNS, you need to allow up to 48 hours for DNS propagation. After this time, there are various online tools for checking if your domain has a valid SPF record. http://www.kitterman.com/spf/validate.html contains all the basic tools and more.

For a comprehensive check, send an e-mail to check-auth@verifier.port25.com from every IP address specified by the SPF record. The reply gives detailed information about SPF, Sender ID and SpamAssassin. Here’s an example reply message for mydomain.com showing a pass result for SPF and Sender ID:

In the above example, authsmtp.com is delegated permission to send mail on mydomain.com’s behalf using the include tag in mydomain.com’s SPF record. The results show that authsmtp.com also has SPF records. It’s also clear from the results that SPF checks SMTP commands, and Sender ID the message header, by observing the ID(s) verified field in the report. Once you’re satisfied that the SPF record is valid, and that e-mail is being delivered successfully, you can change ?all to –all and retest after DNS propagation.

Windows Live Hotmail caches SPF records for improved performance. The cache (known as the SIDF cache) is updated several times a day and you can add your domain once your SPF record is in place using the following link:https://support.msn.com/eform.aspx?productKey=senderid&ct=eformts

Configuring Exchange 2007 for Sender ID

Antispam and other message cleansing features are automatically enabled on Exchange Edge Transport servers, and can be switched on for the Hub Transport role if you’re using it for Internet mail. To switch on antispam agents on a Hub Transport server, run the following script from the Exchange Management Shell:

1. Log on to your Exchange Hub Transport server as a local administrator and open the Exchange Management Shell from Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Shell.
2. In the Exchange Management Shell command prompt window, change the working directory to c:\program files\microsoft\exchange server\scripts.
3. Run the following command (Figure 1):
   .\install-AntispamAgents.ps1
4. Restart the Exchange Transport service by running the command (Figure 1):
   restart-service msexchangetransport
   
   (Figure 1)
   
   
5. Open the Exchange Management Console from Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Console.
6. In the left-hand pane, expand Organization Configuration under Exchange and click Hub Transport. In the central pane click the Anti-spam tab and check that Sender ID is enabled as shown in Figure 2.
   
   (Figure 2)

Only external messages are evaluated by Sender ID through all Receive Connectors on the server by default. Now that Sender ID is enabled, let’s configure how Exchange processes messages that fail Sender ID or cannot be evaluated:

1. In the central pane of the Exchange Management Console, click the Anti-spam tab and double click Sender ID. On the Sender ID Properties dialog, select the Action tab (Figure 3). The default action, as shown in Figure 3, is to stamp the message with a Sender ID result and pass the message to the Exchange Content Filter for processing. You can however choose to simply delete or reject messages.
   
   (Figure 3)
   
   
2. If the Sender ID status of a message cannot be calculated, due to a transient error such as a failed DNS lookup, a temporary error is generated. The default action is again to pass the message to the Content Filter for processing. You can, however, change this behaviour using the Exchange Management Shell and the Set-SenderIDConfig command with the TempErrorAction switch. For example set-SenderIDConfig – TempErrorAction Delete will delete messages if a transient error occurs. Possible values for the TempErrorAction switch are StampStatus, Delete and Reject.

Microsoft recommends that you exclude the domains of trusted partners from Sender ID processing. This can only be configured using the Exchange Management Shell:

1. Open the Exchange Management Shell and run the following command to exclude domains from Sender ID:
   set-SenderIDConfig -BypassedSenderDomains trustedp1.com,trustedp2.com
2. If you want to exclude specific recipients run:
   set-SenderIDConfig –BypassedRecipients bob@trustedp1.com,john@trustedp2.com
3. To confirm Sender ID configuration on Exchange you can run the following command (Figure 4):
   get-SenderIDConfig
   
   (Figure 4)