I remember a number of years ago when the idea of SPF, or Sender Policy Framework, was announced as a possible solution for the burgeoning problem of spam.

SPF proposed that a standard would be established which would allow recipients to determine if the sending server was authorized be the source of email purporting to be from a particular domain. This was done by creating a “policy” record in the domain’s DNS using a special comment record called a TXT record.

For instance, if I set up an Exchange server, I will assign that server’s IP address as authoritative for my domain. Once I have this set up, anyone else who uses SPF can tell if mail from my domain is really from someone that I work with. If they receive mail from some other server, say a spammer’s server or a computer compromised by a bot, they can choose to ignore it.

The implication of SPF, when implemented properly and fully, is that my server (and everyone’s else) should be able to reject incoming mail that is spoofing the return address of the sender. This can eliminate two types of spam:

Backscatter spam – This is spam designed to take advantage of servers that queue and return messages to invalid recipients – the spam is “returned” to the spoofed sender.

Spoofed spam – Messages purporting to be from a valid organization, such as the IRS or Google.

However, there are glaringly significant issues with SPF as a solution:

Null outcomes – A significant number of organizations don’t implement SPF in any way. This means that any filters that might have been implemented are ineffective. A number of organizations also implement SPF as a token gesture, so that they can have an SPF record. They simply say “our mail can come from anywhere.”

False negatives – This is a pretty lousy outcome of depending upon SPF for spam filtering. If a spammer wants to sell me Viagra, for instance, they ultimately want me to go to their website. This means that they can simply set up an SPF record for their domain, and send me mail with impunity. My server won’t reject their email based on SPF.

False positives – When I implement SPF on my server, I have taken on the job of enforcing another organization’s mailing policy. The consequence of this is that I can end up enforcing a policy which has been poorly implemented. What if, for instance, someone has a mobile phone on a network which does not allow SMTP messages to go out through servers other than their own? Then if their domain has an SPF record saying their mail can only come from their servers, I’ll reject messages that a real person is trying to send to one of my users.

So what is the bottom line? Most systems that implement SPF use it as a grading system. For instance, if I want to implement a system for filtering spam, I might use a number of indicators that lead me to believe that an incoming message may or may not be spam. An incoming message coming from a server that is indicated as valid, via the SPF record, can get graded a higher rating. But if we are going to use it as a means of determining whether or not to accept email, it doesn’t provide enough of an accurate data point to be of significant value.