A call to action: Embrace SPFWritten 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.
- + 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.
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.