howto://Use SPF records to combat domain spoofing

  Spam. When you’re talking about the Hormel product, love it. When you’re talking about unsolicited commercial email, I hate it with an abiding passion usually reserved only for the ankle-biter at Fox that cancelled Serenity. But any way you slice it, the bane of email’s existence is spam. Spam spam spam spam, lovely spam! Wonderful spam! Shut up! Bloody Vikings! You can’t have egg bacon spam and sausage without the spam. And we can’t seem to have email without it either. There are a couple of things we can do to help reduce the amount of spam that we deal with, kind of like having your spam on the side. One of them is to implement Sender Policy Framework records.

Sender Policy Framework (SPF)

SPF records are text records we can add to our DNS zone that define the servers allowed to send email for our domain. They help combat spoofing by defining all of the servers and/or ip.addrs that might send email for our domain, and are a little more flexible than just doing MX record lookups since SPF includes provisions for senders that aren’t receivers, and third parties that we trust to send email on our behalf. A server that receives inbound email, and supports SPF lookups, can be configured to use SPF to ‘validate’ that the sending server should be sending mail for the domain in the “mailfrom:” address. Exchange 2007, 2010, MailEnable, and others all support performing SPF lookups to evaluate incoming email.

SPF also has the advantage of being something you can define for any domain, large or small, whether you fully control DNS or outsource it to a registrar. An SPF record is just a text record. BIND, Windows DNS, outsourced DNS providers like NetSol, GoDaddy, Enom, and the like all let you enter text records, so even if you don’t have any physical systems, you can still use SPF to validate mail sent from your domain.

Here is what the SPF record for retrohack.com looks like.

@      IN      TXT      v=spf1 mx ip4:64.202.166.233 ~all

Translating that, we can see that the first three fields are common to most DNS entries

• @
  This simply indicates the domain
• IN
  An Internet record
• TXT
  A text record

And the last bit is the actual SPF record, which in this case contains four key ingredients in the text field.

• v=spf
  Identifies this as an SPF record, since there are other types of text record
• mx
  This is a mechanism that means any server that has an MX record for the domain could send email for the domain.
• ip4:64.202.166.233
  This is a mechanism that means this ip.addr can send email, even if it cannot receive it (that’s the host for this site.)
• ~all
  This is a qualifier that indicates a SOFTFAIL, which tells a receiving server that there could be other legitimate senders for mail from retrohack.com, but if you get email from one of them, look at it more closely.

RFC4408 defines SPF records, and specifies eight mechanisms and four qualifiers.

Mechanisms

• IP4
  An ip.addr, which can be a host address, or a network range using CIDR notation.
• IP6
  An ip.addr, which can be a host address, or a network range using CIDR notation.
• A
  The sending host has an A record in DNS (AAAA if using IPv6.)
• MX
  The sending host matches an MX record in DNS.
• INCLUDE
  Lets you identify other domains with SPF that may send mail as coming from your domain.
• ALL
  Not commonly used, matches always as a default.
• PTR
  Not commonly used, depends upon PTR records.
• EXISTS
  Not commonly used, if the given domain resolves, match.

Qualifiers

Each mechanism can be combined with one of four qualifiers to define what action to take should mail be received from a particular host that matches the mechanism arguement.

• + for a PASS result, which can be omitted.
• ? for a NEUTRAL result interpreted like NONE (no policy).
• ~ for SOFTFAIL, a debugging aid between NEUTRAL and FAIL.
• - for FAIL, the mail should be rejected.

In theory, you could blacklist servers that have spoofed you by listing “ip4:w.x.y.z –all” but in practice, we just want to list the servers that should be sending mail.

Sold on the concept? Great, here is how to create an SPF record for your domain, without really having to craft it by hand. There are some easy to use websites that will help you create your SPF record and validate the record for you before you add it, and once you have it in DNS.

• Microsoft’s SPF Record wizard can be found here. It will walk you through a wizard (it is Microsoft) that at the end will create an SPF text string you can just copy and paste into your DNS record.
• OpenSPF.org has a page on their site with another wizard based creator for SPF records. It is a little harder to follow the first time you are doing this, but does an excellent job of creating the text for your SPF record, and is easy to understand once you go through it once.
• Kitterman Technical Services has a page on their site that can validate your SPF syntax before you create your record in DNS, and can also look it up in DNS to verify it is there and correctly formatted.

Keep in mind that the RFC is still considered experimental, so SPF is not yet widely adopted. The RFC calls for a new record type for SPF (akin to A, CNAME, etc.) but even Windows 2008 R2 doesn’t implement that yet. However, the key to moving an experimental RFC to mainstream is adoption. Considering how easy this is to do within DNS, and that most new mail server programs support it, we can now do our part to help. Retrohack’s webserver is hosted at GoDaddy, it’s email is handled by Google Apps, and it’s DNS records are handled by Name-Services.com, and I was able to implement SPF records easily.

And finally, since there may still be someone out there who has no idea what the heck breakfast and Vikings has to do with this post, behold the Monty Python skit often credited with being why UCE is called Spam.

Are you using SPF records in DNS? Have you configured SPF lookups on your inbound mail servers? Do you understand that Monty Python is the ultimate in humour? Tell us what you think by leaving a comment.

You might also enjoy:

1. Creating DNS records at the command line
2. Recycling domain controller names
3. howto://protect your network from spam
4. howto://use BIND secondaries with an AD integrated primary DNS

Tagged as: best practices, howto, networking