skitch.png

Creating Nested SPF Entries

John_M
Marketo Employee
Marketo Employee

If you're setting up Marketo you're no doubt familiar with how to set up SPF and DKIM to ensure higher deliverability rates, but did you know that there is a limit of 255 characters in an DNS entry, and you'd have to span DNS entries to have an SPF entry longer than 255?

so, if you have a TON of domains you want to include in your SPF.. how do you do that? Excellent Question. In short you're able to nest them within the top level domain. I've enclosed an example below, blurring the domains and IP's to protect the innocent.

In order to see if SPF is set up, head over to www.mxtoolbox.com and type in the domain. For example, type in "Marketo.com" and you'll see that Marketo allows MArketo to send emails on behalf of Marketo. Not surpriusing, Marketo has always been a great customer of Marketo. Again, I'm blurring everything not related to the discussion at hand.

skitch.png

So, here's how it looks when you NEST entries.

skitch-1.png

the top level SPF entry.

In this case, the mktomail.com include is in spf-c, so if we run the MXTools query on _spf-c.company.com (name redacted!) youll see this

skitch-2.png

Meaning that all the sub entries will be added to the list of SPF entries.

6657
12
12 Comments
SanfordWhiteman
Level 10 - Community Moderator

John, there's a not a limit of 255 characters in an SPF TXT record. There's a limit of 255 characters in a single string within a TXT record. You don't need to use includes to make longer records (in fact, since there is a hard limitation on the number of DNS lookups, having an include when you don't need it wastes lookups and can potentially break the record entirely).

The proper way to create long SPF records is to have multiple strings.

     "255_char_string_1" "255_char_string_2"

is a single, valid TXT record.

Casey_Grimes
Level 10

Additionally, I think it's important to point out that there is a limit of 10 entries that you can nest in your SPF entries—it's not common to see that many records, but it's worth considering.

SanfordWhiteman
Level 10 - Community Moderator

Yeah, that's what I was alluding to when I mentioned the hard limitation on DNS lookups.  But there isn't actually a limit on includes: since your record can only result in 10 recursive lookups across all mechanisms, that implicitly means no one mechanism can result in more than 10.

If you had all includes you could have 10, but only if those includes did not result in additional lookups (they'd have to only have ip4/ip6/exp mechanisms).

There's also the additional wrinkle that the 10 lookups is a dynamic cap and isn't supposed to prevent use of the record. In other words, if you have 11 includes but a server gets a match on the 10th one, you're still good.  If a server starts checking the 11th one, it should return a PERMERROR (and will never get to a -all FAIL if that's next). 

SanfordWhiteman
Level 10 - Community Moderator

John, I count 11 lookups in Marketo's own record, making it an unfortunate example of how the include mechanism can bite you hard. In this case it isn't you guys arbitrarily splitting your record, but you depend on other providers who have split theirs without caring how that bubbles up to the 10-lookup limit.

dig +short @4.2.2.1 marketo.com txt

"v=spf1 ip4:96.43.144.64/31 ip4:96.43.148.64/31 ip4:182.50.78.64/28 ip4:204.14.232.64/28

ip4:204.14.234.64/28 include:_spf.salesforce.com include:spf.protection.outlook.com

include:mktomail.com include:email.influitive.com include:stspg-customer.com ~all"

dig +short @4.2.2.1 _spf.salesforce.com txt

"v=spf1 include:_mtablock1.salesforce.com include:_mtablock2.salesforce.com

ip4:136.146.208.16/28 ip4:136.146.210.16/28 ip4:136.147.62.192/26 ip4:136.147.46.192/26

ip4:85.222.130.192/26 ip4:85.222.138.192/26 ~all"

dig +short @4.2.2.1 spf.protection.outlook.com txt

"v=spf1 ip4:207.46.101.128/26 ip4:207.46.108.0/25 ip4:207.46.100.0/24 ip4:207.46.163.0/24

ip4:65.55.169.0/24 ip4:157.55.133.0/25 ip4:157.56.110.0/23 ip4:157.55.234.0/24

ip4:213.199.154.0/24 ip4:213.199.180.0/24 include:spfa.protection.outlook.com -all"

dig +short @4.2.2.1 spfa.protection.outlook.com txt

"v=spf1 ip4:157.56.120.0/25 ip4:157.56.116.0/25 ip4:157.56.112.0/24 ip4:134.170.140.0/24

ip4:134.170.132.0/24 ip4:207.46.51.64/26 ip4:157.55.158.0/23 ip4:157.56.87.192/26

ip4:64.4.22.64/26 include:spfb.protection.outlook.com -all"

dig +short @4.2.2.1 email.influitive.com txt

"v=spf1 a ip4:205.201.137.229 include:spf.mandrillapp.com ~all"

SanfordWhiteman
Level 10 - Community Moderator

This post has spurred a new series of posts on my own blog: http://blog.teknkl.com/third-marketo-users-broken-spf/

John_M
Marketo Employee

Fair point. I haven't seen any clients who are configured using the multiple DNS entry spanning SPF configuration, but this approach works, because I have clients using it. Im talking to some of the deliverability folks on their recommendation, so stay tuned, and thanks for your comments!!

Point taken, ill change my wording

SanfordWhiteman
Level 10 - Community Moderator

Fair point. I haven't seen any clients who are configured using the multiple DNS entry spanning SPF configuration

It's not multiple DNS entries.  It's a single DNS TXT entry with multiple text strings, as specifically designed into the TXT record type and advised in the SPF RFC.

but this approach works, because I have clients using it.

Sure, it works as well as includes usually do!  Which is to say, they're fine until they result in too many DNS lookups and break the SPF record entirely, like the marketo.com record is broken.

Kiersti_Esparz1
Level 7

I lead Marketo's Email Privacy and Deliverability Team.  We will get this blog updated shortly to work out some of the inaccuracies. 

Kiersti_Esparz1
Level 7

Thank you for pointing this out.  It looks like a record was added in December 2015 that resulted in too many lookup mechanisms being in the SPF record.  We have made necessary edits to ensure that we don't run into that error!

SanfordWhiteman
Level 10 - Community Moderator

Sounds good. I don't see any change in the published record yet.