SPF stands for "Sender Policy Framework". SPF records allow you to designate what sources are authorized to send mail for your domain. Receiving servers that verify the SPF information in TXT records could reject messages from sources that are unauthorized before accepting the body of the email.
In order for SPF to function as intended two main tasks have to be completed.
- An SPF policy (or record) must be published for a domain.
- The receiving server must use standard DNS queries. It then reads the SPF information and has an action upon the results.
Crafting an SPF record
An SPF record is made up of 3 main parts. I am going to list a simple record below and we will break it down into its parts.
v=spf1 ip4:8.43.59.66 a -all
For this example I will be using our public IP.
For the first part we designate the spf version we will be using for this record.
v=spf1
Currently this is a non changing portion of the record.
For more details on the nuts and bolts of spf1 you can view the rfc document here.
The second portion of the record is the mechanism. The mechanism allows us to designate an address or variable that we can then assign qualifiers to.
ip4:8.43.59.66 a
The ip4 designates the sender's IP address.
The a states that if the domain for which this record is created resolves to the specified ip4 then it will pass.
There are eight "mechanisms" defined for SPF:
| ALL | Passes always: used for a default result. This will allow anything |
| A | If the domain name has an A or AAAA record that can be resolved to the authorized origin it will pass |
| IP4 | If the origin matches this IP/IP range then it will pass |
| IP6 |
If the origin matches this IP/IP range then it will pass |
| MX | If the domain name has an MX record that resolves to the authorized origin's address it will pass |
| PTR | This mechanism is deprecated and shouldn't be used. |
| Exists | If the domain name resolves (to any address) it will pass. This is rarely used. Can be used in conjunction with DNS Blacklist queries. |
| Include | Refers to another domain's SPF, if the message passes their policy it passes this mechanism. If it fails, it will not cause the SPF to fail but will continue processing the rest of the SPF record. |
The final piece of the puzzle is the Qualifiers. We have discussed what will allow a message to pass. We have been using qualifiers for the initial mechanisms already. when we state ip4: we are saying the same as +ip4 or if the senders address = this IP then it passes.
-all
This indicates that ALL messages fails unless it has met the requirements of the other + (or PASS) qualifiers.
The 4 mechanism qualifiers are as follows:
| + | This is a PASS result. This does not have to specified, it is implied. |
| ? | This generates a NEUTRAL resulted; it is read as no policy |
| ~ | This is a SOFTFAIL, this is commonly used when initially creating an SPF as a debugging tool. Messages that generate a SOFTFAIL are generally accepted but will be tagged. This makes it easier to find where you need to modify the SPF record. |
| - | This is a FAIL. This mail will get rejected unless otherwise designated with a pass qualifier. |
Additional Notes
I have included below additional notes and general information in regards to SPF.
- SPF does not allow for Plain Mail Forwarding. If all of the following occur the forward will likely fail to pass
- The forwarder does not rewrite the Return-Path
- The next hop does not whitelist the forwarder
- This hop checks SPF
- All SPF records should initially be created with softfail's until the user is certain of the results. Once they are certain they can take a harder stand and initiate a Fail policy.
Helpful Tools
http://www.kitterman.com/spf/validate.html - SPF validator (indepth, can test the spf records and check they are correct)
https://mxtoolbox.com/spf.aspx - MXToolbox provides a large number of tools for email.
HELO tests (pulled from wikipedia.org links below)
For an empty Return-Path as used in error messages and other auto-replies, an SPF check of the HELO-identity is mandatory.
With a bogus HELO identity the result NONE would not help, but for valid host names SPF also protects the HELO identity. This SPF feature was always supported as an option for receivers, and later SPF drafts including the final specification recommend to check the HELO always.
This allows receivers to white list sending mailers based on a HELO PASS, or to reject all mails after a HELO FAIL. It can also be used in reputation systems (any white or black list is a simple case of a reputation system).
Sources
https://en.wikipedia.org/wiki/Sender_Policy_Framework
http://www.rfc-editor.org/rfc/rfc7208.txt
http://www.openspf.org/Project_Overview
http://www.kitterman.com/spf/validate.html