SPF Email Authentication: Explained in Plain English
What is Sender Policy Framework (SPF)?
Sender Policy Framework (SPF) is an open email authentication standard used to prevent sender address forgery, allowing senders to publish a list of IP addresses, or server names that are authorized to send on their behalf. SPF authenticates the domain used in the “envelope” or return-path email address. This address is used during the transport of the message (from mail server to mail server,) and is primarily used to “bounce” or return undeliverable mail back to the sender. It is an internal address and is typically not displayed by mail programs.
How SPF Records Work
A sender will publish an SPF record for a given domain. This record is a DNS text record that uses different “mechanisms” to identify what hosts are authorized to send on behalf of that domain. These mechanisms include: IP addresses, A records, MX records, and PTR records. SPF records can also include other SPF records as mechanisms to identify authorized hosts.
The following is an example of an SPF record:
example.com. TXT “v=spf1 a mx ip4:192.168.1.1 include:example.net –all”
| Item | Description |
|---|---|
| example.com | The sending domain that is publishing the SPF record |
| TXT | Specifies that this is a DNS text record |
| v=spf1 | Tag that specifies that the text record is using SPF |
| a | Specifies that the A record of example.com is an authorized host to send on behalf of example.com |
| mx | Specifies that the MX record of example.com is an authorized host to send on behalf of example.com |
| ip4:1.2.3.4 | Specifies that the IP address 1.2.3.4 is authorized to send on behalf of example.com |
| include:example.net | Specifies that the mechanisms found in the SPF record of example.net can also be authorized to send on behalf of example.com |
| -all | Specifies that the hosts included in the SPF record are the only hosts allowed to send on behalf of example.com – all other hosts are not authorized |
A key part of an SPF record is the “all” mechanism. It is used as the rightmost mechanism, and is also what determines how complete the record is. In the above example, a dash (-) “qualifier” is used to signify that only the hosts included in the respective SPF record are authorized for that domain. There are other qualifiers that can be used as well. For example:
To signify that there are other hosts that possibly can send, or are in transition to do so on behalf of the domain, the SPF record would be terminated with “~all”.
To signify that it is not known if any of the hosts are authorized to send on behalf of the domain, the SPF record would be terminated with “?all”.
Authenticating SPF Records
ISPs that authenticate inbound email using the SPF record will check the mechanisms in order until one is found that authenticates the domain successfully. If a mechanism is found that passes, the ISP can then accept the message for delivery. If a mechanism is found that is either not valid, or not definitive in what hosts are authorized to send on behalf the respective domain, the ISP can opt to either accept the message but mark as invalid, or to not deliver the message at all. The validity of the message can be determined through a result outcome that is recorded in the “Authentication Results” header of the email. A few common
results are as follows:
• spf=pass
• spf=temperror
• spf=fail
Sender ID Framework (Sender ID)
Very similar to SPF version 1 is SPF 2.0, more commonly known as Sender ID. Sender ID works on the same principles as SPF, with the exception that it not only has the capability to authenticate the domain used for the “envelope” email address, but also can authenticate the domain used in the “from” or “sender” header email address. This is the address that is typically visible in most mail programs.
Creating and Publishing Sender ID Records
The original methodology of the Sender ID standard (as defined in the RFC document) is to create and publish a Sender ID record very similar to creating an SPF record. The only difference is in the tag that is used at the beginning of the text record. Whereas SPF only uses the “v=spf1” tag, Sender ID uses “spf2.0/pra”, “spf2.0/mfrom”, or “spf2.0/mfrom,pra”, depending on what identities are being validated. With the exception of this first tag, the remainder of the Sender ID record uses the same methodology as SPF version 1.
It is interesting to note that while there has been no official change in documentation, it appears that Microsoft has adapted to and recommends using the “v=spf1” tag, as opposed to using “spf2.0”.
Authenticating Sender ID Records
Authentication using Sender ID is virtually the same as with SPF authentication. The only difference is that, as described above, Sender ID verifies the domain used in the “from” or “sender” header email address – not the “envelope” email address.
Email Authentication
SPF is just one small part of the greater email authentication topic. To learn more about the bigger email authentication picture, including DKIM and DMARC, check out the SocktetLabs Email Authentication Hub!
