Creating a SPF record for your domain

In this installment, we will look at how you can configure an SPF ( Sender Policy Framework) record for your domain. We are going to assume you have a basic working knowledge of how to edit domain records using the tools like CPanel, Webmin, or your host/domain name provider’s control panel or (for those who are really geek-crazy) by hand in Bind. If you are not familiar with domain names read this guide.

The problem

If you have taken computer security classes at some point you are probably tired of hearing this but it is true: the people who created the early version of the internet never imagined it would be so popular as it is today.

Back then the internet community was a small tight knit group of Academic, Research and Development and Military and other such organisations. Everyone knew and trusted each other. As a result when things like emails and the web were developed security was not upmost in the developers’ minds.

The Simple Mail Transfer Protocol was one of those protocols developed during that era of trust. In the early days were few people were on the internet Spam was probably unheard of and if an email said it was from “john@berkeley.edu” it almost certainly was really from John at Berkeley.

Then people like Gary Thuerk started getting online and honour is not their thing. With the rise in the number of people with access to Broadband internet there has been a rise in Spam emails.

From Gary Thuerk’s first spam blast of 393 emails the number has grown significantly over the years. More than 15 billion spam messages are sent everyday i.e. more than half (about 66%) of the emails sent are spam.

Most Spammers employ spoofing and phishing techniques. By its design the SMTP protocol is susceptible to spoofing. It allows an email sender to claim to be anyone using the mail from command.The following commands in a terminal for example will allow you to send an email to someclient@clienthost.co.zw claiming to be manager@somebank.co.zw:

telnet mail.yourmailhost.co.zw smtp
ehlo localhost
mail from:<manager@somebank.co.zw>

rcpt to:<john@example.com>
data
Dear Client,

If you are one of the dumb people actually believe this email is from your bank,give me your banking password so I can steal your hard earned money.

Yours truly,

Some Random Dude Who wants to Steal your money

.

How SPF solves this problem?
An SPF record is an additional DNS records in your domain records that tells other SMTP servers out there which servers are allowed to send emails in your name. What this means is that if a scammer attempts to send emails in your name, something that they are likely to do using their own servers, those emails will be either be marked correctly as spam or rejected outright depending on your instructions as they appear not to be originating from you.

SPF options

For most people the simple txt record will suffice:

yourdomain.co.zw.  IN TXT "v=spf1 mx a -all"

This record simply says that only hosts listed in your MX records (the mx in the record) and your webserver (the a in the record) (if any) can deliver mail. If the receiving MTA implements SPF as part of its spam fighting arsenal it will reject all emails that do not originate from your servers but are purporting to be from your domain (the -all directive in the record). If you would rather have such messages marked as spam instead of being rejected for some reason e.g. you are still testing to see the effects of this configuration then you should employ what is known as a soft fail:

yourdomain.co.zw.  IN TXT "v=spf1 mx a ~all"

The tilde “~” character before all tells other MTAs to do a softfail i.e. mark any messages not coming from your authorised servers as spam instead of rejecting the messages.
Chances are if you use Gmail apps or Hotmail you were asked to set up a txt record for your domain already. Below is an example of Google’s spf record:

v=spf1 include:_spf.google.com ~all

Include directive simply tells the querying server to include directives for the domain _spf.google.com thus allowing Google to add and remove permitted mail servers without you having to change your DNS record whenever Google updates their settings.

In the early article some recommended that startups use SMTP services like MailChimp (Mandrill). If you had such a set up and also used Gmail apps your TXT record would look like this:

yourdomain.co.zw.  IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net ~all"

SPF records can be set with a lot of other options for example authorised server CIDR blocks.You can use the dig command to examine other people’s SPF records in the wild. For example:

dig twitter.com txt

will show you Twitter’s  SPF configuration.

You can also use the SPF record wizard here to easily create your SPF record.
Entering the SPF record.

Once you have created the record you will have to enter and effect it in your domain name control panel. How you do this depends on the type of control panel you use but the steps below should work for most.

• Create a new txt record. Some control panels require you to access the advanced editor tab to do this.
• In the name box type yourdomain.co.zw.
• Paste the part of the record in quotes including the quotes for example  for the record:yourdomain.co.zw. IN TXT “v=spf1 include:_spf.google.com include:servers.mcsv.net ~all” you should paste:

  "v=spf1 include:_spf.google.com include:servers.mcsv.net ~all"

• Set the TTL to a valid preferred value e.g. 7200

NB. You should note that not all MTA’s check for a SPF record. A lot of servers out there simply ignore it. And those that do check only use it in an advisory basis e.g. a record that calls for emails from unauthorised servers might be treated as a softfail instead. Most reputable mail servers however implement SPF.

Also SPF does not prevent some unauthorised sender e.g. user1@yourbank.co.zw from claiming to be say bankmanager@yourbank.co.zw. As far as remote hosts are concerned this email is authentic and will be delivered as being from your bank. If spammers manage to get one of your user’s email password they can easily defeat the SPF record by using this user’s password and your server to spam people.

There are two ways to thwart such attacks:

1. Limit the number of emails that your users can send. Why would Jane the receptionist be send 300/day for? Will look at how you can do this using Postfix in our next articles.
2. Prevent sender spoofing i.e. if a sender authenticates as janethepa@yourdomain.co.zw make sure she cannot send mail purporting from theboss@yourdomain.co.zw. We will also look at how you can do this in Postfix.

I hope you find this useful. As always please leave your comments below if you have any tips, tweaks and as always opinions you want to share.