SPF: Sunblock for spam

Steve Kennedy says that Sender Policy Framework (SPF) may be an answer to ridding the world of spam - or at least a vast amount of it.

In order to understand SPF a basic understanding of email is required as it's tied to the domain name system (DNS) and simple mail transfer protocol (SMTP). Unfortunately changes have to be made to both systems to implement SPF.

DNS, the backbone of the internet

One of the DNS's main uses is to map names to internet addresses so that rather than having to remember something like we can use the much more friendly www.gbnet.net.

DNS also stores information on how mail should be routed for domains using MX (Mail eXchanger) records. MX records are just numbers, with the lowest number having highest priority.

A domain (such as gbnet.net) may have multiple MX records, which allow mail to be delivered to several different systems and still arrive at the correct destination.

There are systems that are purely back-up MX machines which do nothing else but hold on to mail until it can be delivered to its final destination.

This works very well for receiving mail, but says nothing about sending mail.

SMTP hop here, hop there

Almost every mail client will have an SMTP client built in, which is how it sends mail to another system. However most clients are configured to 'talk' to a single mail server and then the mail server will do the clever stuff of looking up MX records and delivering the email.

But basic SMTP has a flaw - there's no authentication - so anyone can connect their mail client and the mail server will then go and send the mail on to the recipients.

Things have slowly changed and people operating mail servers generally only allow them to be used by the people that should be using them, so spammers can no longer randomly connect to a mail server and merrily inject spam.

Extensions to SMTP such as SMTP AUTH have also been introduced, which makes the mail client authenticate before mail can be sent.

However if a spammer runs their own mail server they can set the address they are sending from and the mail server will send it out.

Many ISP mail servers will also allow their customers to set their sending address to anything and send the mail out, so if a customer machine is compromised by a virus or trojan and is set to send out reams of spam, the ISP is almost powerless to stop it.


SPF is an addition to the domain records for a particular domain that, like MX records, tell systems how to deliver mail to that domain and where mail from that domain should be coming from.

Most ISPs have particular systems that send out mail and these are listed in the SPF records. If mail is forged and sent from a system not in the SPF record then the receiving system can look-up where the mail came from and if it isn't listed ascertain it's likely to be spam.

It means that every system that receives mail has to implement some kind of SPF look-up mechanism into the mail server.

SPF isn't the complete solution, as a spammer can still use a valid domain, associate that domain with valid SPF records and send out email, but it's very likely that domain will quickly be flagged as a spam domain and be blocked.

Where SPF still has problems is for mail forwarding, where a domain is hosted somewhere other than the ISP, and  they forward the email for onward delivery to the customer.

When the customer sends mail out, they set their address to the forwarding name and send it through their ISP.

Here the customer has to know the systems that the ISP will use, or the SPF records won't be there or will be wrong, which means remote systems won't accept mail from that domain.

Other SPF-like systems

Microsoft has modified SPF and called it CallerID for email (now SenderID Framework) but, although a good idea, MS has retained ownership of it so many are resistant to using it in case MS introduces licensing at some point.

Yahoo also has a system called DomainKeys that utilizes public key infrastructure where the injecting system signs the email using its private key and the public key is stored in DNS.

Further reading

September 2005

Blueprint for Cyber Security

Our vision is a world properly protected from cyber threat. This blueprint sets out how we can deliver that solution, starting in health and care.