A call to action: Embrace SPF

Written by Ed Fisher on October 20, 2010

In today’s post, I’m going to ask for your help. I want you to do something that you know is the right thing to do, is something you have been considering doing anyway, and is also fairly easy to do. I want you to embrace SPF. If you haven’t used SPF yet, then I want you to implement SPF records for all your domains, and start with SOFTFAIL. Don’t worry, I will help you get there. If you are already using SPF records, then I want you to flip the switch and go from SOFTFAIL to FAIL.

SPF records could be one of the most effective ways available to reduce SPAM by combatting spoofing. Our edge servers could dump spoofed email into the bitbucket instead of the inbox, but they are not. Why? Because most admins are not implementing SPF, and those who are using them aren’t using them as they should. Until the majority of domains implement SPF records, our MTAs can’t start rejecting spoofed email. We need to fix this, leading by example.

If you are not familiar with using SPF records, you can check out How to use SPF records to combat domain spoofing. In this post, you’ll learn what SPF records are, how to implement them in DNS, and how to create them using some handy wizards on the Internet.

If you are already familiar with SPF records then you know that there are four actions that can be indicated by an SPF record.

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

Keep that in mind…a – indicates that any mail purporting to originate from a domain that is sourced from a server not covered by the SPF record should be rejected. In other words, if a mail system administrator is certain that all his official, approved MTAs are covered in the SPF, then s/he is telling you to reject any email that comes from anywhere else. Seems pretty straight forward to me. If you know what your senders are, or even just your company’s subnets, then you can safely state that anyone else is bogus. We’ll come back to this point in a moment.   

A recent post by my co-blogger John Mello, titled Sender authentication effective, but no panacea against spam , covered some of the shortcomings of using SPF records in that post. It’s another great article from John, and I encourage you to go read it, but in case you don’t have time, I am going to reprint a graphic from his post here, and call out a couple of things about it.

 

Notice the number of SPF hard fails? Only 3%. Here’s that point I promised to come back to. Remember what a hard fail is? It is when an SPF record indicates that any mail not sent from one of the ‘official’ MTAs should be rejected.

In other words, in this study only 3% of email received was marked with an SPF that indicated a hard fail policy. That number really disturbs me. It begs certain questions… Are email admins really that ignorant of what systems send their email? Can’t they  work with the network engineers to identify the company’s subnets, or the firewall admins to prevent unapproved corporate servers from sending outgoing email?

I don’t know about you, but I know what servers I have that should be sending mail… my ISP’s smarthost, my blog server, my Exchange server. Nothing else out there should be sending email from retrohack.com, so I have flipped that bit. If there is something out there sending email as if it is from my domain, I want it to fail. My SPF record now indicates a hard fail. If you are checking SPF records on incoming email, and you see something that isn’t covered by my SPF record…dump it in the bit bucket. I am fine with that.

Join me by implementing SPF records if you are not already. If you are, start using a hard fail, too. With enough systems using SPF, we can shift this from a great idea poorly implemented, to an effective way to eliminate spoofing. We can stop looking at spoofed email as possibly legitimate (~) and instead start rejecting email the way (-) tells us we can.

Comments

Karl October 20, 2010

Ed, having gone through this process of setting up it is a valuable reminder to change it to -. However, one thing that gets short shrift is that many offices with a filtering firm like messagelabs need to make sure their filtering firm supports SPF and get the appropriate server information from them as well. (Messagelabs does provide that info on request). And, also important is you make sure to address 3rd party services that you use whether they be survey tools, landing page services, etc. that send emails with your domain in the from field.

If someone else (without telling IT) sets up a online survey account or other service that is sending email on your behalf and you have -, you take the blame not them.

So what I would suggest is that ~ to – is a business process problem because it involves locking down other depts. into making sure they keep everyone informed. Again, larger companies not a problem, smaller businesses more of a problem.

Ed Fisher February 17, 2011

I see your point Karl, and in many businesses that could be a problem, but when Sales & Marketing starts to get into things that are traditionally the purview of IT, bad things can happen. I try to make a deal with them…they don’t do IT without me, and I won’t set up a company Facebook page without them :-) .
Flipping the ~ to – could break things, so when you do it, make sure you have informed every stakeholder, and let them know what to look for that would indicate issues, like increased bouncebacks.

  • (required)
  • (required)