Sender Policy Framework – SPF

4.1 Sender Policy Framework – SPF [RFC 7208]

Sender Policy Framework or SPF was developed from 2000 with publication as an experimental RFC 4408 in 2006 although widespread adoption has been slow. The basic principle is that the domain owner publishes details of mail servers that legitimately send Email on behalf of the domain via DNS text (TXT) records. The intent is that if a message is received from a server not included in these DNS records, then the receiving Email server can presume the message has not been sent by a server in use by the domain and take appropriate ‘counter-spam’ action.

Figure 1 – Processing of SPF check of received Email

Figure 1 – Processing of SPF check of received Email

The specification defines “intended actions” that the recipient Email server should take in the case of a message failing an SPF check, plus guidance as to whether the list of servers is exhaustive, simply advisory, that the check has no significance or even that any mail server can legitimately send Email for the domain. The ‘no significance’ (neutral) and ‘any server’ settings are somewhat academic to the principle of attempting to control spam described here.
This all seems pretty logical; the domain owner states the legitimate servers that should be sending mail on behalf of the domain and anything else can be safely considered spam; what could be simpler? Well nothing is ever that simple.

One of the impacts of introducing SPF, and in particular of introducing a ‘hard’ or exhaustive list of servers, is that if a user auto-forwards Email from one mailbox to another, the legitimate forwarded Email can then fail an SPF check at the second receiving mailbox. This is down to the way in which many auto-forwarders work by simply relaying the message on to the new address. This is good for the user who receives the message in the new (second) mailbox as if it has come direct from the original sender, meaning replies work and the message generally looks as it would have looked when viewed through mailbox 1. The problem though is that by relaying the message in this way, mailbox 1 is seen by mailbox 2 as being the sender of the original Email and on performing an SPF check, will detect that mail server 1 is not listed as a legitimate sender of Email for the original sending domain.

Consequently mailbox 2 is liable to treat the forwarded message as spam; which if your anti-spam controls are working as you want to them to operate for real spam, is to auto-delete or reject the message. The issue here is that mailbox 1 is acting as a relay, forwarding anything it receives to mailbox 2, and SPF is designed to detect and block mail from relays as this is a typical mechanism used by spammers. Consequently auto-forwarded Email can become ‘collateral damage’ in the war to control spam.

Figure 2 – The potential impact of SPF on auto-forwarded Email

Figure 2 – The potential impact of SPF on auto-forwarded Email

In part due to this problem, despite SPF defining an “intended action” a recipient should take in the case of a message failing an SPF check, these actions can often be watered-down by recipient ISPs who can be wary as to whether the domain owner ‘really meant it’ when their SPF record states a strict check and indicates deletion/rejection of failing messages.

Excepting these issues, how though would you implement SPF for a domain you operate?

SPF is implemented by DNS text (TXT) records. Your DNS zone is considered a trusted source of information about the domain and so a suitable location for general access to such authoritative information. This is a mechanism re-used by the other technical controls described later; each rely on your DNS as being under your control and so authoritative for the domain.

There are two type of SPF record which you should define:

  1. A domain-wide ‘legitimate mail server white list’ record which lists all valid mail servers that should be sending mail for your domain. See 4.1.1 Domain SPF record below
  2. A set of ‘per sending server’ records, one for each ‘HELO/EHLO names’ your servers use when sending mail. See 4.1.2 HELO/EHLO name records below


The idea of a ‘white list’ of legitimate mail servers is simple to grasp, but ‘HELO/EHLO names’ record maybe demands a little more explanation.

When a mail server sends mail to another mail server, it goes through an SMTP conversation. Have established a connection to the mail server to which it wishes to deliver mail, the sending server announces itself with a ‘HELO’ command. The later ‘extended SMTP’ changes this introduction to ‘EHLO’ indicating a desire to use extended SMTP, but is otherwise the same introduction step. So for instance, the sending mail server might say:


HELO smtp.example.com
Figure 3 – Example HELO name SPF record

The sending mail server is therefore announcing itself as being smtp.example.com.

It is this name (or names) used by your mail server that should be defined in an SPF record, one record per name used, as it provides the recipient mail server an opportunity to check whether this is a valid mail sending name. So if for instance, you have a set of four
sending mail servers announcing themselves as; smtp1 to smtp4 or mail1 to mail4, then there should be a corresponding SPF record for each of the four names in use as detailed in 4.1.2 HELO/EHLO name records below.

Continue reading ‘Example SPF records’ »