If you’re relying on consistent email delivery, you absolutely must have email authentication standards like sender policy framework (SPF) for your domain. We’ll walk you through what is an SPF record, what they look like and how they work.
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 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.
As of 2024, Google and Yahoo require another email authentication standard, DMARC, which cannot be published successfully without a working SPF record. Since these two mailbox providers (MBPs) are amongst the most used inboxes, an incorrect or missing SPF record could spell disaster for you.
How SPF Records Work
A sender will publish an SPF record for a given domain. This record is a DNS text record using 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 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 the record’s completeness.
In the above example, a dash (-) qualifier is used to signify only the hosts included in the respective record are authorized for that domain. There are other qualifiers that can be used as well.
For example:
- To signify 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 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
MBPs authenticating inbound email using the SPF record will check the mechanisms in order until one is found that authenticates the domain successfully. If a passing mechanism is found, the MBP can then accept the message for delivery. If a invalid mechanism is found, or a mechanism is not definitive in what hosts are authorized to send on behalf the respective domain, the MBP 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 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)
There is also SPF 2.0, more commonly known as Sender ID.
Sender ID uses the same principles as SPF, with the exception 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, which is typically visible in most mail clients.
Creating and Publishing Sender ID Records
The original methodology of the Sender ID standard 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.
Where 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
The only difference between Sender ID authentication and SPF authentication is that Sender ID verifies the domain used in the “from” or “sender” header email address rather than the envelope email address.
SPF Records Are Only One Piece of the Authentication Puzzle
Email authentication is a broad, but very important, concept in email. With multiple standards, differing levels of strictness, and evolving best practices, it’s critical for email senders to be up-to-date and knowledgable about authentication.
SocketLabs Email makes setting up authentication on your domains super simple, and we also have tools to assist you in creating and installing more complex standards like DMARC. You can start using SocketLabs Email for a free trial now. Or, if you need more help, you can always let us know.
