All About Sender Policy Framework
What Is SPF?
Well, let's start with what SPF is not and move forward from there. SPF is not a solution for spam. It does not stop spam from being sent or received. It will not block spam from hitting your mailbox. In fact, it won't even stop spam from being sent out through your own server. What is it then? A solution for email address spoofing. Spoofing is when a spammer sends out a batch of email and it is made to look like it came from you. See, spammers will push out a ton of spam emails and a great majority of it gets bounced back to them as undeliverable. They don't like that. It wastes time for them. So they came up with a solution. Get an address that works and send out that spam as if it came from that address. Your address. The result is that you get all those bounceback messages. Nice, right?? Well, that's where SPF can help.
SPF allows a domain owner to specify how and by whom emails can be sent. Mail servers who check for an SPF record can make sure that the person sending an email is actually allowed to send it. When someone else's mail server receives a message claiming to come from your domain, then that receiving server can check whether the message complies with your domain's stated policy. In other words, if someone sending an email out as if it came from yourdomain.com, but it is actually being sent from gmail.com, the receiving server can nix the email since gmail.com would not be listed in your SPF setting in your domain's DNS zone.
This Is All Just A Bit Confusing!
It can be. So, here's a little diagram that might help.
I hope this illustration shows the process in a way that most people can easily follow what is happening. Some of you out there might be screaming inside at the moment... "This looks like it should STOP spam! Why doesn't everyone do it??" Well for a few reasons. It creates a need for more processing power for email servers. To have to look up the permissions for each and every email that comes along would be too much for some servers to handle. They don't have the CPU power to make it work. Also, there is a bandwidth issue. If every email server suddenly started verifying everything out there, where would the net be? Congested with DNS lookups? And will it cost a company extra if suddenly their servers start looking up data about each email that they receive? Ultimately, yes.
The Big Reason SPF Is NOT The Spam Killer
Even more than all those reasons given above is the fact that spammers are now more often sending their filth out through legitimate servers that have been compromised. A spam email sent from a compromised server would actually pass this verification process. So even if everyone in the world embraced SPF and implemented it properly, it would still fail. The truth is that were SPF more popular right now, we would have a whole lot more computers out there which were unknowingly acting as spam slaves. Should the normal route of sending out spam close for spammers they would redouble their efforts to use legitimate machines to do their dirty work.
So Why Publish An SPF Line At All
Many bigger companies are now doing SPF checks on incoming mail. It's a good idea to publish an SPF record in your DNS zone so that mail delivered to them by a spammer who is spoofing your domain in a dictionary attack is not bounced back to you. The result of a dictionary attack is usually hundreds of bounced emails ending up on your doorstep because they really do not exist.
How Do I Do It?
If you would like to create your own SPF record for use on your website, you can learn more about how to do so at www.openspf.org. Or you can let us create one for you. However, in order to implement the record you must contact us via the support ticket system. We will be more than happy to add the record to your DNS zone file. But we do not allow users to edit their own DNS zone records for security reasons.