Max Euston

Authenticate your outgoing email - How to setup SPF records

E-mail spam can affect you in two ways. The first is that it can be sent to you. This problem is the one that is the most familiar to all of us. However, there is a second way it can affect you. If you've ever gotten a bounce message for an e-mail that you never sent, then you've been the victim of the second way. This can also cause all mail from your domain to be falsely treated as spam by some servers (meaning that mail you send may get silently deleted).

SMTP communications protocol

All e-mail has both a Sender address and a Recipient address. When one mail server connects to another, the conversation goes something like this: (Lines where we type something are marked with a >)

We connect (from my webserver) to a mail server (on tcp port 25). The server identifies itself to us (the '220' line).

> www$ nc mail.example.com 25
  220 mail.example.com SMTP Server ready.

First, we tell the server who we are (but we will lie). The server does a reverse DNS lookup and shows our real name.

> HELO mail.euston.net
  250 www.euston.net Hello www.euston.net [216.182.45.246], pleased to meet you

Next, we specify a Sender address.

> MAIL From:honeypot@euston.net
  250 2.1.0 honeypot@euston.net Sender ok

Finally, we specify the Recipient address we are sending to. This is to a domain for which the server accepts mail.

> RCPT To:user@example.com
  250 2.1.5 user@example.com... Recipient ok

At this point, the mail server has accepted our request to send an e-mail, and we would now send the actual message, which would be delivered to the Recipient. This is an example of how e-mail (and spam) is sent.

SMTP connection showing a forged Sender address

Spammers forge the Sender address. This is easy to do, since SMTP was designed when the Internet was much smaller, and spam could be tracked back to the sender by IP address. Today, with so many home computers compromised by viruses, it isn't always the fault of the owner of that machine (the spammer has taken control of the PC).

So, lets try some variations. Here (during the SMTP conversation), we tell the server who the Sender of this e-mail is (and again, we lie). However, since this e-mail is from an imaginary domain (the mail server checks), the server rejects it (the '553' code).

> MAIL From:buddy@your.friend
  553 5.1.8 buddy@your.friend... Domain of sender address buddy@your.friend does not exist

However, if we specify a fake Sender address, but from a valid domain (that doesn't use SPF), there is no way for the server to validate this address (so it accepts it).

> MAIL From:honeypot@euston.net
  250 2.1.0 honeypot@euston.net Sender ok

Backskatter

This is the second way that spam can affect you. If a spammer uses a forged address for the Sender (possibly on purpose), and they use your domain, then you have to deal with the bounced messages, out-of-office replies, hate mail, and other repercussions.

Introduction to SPF

SPF (Sender Policy Framework) is a very simple (and trivial to implement) method to tell the world that only servers your specify are allowed to send e-mail using addresses from your domain. It does this with extra records in your DNS (Domain Name System).

How to configure SPF records in DNS

So, now let's setup the SPF record in our DNS servers. This is what is looks like in the BIND configuration file.

@       IN      SOA     gw.euston.net. root.gw.euston.net.  (
                                2008010800      ; Serial
                                3600    ; Refresh
                                900     ; Retry
                                3600000 ; Expire
                                3600 )  ; Minimum
        IN      NS      ns1
        IN      NS      ns2
;
        IN      MX      10 mail
;
        IN      TXT     "v=spf1 ip4:216.182.45.245 -all"

Here is what it looks like to the outside world.

> www$ nslookup -query=txt euston.net
  Server:         ns1.euston.net
  Address:        216.182.45.243#53

  euston.net      text = "v=spf1 ip4:216.182.45.245 -all"

You also need to setup a similar record for your mail servers.

> www$ nslookup -query=txt mail.euston.net
  Server:         ns1.euston.net
  Address:        216.182.45.243#53

  mail.euston.net      text = "v=spf1 ip4:216.182.45.245 -all"

Basically, what that says is: e-mail from any user at euston.net must come from the IP address 216.182.45.245 (my mail server).

So, now that we have setup SPF (for euston.net), here is what a failure looks like (attempted to be sent from www.euston.net, not mail.euston.net - note the last number in the IP address is different). Although the error comes after the RCPT line, and not the MAIL line, it still failes before the e-mail actually gets sent.

> MAIL From: <honeypot@euston.net>
  250 Sender <honeypot@euston.net> OK
> RCPT To: <user@example.com>
  550 SPF test returned fail <-> for : ip=216.182.45.246 sender=honeypot@euston.net helo=mail.euston.net. Command rejected.

SPF records used by other domains

Here is the SPF record for Google.

> www$ nslookup -query=txt google.com
  Server:         ns1.euston.net
  Address:        216.182.45.243#53

  google.com      text = "v=spf1 include:_netblocks.google.com ~all"

It says to check the TXT record at _netblocks.google.com for the answer. If you look there, you will see all the valid IP address ranges that are allowed to send e-mail from '@google.com' addresses.