Sender Policy Framework (SPF) is a protocol designed to help combat forged email. It allows the owner of a domain to specify which hosts are authorized to send email from that domain. Full details can be found in RFC 7208.
Domain owners publish SPF records in the Domain Name System (DNS) as TXT records which list the IP addresses from which email is authorized to be sent. These records are examined when email receivers check to see if the server which sent an email is authorized by the domain owner to send email on behalf of the domain. What happens to failed matches depends upon the ‘all’ mechanism and its qualifier at the end of the record (more on that in a bit).
There are many reasons cyber criminals falsify emails, including phishing scams and spam. This can lead to the possible exposure of sensitive data or the blacklisting of your domain. Though SPF records cannot catch all spam, they act to dissuade would-be attackers and should be utilized in your domain’s security setup. For added security consider implementing DKIM and DMARC records in addition to the SPF records.
The following steps describe how an SPF record is created at http://manage.totaluptime.com.
To edit, enable/disable, or delete an SPF record, highlight it and select the respective action.
So how do you build an SPF record? The following steps will help you gather the necessary information and then put it all together.
This may include any of the following:
While it is important to use SPF records to authorize sending IP addresses, you may also want to consider creating SPF records for your non-sending domains to help prevent criminals spoofing mail from those domains.
**NOTE: SPF records have a character limit of 255 characters. If your SPF record exceeds this limit, then your mail may not be received by the receiving mail server depending on it’s policies.**
Now that you have built your SPF record you are ready to publish it through your DNS provider. For totaluptime.com record publishing, please follow the Creating an SPF Record steps above.
As stated previously, an SPF record is created in DNS as a TXT record comprised of a version string, mechanisms, and qualifiers. See the following example for the domain example.net.
TXT @ “v=spf1 a mx ip4:192.168.1.67 include:outlook.com ~all”
Let’s break down the above example by component.
Component | Description |
TXT | The DNS zone record type; SPF records are written as TXT records. |
@ | In a DNS file, the ‘@’ symbol represents the current domain. |
v=spf1 | This identifies the record as an SPF record utilizing SPF version 1. |
a | In the above example this will examine the example.net A record for a matching IP address. |
mx | In the above example this will examine the A records for each MX record in the example.net DNS zone. |
ip4:192.168.1.67 | If the sending IP address matches, this will pass. |
include:outlook.com | Authorizes mail to be sent from outlook.com on behalf of the domain. |
~all | Any tests which do not match the previous components will soft fail, flagging the email and accepting it. |
Below we detail the version string, mechanisms, and qualifiers which are most often used. Please note there are other available mechanisms, but they are out of the scope of this article.
Syntax | Description |
v=spf1 | This configures the record to use SPF version 1. All SPF records must begin with a version string to identify the TXT record as an SPF record. |
Mechanism | Description |
all | This mechanism always matches and should be placed at the very end of the SPF record. |
include | This mechanism specifies other authorized domains. |
a | This mechanism specifies all the IP addresses in the DNS A (or AAAA) record. It may be specified by either ‘a’ or ‘a:<A Record>’, such as ‘a:exchange.example.net.’ |
mx | This mechanism specifies all the A records for the domain’s MX record(s). |
Ip4 and ip6 | These mechanisms specify a single address or address range. If no mask is entered, a mask of /32 for IPv4 and /128 for IPv6 is assumed.
Examples: · Ip4:192.168.1.128/25 · Ip6:fe80::1 |
Qualifier | Description |
+ | Pass: the address passed the test and the email is accepted. If the mechanisms are not prefixed by a qualifier, the + is assumed. |
– | Hard fail: the address failed the test and the email is bounced. |
~ | Soft fail: the address failed the test and the email is accepted but flagged. |