When creating an SPF record you are limited to a 255 character string. If you attempt to create an SPF or TXT record with a longer string (>255 Characters), BIND will give an error (e.g. "Invalid rdata format: ran out of space".). Some environments are too complicated to fit into a 255 character string. You run into needing a longer record. Luckily, RFC 4408 states a TXT or SPF record is allowed to contain multiple strings, which should be concatenated together by the application that is reading it. Here is an example from the RFC:
Multiple Strings in a Single DNS record
As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
record (either TXT or SPF RR types) can be composed of more than one
string. If a published record contains multiple strings, then the
record MUST be treated as if those strings are concatenated together
without adding spaces. For example:
IN TXT "v=spf1 .... first" "second string..."
MUST be treated as equivalent to
IN TXT "v=spf1 .... firstsecond string..."
SPF or TXT records containing multiple strings are useful in
constructing records that would exceed the 255-byte maximum length of
a string within a single TXT or SPF RR record.
You may have multiple "strings" in a single TXT record. Each "string" may be up to 255 characters in length, with a "length byte" indicating the size of the "string"'s payload. I don't believe there is any arbitrary limitation on the number of "string"s in a TXT record, but the RDATA itself may not exceed 65535 bytes in total, which is comprised of both the length-bytes and payloads of all "string"s contained therein. That 64K limit is a general restriction on DNS records of all types, not specific to TXT records.
Note that any DNS response which exceeds 512 bytes is slightly undesirable since, in the absence of EDNS0 (which the vast majority of -- but not all -- implementations honor these days), responses which exceed 512 bytes will signal truncation and prompt a retry via TCP. It's optimal to stay within 512 bytes if possible.
- the limit to a TXT string is 255
- the limit to a UDP packet is 512
- the limit to a total of TXT data for a given record is 65535
An example of an SPF record split into 2 separate entries as such:
"v=spf1 ip4:126.96.36.199/16 ip4:188.8.131.52/24 ip4:184.108.40.206/24 ip4:220.127.116.11 ip4:18.104.22.168/24 ip4:22.214.171.124/24 ip4:126.96.36.199/24 ip4:188.8.131.52/24 ip4:184.108.40.206/24 ip4:220.127.116.11/24 ip4:18.104.22.168/32 ip4:22.214.171.124/30 ip4:126.96.36.199 ip4:188.8.131.52/31 ip4:184.108.40.206 ip4:220.127.116.11 ip4:18.104.22.168" " ip4:22.214.171.124/24 ip4:126.96.36.199/30 ip4:188.8.131.52/30 ip4:184.108.40.206 ip4:220.127.116.11 ip4:18.104.22.168 ip4:22.214.171.124 include:thirdparty.net -all"
Another option, if you don't have many DNS lookups today, is to create a separate record for some of your traffic and include that record in this one:
_spf.mydomain.com TXT v=spf1 ip4:126.96.36.199/16 ip4:188.8.131.52/24 ip4:184.108.40.206/24 ip4:220.127.116.11 ip4:18.104.22.168/24 ip4:22.214.171.124/24 ip4:126.96.36.199/24 ip4:188.8.131.52/24 ip4:184.108.40.206/24 ip4:220.127.116.11/24 ip4:18.104.22.168/32 ip4:22.214.171.124/30 ip4:126.96.36.199 -all
mydomain.com TXT v=spf1 ip4:188.8.131.52/31 ip4:184.108.40.206 ip4:220.127.116.11 ip4:18.104.22.168 ip4:22.214.171.124/24 ip4:126.96.36.199/30 ip4:188.8.131.52/30 ip4:184.108.40.206 ip4:220.127.116.11 ip4:18.104.22.168 ip4:22.214.171.124 include:thirdparty.net -all
You may also want to look into hosting your SPF records with our Brand Protection product which works around this issue entirely. For more information see Benefits of hosting records with Agari.