Networking Setup Notes

name and address
created jul 5, 2010

Setting up SPF

Well, they've done it again. Those geniuses have come up with yet another way to screw up our email. It's called SPF or “Sender Policy Framework.” If you're reading this page, you probably know by now that SPF has nothing to do with protecting your email server against sunburn. It's a way of blocking your domain unless you make more changes to your DNS server. If your mail server doesn't follow these rules, you're assumed to be a spammer and all your outgoing email gets bounced. You will get burned.

What is SPF

SPF is an earlier version of DKIM. The recipient mail server queries your DNS server to find out if the email really came from one of your IP addresses. If not, or if you don't have SPF installed, the message is assumed to be spam, and it's bounced. Yes, it's stupid ... but you should be used to that sort of thing by now. Apparently, some people are actually using it.

Installing SPF

The hardest part about installing SPF is accessing the OpenSPF website . The information here is taken from the Zytrax website. Since I've never been able to access the official SPF website, I can't tell if the information shown here is correct. But I've been using it, and it seems to work.

  1. Make sure you are running BIND 9.4 or higher.
    strings /usr/local/sbin/named | grep "named version" 
  2. Insert four lines of SPF stuff in your domain record. These SPF records have the same format as a standard TXT record. For example, suppose you had one mail server for a domain called You would probably already have an MX record like this:
    ; zone file fragment for
                  IN  MX 10
    mail          IN  A
    To add Sender Policy Framework stuff, you would slather the the following four SPF lines into the "@" section of your domain file:  IN  TXT   "v=spf1 mx -all"  IN  SPF   "v=spf1 mx -all"
    mail          IN  TXT   "v=spf1 a -all"
    mail          IN  SPF   "v=spf1 a -all"
    Somewhere in that file, you need to specify the IP address of the mail server in an address or A record. A line like this should already be in there:
                IN   A
    That's it--much easier than DKIM. Don't forget to turn off the named daemon while you're doing this. Next, increment your serial number and re-start named. Next, wait for a couple days while the changes gradually propagate throughout the Internet. (In reality, it often takes two weeks or longer, plus the caching time specified in your zone file.) Now, you're protected from the harmful rays of the recipient's MTA.
  3. If your email is handled by an off-site mail server, you would use an include entry, like so: IN  TXT    "v=spf1 -all" IN  SPF    "v=spf1 -all"
    This passes the responsibility onto, and will only work if has SPF set up properly.
  4. The little punctuation mark before the all is important. '-' means non-matching entries will fail, '~' means they are neither pass nor fail, and '+' means they always pass. Using the third one means that you think SPF is valueless.
  5. Another possibility is to validate all hosts in a given subnet. You would change the four SPF lines to indicate your subnet, using IPv4 Classless notation, like so:  IN  TXT    "v=spf1 ip4: -all"  IN  SPF    "v=spf1 ip4: -all"
    mail          IN  TXT    "v=spf1 ip4: -all"
    mail          IN  SPF    "v=spf1 ip4: -all"
    Obviously, you would put your own network information here, not a 192 /27.
  6. Here are the two lines we use on one of our domains. These lines are known to work. The trick is to use one SPF and one TXT line. IN SPF "v=spf1 a mx ~all" IN TXT "v=spf1 a mx ~all" 
  7. It goes without saying that the above should be done on the name server that is authoritative for your domain.

There are a few other features, notably adding a DNS Black List feature. I do not recommend using these, as these DNSBLs are notoriously inaccurate. An SPF testing tool can be found at

Okay, let's see ... Did I miss any sunscreen jokes?