Terry Zink: Security Talk

Discussing Internet security in (mostly) plain English

Sender authentication part 12: Some examples of SPF

Sender authentication part 12: Some examples of SPF

  • Comments 5

Now that we've plowed our way through SPF, including the syntax (I can't believe I took the time to do it, but if I ever go into a university and have to teach it I guess I should know it), let's take a look at some real life examples of domains that publish SPF records and try to interpret them.

Example 1 - Frontbridge

Let's start with Frontbridge, the antispam company that Microsoft bought in July 2005. Their SPF record is the following:

"v=spf1 ip4: ip4: include:spf.frontbridge.com -all"

The version of SPF is 1.0, and the IPs that are permitted to send mail are, and then we have the SPF record spf.frontbridge.com.  The SPF record for spf.frontbridge.com is the following:

"v=spf1 include:spfa.frontbridge.com include:spfb.frontbridge.com -all"

Not content to make this example easy, we have another include directive.  Looking up the SPF records for spfa.frontbridge.com, we get the following:

"v=spf1 ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: -all"

For spfb.frontbridge.com:

"v=spf1 ip4: ip4: ip4: ip4: ip4: -all"

So, the only IPs permitted to send mail as frontbridge.com are the ones above.  If an IP is not in any of the above IPs, return a Hard Fail.


Example 2 - The Motley Fool

My next example is The Motley Fool, a financial website.  I've subscribed to The Motley Fool for a number of years and some of the articles are alright.  Their SPF record is below:

"v=spf1 a mx ip4: ip4: ip4: ip4: ip4: ~all"

This is simpler.  To interpret it, the version of SPF is 1.0.  The IPs allowed to send mail are the A-record, the MX-record, and all of the rest of the IPs that are mentioned.  The A-record of The Motley Fool is, the mx-records of fool.com are and  If the IP is in any of those ranges, return a Pass.  If not, return a Soft Fail.


Example 3 - Yahoo

The following is Yahoo's SPF record:

"  "

That's not a typo, Yahoo does not publish SPF records so there's nothing to authenticate.  Yahoo uses DomainKeys, which is another method of email authentication.  I guess they think that because it's such a good method they are not going to bother publishing SPF records (they need to support the home team and no one else).

That's one way of looking at.  Of course, the drawbacks to this would be that spam filtering services that don't use DomainKeys to authenticate but do use SPF will treat any email from Yahoo as suspicious, since spammers (historically) have spoofed Yahoo.


Example 4 - Gmail

Our next example is Gmail.  The SPF record for Gmail is the following:

"v=spf1 redirect=_spf.google.com"

I didn't look into this modifier in my explanation of the syntax of SPF, but it means that the SPF record for _spf.google.com replaces the record for gmail.com.  For _spf.google.com:

"v=spf1 ip4: ip4: ip4: ip4: ip4: ip4: ip4: ?all"

Again, this one is relatively easy to interpret.  If the transmitting IP is claiming to be coming from Gmail, the IP must be within any of the ranges mentioned above.  But what is interesting is if it doesn't, the result is SPF Neutral.  What's up with that?  Why wouldn't Google explicitly state which IPs they authorize to transmit mail?  While I don't know for sure, I think it is because Google also uses DomainKeys, which is another form of email authentication.  Still, it's a little annoying that they would be so ambiguous as to be Neutral, rather than a Soft Fail.  I could see it if they didn't explicitly control google.com, but they do.  So why the need for ambiguity?

It's only speculation on my part.  There's probably something simple I am overlooking.


Example 5 - Hotmail

Finally, let's have a look at Hotmail. 

"v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all"

The version of SPF is 1.0.  It has the include directive for spf-[abcd].hotmail.com, which means that all of those domains are searched for a match.  If no match is found among them, return a Soft Fail.

Let's look up the SPF record for spf-a.hotmail.com:

"v=spf1 ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ~all"

Obviously, I picked a winner here by selecting an example with a huge number of IPs.  Let's interpret this; the version of SPF is 1.0, the IPs permitted to send mail for spf-a.hotmail.com are - (if I did my math right), expanding all the way to the end of range.  If the sending IP is not in this range, return a Soft Fail.  However, we don't return a Soft Fail because of spf-[abcd].hotmail.com, we return it because the SPF record for hotmail.com says to return the Soft Fail.

Leave a Comment
  • Please add 1 and 2 and type the answer here:
  • Post
  • Terry, three questions.

    1. Why would you use the "redirect=" directive over the "include:" directive? They seem to perform a similar function.

    2. Why so many layers for Frontbridge? Why not just create "spf.frontbridge.com" containing all allowed IP ranges and use an "include:" directive where applicable?

    3. The Motley Fool lists "a" and "mx" but then lists the resolved IPs with "ipv4" directives. I had thought using ipv4 directives was more efficient as it saved additional DNS lookups.

    Great series of posts. Really enjoyed them!

  • I'm not familiar enough with setting up SPF records to understand the motivation that a particular domain might use, but I'll take a stab at it.  

    1. Redirect says to substitute the redirected SPF record SPF record for the domain's SPF record.  Someone might use this when they have control over both domains.

    An include directive uses the included domain's valid SPF records but specifies a different action if no match is found.  Someone might use it if they want to specify different failure actions or they don't control the second domain.

    2. Why so many layers for Frontbridge?  Possibly, the extra IPs were added hastily rather than for spf.frontbridge.com.

    3. You're certainly right about the a and mx records for The Motley Fool.  In fact, OpenSPF even recommends just using IPv4 SPF records.  In fact, the mx record is within the IPv4 directives they list.  I'm not sure why they did that.

  • I've been enjoying reading your posts on SPF.  I did a poll of my own (see my link), regarding SPF use within Commercial Banks.  It seems like a no brainer, to help prevent phishing, but still many banks don't publish an SPF record, especially outside of the U.S..

  • Nice research, Brian.  You are right about SPF policies, it does seem like a no-brainer; I can only think of a couple reasons why they wouldn't set them up:

    1. Their IT depts are not familiar with the standard.

    2. They are using something other than SPF for email authentication (DomainKeys?).

  • Thank you guys, it is the BEST article I have seen so far aboutt the SPF.  I am new to this idea and still learning.  God work guys, keep it coming...

Page 1 of 1 (5 items)