How-to: Configure and use Sender Policy Framework

We had a curious phenomena until recently in which email generated by the client's newly launched website was being rejected as spam by some members of its partner network.

After a diagnosis of the mail formatting, the suggestion was that SPF needed to be configured. You may realise that SPF is not a quality measure for sunscreen...

SPF stands for Sender Policy Framework. It is an email validation system designed to prevent email spam by detecting email spoofing, a common vulnerability, by verifying sender IP addresses. SPF allows administrators to specify which hosts are allowed to send mail under a given domain by creating a specific SPF record. So far, so technical...

Domain owners identify their authorised mail servers to the domain name service in DNS records. Inbound mail servers use the DNS to check that mail from a given domain is being sent by a host authorised by the outbound domain's administrators. SMTP receivers verify the sender address against this information, and can distinguish authentic messages from forgeries before any message content is transmitted.

What is attractive is that SPF is implemented at the level of outbound DNS TXT records and can be queried by the inbound SMTP server. Whilst you can find detailed information on SPF record sytax at this is a quick example of the basic SPF TXT record you could use.

We'll look at this on Plesk, but as long as you can find the DNS records section of your domain, this works equally well for other server panels.

Using the Plesk Control Panel, we log in as admin and select the domain for which SPF is to be configured.

From there, selecting  Websites and domains displayed the records configured for the particular domain URL. If there is no TXT records, you may need to select Add Record to, errm, add a record. You can also select an existing record to edit it.

DNS TXT records have the following format: IN TXT "v=spf1 spf_string"

  • spf1 is the SPF version, and 
  • spf_string lists the combination of the allowed options, for example:
    "a, ptr, mx, ip4, include, all"
Here, all is a closing argument and must be placed at the end.

Each option may be prefixed according to the type of response required when processing messages:  
- fail (message is rejected)  
~ softfail (message is passed with warning)  
+ pass (message is passed - the default prefix value)
? neutral

The simplest (and most common) SPF record will be: IN TXT "v=spf1 mx -all" 

This means that mail from can be sent only from the parent server (parent MX record).

Other servers may be configured to  send mail as, which can be set using 'arguments' to the a:, mx:, ip4:, and ptr: options.

mx: takes domain names and approves all the MX servers of these domains, for example:
"v=spf1 a mx -all"

Mail can be sent from the parent domain MX and additionally from server which is an 'authorised' sender.

A more specific example:  10800 IN   TXT  "v=spf1 a mx ptr ip4: -all" 

In this example only the following hosts are authorised to send email:
  • all the domain's A records
  • all the domain's MX records
  • the domain PTR record
  • the hosting server IP address and
  • the MX record

What do I know?
If you're not sure what is currently authorised and can't go straight to your MX records, there are a number of online tools for checking what is publicly configured for a given domain.

For example, MXToolbox does exactly what its name suggests. It will list all MX records for a domain in priority order. The MX lookup is done directly against the domain's authoritative name server, so changes to MX Records should show up instantly. It has further diagnostics, which will connect to the mail server, verify reverse DNS records, perform a simple Open Relay check and measure response time performance. You may also check each MX record (IP Address) against 105 DNS based blacklists. RC