By implementing an SPF record (sender policy framework) spammers and phishers are less likely to choose your domain as their ?cover? domain.

This is because spammers will seek domains which do not implement any form of email authentication as there is a higher chance they will get through spam filters at the receiving domain. Without SPF/email authentication when the remote mail server receives an email it will have no way to verify or check whether the email is likely to be genuine or not and will therefore have to rely on unreliable content filtering to establish whether the email is likely to be spam or not. Content filtering relies on patterns like words or phrases within the body or subject of the message and the receiving mail server will make a decision on whether your email is genuine purely on the content of your message. With SPF the spam filter at the remote mail server will be able to make a more informed decision as to whether the message is genuine or not.

If you do implement SPF however it is still possible that spammers will attempt to use your domain as their cover domain and attempt to deliver messages using it. When this happens the remote mail server will check against your SPF record and recognize that the source of the email it has just received is not authorised to send email for your domain and is likely to block or quarantine your message. This means that if your customers or potential customers are the target of the spam the vast majority of the emails will be blocked which will reduce the impact to any of your non internet savy client base. In addition to helping your own client base and protecting your own brand you are also allowing the wider internet community to cut down on the amount of spam on the internet by being able to pickup on more of it and block it.

SPF can also help you reduce the amount of users that blacklist your domain. Lets imagine a scenario when you have not implemented SPF, a spammer has successfully delivered email to many domains around the word seemingly coming from your domain/brand. In this instance there are likely to be many people around the world marking these emails as spam. Many spam filters use bayesian techniques for the spam filter to ?auto learn?. This means that once a user has marked an email coming from your domain as spam, the spam filter will analyse every part of the email, looking for phrases, html patterns, images and the from domain and email address. If the spammer is sending many different emails using your domain one of the few things that will remain consistent will be your domain name and the spam filter will pickup on this. If you then send the mail server that has auto learnt about your domain and the large amount of spam coming from it, a genuine email, the chances are it will be blocked. The chances of this happening will be much reduced if you had implemented SPF.

Spam filters don't only negatively score emails which fail the SPF check. If an email from a domain passes an SPF check, it is quite feasible that the administrator of that spam filter has added a policy to positively score that email. This means that genuine email from your domain is MORE likely to be delivered to the inbox of the person you are sending an email to.

In Summary then the reasons for implementing SPF are :-

* You domain is less likely to be used by a spammer.
* If your domain is used by a spammer, the emails are far more likely to get blocked.
* You help reduce the amount of overall spam on the internet.
* Your domain is less likely to be blacklisted by bayesian spam filters.
* Genuine email is more likely to get through spam filters.

That being said however, the biggest objection to SPF is that many people think that it ?breaks? email forwarding. This is where the email is received by one mail server and then forwards it to another for a particular account or domain. Although this is true if the email server receiving the forwarded mail does inbound SPF checking there are several workarounds you can put in place.

One of most commonly used workarounds is to whitelist the mail server that forwards mail to your own. This means that it can fail the SPF check but you can still choose to allow the email through. The vast majority of mail servers allow whitelisting and this is normally very easy to implement. If you however can not support whitelisting there is another option. The other option is that instead of forwarding from the original domain that the email was sent from, you can instead ?resend? the email, e.g take the contents of the original email, put it into a new email and send it from a domain which will not fail SPF checks.

I think you will agree that the benefits far outway the negatives, especially as only a small percentage of domains and users forward mail so no doubt you now want to know how you can go about implementing your SPF record on your domain(s). Email Manual will be posting a guide tomorrow on how to create your SPF record and within a couple of days we will have a guide on how you can implement the SPF record on both BIND and Microsoft DNS servers, why not subscribe via twitter or our RSS feed to be notified of when these guides are available.