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.
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 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).
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.
This simple record specifies that the domain sends no mail at all. It’s useful for domains from which you are certain that no mail should be sent. This is sometimes known as a null SPF record.
v=spf1 a –all
In this example the a tag is added, and the IP address from which the mail was received must match one of the domain’s A records.
v=spf1 a:mail.mydomain.com –all
A slight variation on the example above, in this record all servers responsible for outgoing mail have been listed in an A record in the mail sub-domain.
v=spf1 mx include:mail.com -all
The mx tag checks all MX records’ corresponding A records in order of MX weighting.
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.
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 email@example.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:
Sender-ID check details:
ID(s) verified: header.Fromfirstname.lastname@example.org DNS record(s):
mydomain.com. 86400 IN TXT "v=spf1 a include:authsmtp.com -all"
mydomain.com. 86400 IN A 184.108.40.206
220.127.116.11.in-addr.arpa. 86400 IN PTR outmail128113.authsmtp.net.
outmail128113.authsmtp.net. 14400 IN A 18.104.22.168
authsmtp.com. 14400 IN TXT "v=spf include:spf-a.authsmtp.com include:spf-b.authsmtp.com include:spf-c.authsmtp.com ~all"
spf-a.authsmtp.com. 14400 IN TXT "v=spf1 ip4:22.214.171.124/24 ip4:126.96.36.199/25 ip4:188.8.131.52/22 ip4:184.108.40.206/23 ip4:220.127.116.11/29 ip4:18.104.22.168 ~all"
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
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:
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:
Microsoft recommends that you exclude the domains of trusted partners from Sender ID processing. This can only be configured using the Exchange Management Shell:
SPF and Sender ID provide a simple, if not foolproof, way to protect not only your domain name but also your company’s reputation. In addition, on Exchange Server, Sender ID can be configured to help filter unwanted mail and protect users from malicious content. One drawback of SPF and Sender ID is that they can both break e-mail forwarding services, although workarounds do exist. If you don’t already have SPF in place for your domain name(s), regardless of whether you are currently experiencing problems, consider implementing this now so that in the event of an attempt to hijack your domain name, you can be sure the damage will be minimal.