Sender Policy Framework (SPF) is a system whereby special records – of the TXT type – are placed into the Domain Name System (DNS) to specify the IP addresses of all mail servers that are allowed to send email to the public internet, for that particular domain.
Receiving mail servers can look at an incoming email – from [email protected] for example – and then look up the SPF records for domain.com. If the IP address from which the email actually arrived is not in the list of authorised servers from the SPF records the receiving server looks at, it can be assumed that the email is not really from someone from within that domain.
Unfortunately, you cannot say that if an email fails an SPF check that it is DEFINITELY spam. It’s only an indication that it is MORE LIKELY to be spam.
Also unfortunate, is that SPF is not as widely adopted as would be useful. If every single domain name was forced to use SPF, and the administrators of each domain rigidly enforced policy to ensure that email is only sent via their authorised servers, SPF will stop spam dead. Completely.
So, is SPF worth implementing? For the most part, the answer is yes. If you want to give other servers on the internet the opportunity to verify that a particular email is from your domain, it’s the best currently available option.
The biggest problem is, not all RECEIVING email servers choose to do SPF checking on incoming mail. Because it’s not compulsory, SPF lacks the punch it would otherwise have.
Basically, everyone SHOULD use SPF. In particular, if your site is an e-commerce site, it would be responsible to add SPF records for your domain. Because e-commerce sites are more likely to fall prey to phishing attacks, it would be extremely useful to your users to offer this option to receiving servers, to help alleviate the world of phishing scams.
It is up to administrators everywhere to look at using SPF lookups on their mail servers to help end users identify spam. SPF is another string to the bow.