Working with SPF Records

Today I finally sat down and learned enough about SPF records to actually get one deployed on a site I'm setting up. What's an SPF record, you're wondering? Perhaps you are too lazy to click one of my provided links. No problem, here is a description anyone can understand.

So email is more like a normal letter than you might expected--not surprising, since most systems are built modeled after existing systems--and includes things like a sending address and a return address. In the world of email, these are the "To:" header and the "From:" header, respectively. So, if I were to send you an email, the top of it would look something like:

To: "John Doe" <jdoe@example.com>
From: "Sean Kellogg" <skellogg@probonogeek.org>
Subject: A message
...

Thus, you would know the email was from me and treat it appropriately.

Trouble is, just like a return address on an envelope, there is no way to be certain the return address is accurate. I could stamp all of my envelopes with 1600 Pennsylvania Ave. and it would still get delivered (well... maybe, not sure how USPS would respond to that particular address). Point is, I could send the following email to you just as easily as the one above.

To: "John Doe" <jdoe@example.com>
From: "Bill Gates <bill.gates@microsoft.com>
Subject: A message
...

and the mail system would happily send it off your your mailbox. So, you've got one class of people who are trying to steal your identity. The other class of folks are those who are more interested in masking their own. This group is known as spammers. I would say all spam today is sent using forged headers, such that the From: header is set to either a non-existent email address or some poor unsuspecting by-standard.

Enter SPF records, which are a mechanism to validate the From headers. Basically, as a domain manager, you declare a set number of machines which are authorized to send mail on behalf of the domain. Then, mail service providers are responsible for checking that declaration to ensure that the originating server is one of the authorized senders. In the microsoft.com example, the mailhost would figure out all the valid servers that can send email on behalf of microsoft.com, realize my server is not one of them, and reject the email.

The only part left is to figure out how to write SPF records. Turns out it's not as hard as I expected, once you know how. I recommend the following wizard as a great starting point for defining your SPF records. All you need to do is specify the domain you are managing, and then list the various servers you want to authorize to send on your behalf.

Of course, that last part is easier said than done in some cases. The domain I was doing this for uses google apps for mail delivery, and lord only knows how many different servers are involved with the gmail setup. Thankfully, the SPF folks were prepared for that! There is an "include" directive as part of the SPF spec that allows you to say, "in addition to these settings, include the settings from this other SPF record." Then you just point at the gmail SPF record and your set.

I'll be honest though, I'm not certain about this whole SPF system. For example, I use the washingtonpost.com article sender to send stuff to friends and colleagues. Those emails are generated by washingtonpost.com servers and set the From: header to my address. Except, if the recipient host is set to enforce SPF records, it's going to get the email and say, woah, washingtonpost.com is not authorized to send for probonogeek.org! Not sure how this problem gets resolved, but there needs to be a way for address holders to authorize third party sites to send email on their behalf on a one-at-a-time basis. Any bight ideas out there?