Authenticating your Emails with SPF
Following up on last week’s post about Yahoo’s DMARC policy change, here’s how to authenticate mailings that (a) you send, and (b) we send on your behalf. Before going into this, I want to make this point abundantly clear:
FeedBlitz automatically authenticates email we send; you don’t HAVE to do anything.
And for the vast majority of our clients, that’s perfect! That said, let’s say you want to authenticate email you send for your site’s domain anyway, and email we send for you as well. OK, sure, can do. In order to make that happen, you must have the ability to add a TXT record to your DNS settings, because that’s how SPF (the authentication protocol we’re going to set up) works.
Got that ability? Ok, good. Here’s what you have to do.
If you don’t have an SPF record already in place, you can simply add this as a TXT record to your domain’s DNS:
v=spf1 include:mail.feedblitz.com ~all
What this says is “hey, I’m an SPF authentication record for <my site’s domain>, anything that mail.feedblitz.com sends on my behalf is OK, anything else you should look at closely.” This SPF entry in your DNS will authenticate email sent by FeedBlitz for your site based on your SPF records (remember, FeedBlitz’s emails already authenticate based on our SPF records, and your SPF entry won’t change that). It also invites providers to look more closely at other emails that purport to be from you. If this makes you nervous, replace “~all” with “?all” but then the SPF record doesn’t really say much of anything; it’s effectively a test entry that will, in the real world, have no effect at all.
You should therefore think about email sent by, or through, other systems on your behalf. Let’s say that you’re using Google Apps, and you send email for your site through your Google Apps account. Here is what Google help says should your SPF record be:
v=spf1 include:_spf.google.com ~all
So, to tell receiving ISPs that it’s really OK for your domain to have email sent on its behalf by both Google Apps and FeedBlitz, here’s what you should set your SPF record to be in your DNS:
v=spf1 include:_spf.google.com include:mail.feedblitz.com ~all
In other words, you simply add include:mail.feedblitz.com to any current SPF record (or the example given to you by your provider), and email we send on your behalf will authenticate using both our SPF record and yours. So for the above record, Google Apps will authenticate as well as FeedBlitz. The same approach works whatever ISP or service you use to send your site’s emails through. All you need to do is find out is what you need to have for your SPF record for the system you typically send email through, and then add the include:mail.feedblitz.com text to it. Your provider should be able to help you with the record you need to add for their systems.
Now, if you research SPF, you will see that some recommend using “-all” (dash all) instead of “~all” (tilde all) at the end of the SPF record. It’s a critically important difference, and I really don’t like that advice for bloggers and businesses without dedicated and email-savvy IT staff. You should think very hard before using the “-all” version. Here’s why.
The tilde version “~all” says “Look closely at email that doesn’t authenticate, but we’re not saying it’s definitely bad” — effectively leaving ISPs to use their best judgment to determine whether email that purports to be from you but doesn’t authenticate is spam (or not). I certainly recommend using this option, at least at first. It’s the safest way to avoid valid email from you being accidentally junked. ISPs are really pretty good at blocking junk based on things like IP reputation, content filters and other techniques. Most of the time, this is going to be A-OK.
Switching to the dash version “-all” says something very different: “Any mail that does not authenticate is definitely junk.” That’s something you should only set if you’re really, really sure that statement is true, because now you’re saying anything and everything else is absolutely spam.
How could this possibly go wrong? Well, for example, say you send an email from home via your cable provider’s email servers instead of Google Apps or FeedBlitz for your blog’s domain, assuming that is how you’ve set up your SPF record. The “-all” now says that the email you just sent is junk. As a result, it might not be accepted by your recipient’s email provider at all, and if it is, it will certainly be routed to their spam folder. The same might happen if you use a third party service, such as a shopping cart or help desk system, that sends mail on your behalf, but not using the mail systems you identify in your SPF record. Or, say you switch hosting services or email providers and forget to update the SPF record you created several years ago. All your email will be junked, thanks to that “-all”, until you fix your SPF record.
So you need to be very, very sure that email will only be sent from the domains and IP addresses that you specify in your SPF record before you switch to the “-all” version of SPF. And you need to remember to update it as you add, switch or drop online service providers.
Now you know how to set up SPF for your domain. After you do this, you should ensure that emails we send on your behalf are from an address on that domain, and not a generic consumer provider, so that the authentication you set up can take effect.
The flaw with SPF, which is why it’s imperfect, is that other spammy systems might authenticate correctly for themselves (because of their own SPF records) but still spoof your address. That’s the situation DMARC addresses, (and what caused all the problems with Yahoo), and I’ll cover that tomorrow.