I’ve been fighting the good fight against spammers for a few months now on and off. Not the usual fight however. This time my domain is the problem, as some nice spam-bot out there on the web has taken a liking to my domain and wants to use it as the source of it’s evil advertising campaigns. It’s annoying really, as every time this spam-bot emails to the wrong address, I end up getting the bounce message. A couple a day in July, turned quickly into a few hundred a day in August. This weekend I finally had the chance to sit down and do some research on what I can do to make this spam-bot go away and start spoofing some AOL addresses again. The answer I came across was SPF.
Ok, I guess people now are saying WTF is SPF when it’s at home. SPF is “Sender Policy Framework”, and it’s aim (if used) is to provide a way for servers receiving email to check if the sender is who they’re supposed to be. This is achieved through the use of a TXT entry on the name-server used for your domain. This TXT entry tells the receiving server what IP address you’re emails should originate from, and if they don’t match, then dump the email on the floor. In the short-term, this may not solve my problem 100%, but if even 1 spam gets stopped because I’ve added this SPF entry, then in my view it’s a job well done. Maybe it’ll even force the spam-bot to move on to another domain without the SPF set.
How do you do this you say… well it’s easy. The details are discussed on the SPF homepage and include everything you’ll need to understand how it works and what to add. You can also use a number of automatic SPF creators on the web, including the one at openspf.org. As an example, my SPF entry (which you can find by doing an nslookup on my domain) is .:
v=spf1 a a:remote.c22.cc include:aspmx.googlemail.com ~all
Looks complex… but once you break it down, it’s not that hard to understand.
v=spf1 – is the version number of SPF supported
a – means that all A records for my domain are permitted to send email
a:remote.c22.cc – sets the remote.c22.cc CNAME as permitted
include:aspmx.googlemail.com – tells the server checking to lookup the SPF record for gmail as well
~all – is the catch-all rule, that says these are the only servers permitted
See, simple really. Most domains will have a simple SPF like v=spf1 a ~all or v=spf1 ip4:x.x.x.x ~all if you only have 1 publicly addressable mail server. Mine is currently more complex as I’m testing various solutions. However in the long run it’ll end up just as an include to the Google servers.
Is SPF going to stop SPAM… NO, probably not. But it’s going to make things a little harder for the evil spam-bots of the world. After all, if the legitimate domains are protected using something like SPF (or Microsoft’s version SenderID) then the spammers will need to setup a domain to send spam from. With improved communication in the industry, these domains will be quickly blacklisted. Of course spammers can get new domains constantly (at a cost) or use DNS poisoning to force the SPF records to be blank on set servers. However, SPF isn’t meant to be THE solution. It’s just another piece of the puzzle. After all the only real solutions to spam are to make it so hard to do that it’s no longer worthwhile, or educate those people still STUPID enough to think, ooh I can help a deposed Nigerian president AND earn money…. Sign me up.
Right now I’m not sure how much spam this SPF is stopping. After all, I’m not sure how much is being spoofed. Still, if the servers support SPF checking then I’m sure it’ll be doing some good. My suggestion, if you’ve got a domain, then spend 5 minutes to set an SPF to protect others from spam that might be spoofed from your domain in the future.