SPF Records

 

An SPF record is short for Sender Policy Framework, and it is an anti-spam technique that maps a domain to a sending IP using rDNS (reverse DNS).  If a recipient server is configured to perform an SPF check as part of its spam filtering process, the IP contained in the SPF record is compared to the sending IP of every email.  If it matches, the email is considered to be legitimate.  If it doesn’t match, the email is considered to be spam.  To configure an SPF record for an email domain, the sending IP would be saved in the domain’s TXT record in this basic format:

“v=spf1 ip4:<insert WAN IP here> -all”

The example above would be used if a single server using a single WAN IP is used to send all email for the entire organization.  I say all email because situations often arise where a single server organization uses a company to send email on their behalf such as Constant Contact, Salesforce, etc.  In these situations, the email is sent as the organization’s email domain, but from servers external to the organization.  Because of this, the external IPs must be added to the email domain’s SPF record or any email sent on behalf of the organization may be flagged as spam.  The IPs can be added one at a time in the format above, but in the case of Salesforce, the number of IPs needed would quickly reach the 256 character limit for SPF records.  To work around this, a recursive addition can be made.  For the sake of this example, the WAN IP of 74.117.225.98 will be used for the Exchange server:

“v=spf1 ip4:74.117.225.98 include:_spf.salesforce.com –all”

The addition of _spf.salesforce.com indicates a separate SPF query must be made as demonstrated here using nslookup:

If we copy the results and break the entries down into separate lines, we end up with:

"v=spf1
include:_mtablock1.salesforce.com
ip4:136.146.208.16/28
ip4:136.146.210.16/28
ip4:136.147.62.224/28
ip4:136.147.46.224/28
ip4:85.222.130.224/28
~all"

The recursive query returned 5 CIDR ranges of IPs and yet another recursive SPF record.  Querying the second recursive record of _mtablock1.salesforce.com using nslookup yields the following:

 

Broken down it looks like this:

"v=spf1
ip4:96.43.144.64/28
ip4:96.43.147.64/28
ip4:96.43.148.64/28
ip4:96.43.151.64/28
ip4:96.43.152.64/27
ip4:96.43.153.64/27
ip4:182.50.78.64/28
ip4:204.14.232.64/28
ip4:204.14.234.64/28
ip4:204.14.238.0/27
ip4:136.146.128.64/27
~all"


If we combined both sets of CIDR ranges, we would be left with the following IPs:

136.146.208.16/28
136.146.210.16/28
136.147.62.224/28
136.147.46.224/28
85.222.130.224/28
96.43.144.64/28
96.43.147.64/28
96.43.148.64/28
96.43.151.64/28
96.43.152.64/27
96.43.153.64/27
182.50.78.64/28
204.14.232.64/28
204.14.234.64/28
204.14.238.0/27
136.146.128.64/27


Combine these with the original sending IP for the email domain in question, and we now have a complete SPF record. 

Additional information regarding SPF records can be found here - https://support.microsoft.com/en-us/kb/2640313

A great tool used to verify the syntax validity of an SPF record can be found here - http://www.kitterman.com/spf/validate.html