SPF is an email authentication mechanism designed to fight email spoofing and phishing attacks (to understand phishing attacks please refer to this post). SPF is defined in RFC 7208.
The protection of your outbound email is implemented by configuring a TXT record in your public DNS which lists the servers that are allowed to send email from your mail domain. Nothing is configured on the mail server itself.
SPF is relatively easy to implement and maintain and is widely adopted. However, it only protects the RFC5321.MailFrom address. To protect the RFC5322.From address, the one seen by users in their mail client, you need to implement DKIM.
To protect your users from inbound mail spoofing you should include SPF checking as one of many elements in a broad protection suite.
SPF Processing
When your outbound email is delivered the receiving side will check that the mail is coming from a server you have authorized in your SPF record in DNS. Specifically, the receiving server will do a DNS lookup on the domain used in the RFC5321.MailFrom address in the email envelope header. The matching rule in the SPF record is evaluated to determine if the sending servers IP address is allowed to send email for the domain name used in the RFC5321.MailFrom attribute of the email.
The following diagram illustrates how SPF processing takes place. The mail admin of royalty.dk has implemented an SPF record and now sends an email to a recipient in the observatory.dk domain.
- The sending server initiates an SMTP connection and states the sending mail address (RFC5321.MailFrom) as “frederik@royalty.dk”
- The receiving mail server performs a DNS lookup on royalty.dk to see if the IP address 1.2.3.4 is authorized to send emails from royalty.dk
In this case mail is delivered successfully to the recipient. Had the sending server not been in the SPF record the spam probability score would have increased and (depending on other factors) could end up in the spam filter.
SPF Record
The main components of the SPF record are the version tag (“v”), the mechanism and the qualifier.
The version tag is mandatory and is always set to 1:
The mechanism is one or more matching rules that are compared to the IP address of the sending mail server. The following mechanisms can be used in any combination in your SPF record:
SPF Mechanisms
| Mechanism | Description | Sample Value |
|---|---|---|
| a | Matches if the senders domain name resolved as A or AAAA record matches the senders IP address | v=spf1 a -all |
| ip4 | Matches if the ip (host or subnet) matches the senders IP address | v=spf1 ip4:198.23.187.0/24 ~all |
| ip6 | Matches if the ip (host or subnet) matches the senders IP address | v=spf1 ip6:2001:db8::cd30 -all |
| mx | Matches if any of the mx records of the sending domain matches the senders ip | v=spf1 mx -all |
| ptr | checks if reverse lookup on senders ip matches senders domain name (do not use) | v=spf1 ptr ~all |
| exists | complex arbitrary domain name lookup (rarely used) | exists:%{ir}.%{l1r+-}._spf.%{d} -all |
| include | includes the policy of another domain in the processing | v=spf1 include:royalty.se -all |
| all | Matches everything, used as rightmost mechanism to provide a default | v=spf1 ip4:1.2.3.4 ~all |
The qualifier informs the recipient evaluating the SPF record what action should be taken for a mechanism (matching rule). The following qualifiers can be used for each mechanism:
SPF Qualifiers
| Qualifier | Name | Description |
|---|---|---|
| + | Pass | The server matching this filter is allowed to send on behalf of the domain |
| - | Fail | The server matching this filter is not allowed to send on behalf of the domain (solid fail statement) |
| ~ | Softfail | The server matching this filter is "probably not allowed" to send on behalf of the domain (weak fail statement) |
| ? | Neutral | Unknown if the matching server is allowed to send - indicates test implementation |
The Pass qualifier (+) is implicit: If no other qualifier is used then Pass is assumed. This means the following two SPF records are identical:
The “all” mechanism must be the final mechanism in your SPF record. The qualifier of the “all” mechanism decides what happens when the sending IP doesn’t have a match with any other mechanism in the SPF record:
- ?all instructs recipients to take no action on your SPF record and is used while testing
- ~all instructs recipients to increase the emails spam score rating (but in some cases the sender might be valid even without a matching rule)
- -all instructs recipients to discard the message as you are sure to have listed all sending mail servers in the SPF record
SPF Record Configuration and Validation
For a safe and solid implementation of SPF consider the following:
- If you are sending email out via an external relay or if you’re using cloud mail refer to the provider’s SPF record using the “include” mechanism in your own SPF record (don’t copy their record, it may change)
- If you have several sending mail servers it’s better to include their subnet instead of individual servers – new servers in the subnet will be valid when you forget to update your SPF record
- Start with ?all or ~all to avoid interrupting your mail delivery in case of configuration errors
- Verify your SPF syntax before publishing it using an online SPF validator
- Use DMARC to verify your SPF configuration (learn how)
- Move to the safer “fail” setting (-all) when SPF has been implemented and validated
Once you have securely implemented SPF it’s time to move on with DKIM and DMARC.