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.

  1. An SPF policy (or record) must be published for a domain. 

  2. 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:

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:

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.

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

Did this answer your question?