Common errors in SPF records

The other day I was asked to come up with some common errors that we see when people set up SPF records as we want to start notifying our customers when they have these types of errors. I thought it would be a good idea to make this public and add to it as necessary.

1. You have too many DNS lookups

SPF specifies a maximum number of 10 DNS lookups (e.g., nested includes, A-record resolution, MX-record resolution, PTR record resolution, etc. are greater than 10). I talk about how to get around this here:

Most verifiers, if they can verify you before hitting the 10 DNS lookup limit, will pass if you haven’t hit 10 up to that point. But go over and this will generate a PermError.

2. Too many SPF records in DNS

This occurs when someone meant to add more IPs or 3rd parties to their SPF record and created a second TXT record instead of including them all into the first one: IN TXT "v=spf1 –all" IN TXT "v=spf1 ip4: –all"

Whereas it should be this: IN TXT "v=spf1 ip4: –all"

If this occurs, SPF should return a PermError. We here at Office 365 will cut you some slack and interpret two SPF records as a single one; that is, we detect your probable intent even though you didn’t do it correctly. Most other receivers are not nearly as forgiving.

3. Duplication of what you need for Office 365 to work

You only need to have in your SPF record, you don’t need any of the following:

While SPF still works if you include any of the others, you will get unnecessarily closer to the 10 DNS lookup limit (this prevents you from adding much more 3rd party services to send on your behalf).

As a matter of fact, if you have any of those in your SPF record, you should replace them with

4. Forgetting to include an ip4: and instead putting ip:

For example: IN TXT "v=spf1 ip4: ip4: ip: –all"

Office 365 will cut you some slack and interpret an ip: as ip4:. Other services aren’t quite so forgiving and may generate a PermError.

5. Not properly formatting the double quotes

You can put additional double quotes into the SPF record as long as you put spaces in the correct places: IN TXT "v=spf1" "" "ip4:" "" "–all"

The above is created by someone who is trying to add additional 3rd parties to their SPF record by putting them in double quotes. However, this concatenates the record so it gets treated as this: IN TXT "–all"

Email receivers will treat this as you not having an SPF record at all.

It should be this (better to not include any quotes at all because you are using up characters in your SPF record, and you only have 255 to spend): IN TXT "v=spf1" "" " ip4:" "" " –all"

6. Exceeding 255 characters in an SPF record

If you are going over 255 characters, it should be separated by a space and max of two components: IN TXT "v=spf1 <bunch of others> ip4: " "ip4: –all"

If you go over 255 characters, I think most receivers will return a PermError but it varies by receiver.

7. Forgetting to include key parts of the record indicating that it is an SPF record

These are all incorrect: IN TXT " ip4: –all" IN TXT "v=spf1 ip4:" IN TXT " ip4:"

The first one lacks v=spf1, the second does not have a failure policy, and the last one lacks both.

If you do this, most receivers will either return a PermError or will treat it as if there is no SPF record.

8. Having a failure policy of +all

It’s okay to have any of the following policies: -all, ~all, ?all. Don’t do +all: IN TXT "v=spf1 ip4: +all"

This allows the entire world to send email as you. I was talking to another (very) large receiver at M3AAWG this past week and we’re talking about tightening up this behavior by rejecting in SMTP if you have a +all in your SPF record.

So don’t do it.

9. Having large IP ranges in your SPF record

IP ranges larger than /16 usually are wider than you need: IN TXT "v=spf1 ip4: –all"

That allows far too many IPs to send on your behalf. This is another pattern that I was talking about with the large receiver at M3AAWG that we are looking to start rejecting in SMTP.

10. Including a PTR in your SPF record

This one… I am not so strict about: IN TXT "v=spf1 ptr –all"

The SPF spec says not to do this and it is deprecated, but I can see the rationale for still using it. So while I recommend not to use it, I’m not so sure I’d want to reject on it.

Those are the most common errors that we see today, and how they are treated. As I think of or discover more, I will add to the list.

To test SPF records, I use the following two websites:

SPF Record Testing Tools:


Other than some Perl and shell scripts I wrote internally, that’s all I basically use.

Comments (4)

  1. Grzegorz Wierzbicki says:

    What you actually need for Office 365 is this:

    It includes as nested lookup.…/2954799

    I know this one is changing with the new email model for Sharepoint but it is still needed today.…/3134824

  2. tzink says:

    @Grzegorz Wierzbicki

    You should only put into your SPF record **IF** you use Sharepoint Online. If not, put You shouldn't add services you don't use.

  3. Hi Terry, Return Path has an SPF Record Testing Tool as well at Cheers.

  4. Hicsy says:

    Hey Microsoft – currently you burn 3 of your customers’ MAXIMUM 10 DNS lookups with your nested-lookup! Salesforce used to burn 4 lookups, and they solved that by using a macro. This has another plus: it’s much easier to manage your complex listings via A-Records.

    see here:

Skip to main content