Sender authentication part 12: Some examples of SPF

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: -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  The SPF record for is the following:

"v=spf1 -all"

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

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


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

So, the only IPs permitted to send mail as 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 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:


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

"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, 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 ~all"

The version of SPF is 1.0.  It has the include directive for spf-[abcd], 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

"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 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], we return it because the SPF record for says to return the Soft Fail.

Comments (5)
  1. Mike says:

    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 "" 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!

  2. tzink says:

    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

    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.

  3. Brian Egge says:

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

  4. tzink says:

    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?).

  5. Salman says:

    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…

Comments are closed.

Skip to main content