-
Yeah but I looked at the DNS and it's not split unless they also do some weird shit behind the scenes.
The output of dig on it is actually longer because it's stuck some quotes in places (maybe the magic split + concat?)
hippy-
Yeah but I looked at the DNS and it's not split unless they also do some weird shit behind the scenes.
Godaddy shows my example above as a single string. Then does it's weird shit to make it work in DNS.
Multiple strings enclosed in quotes and separated by a space. The verifier will remove the " " and smash it all back together again when it realises it is an SPF record. So in your case, the second string is ip4:xxx.xxx.xx.192/27 ip4:xxx.xx.xxx.36 ~all
If it is a domain you give a shit about, put your explicit ip4's ahead of your includes. Currently, if any of those IPs want to pass, the verifier needs to complete at least 7 other lookups first. 7 is within the acceptable limit of 10, but a free improvement and general rule of thumb would be to put the IPs first.
Going over 255 characters is less of an issue today, but some people are adamant they need to stay under it. The look up limit is more of a concern.
stevo_com
There's your problem. If you're running an SPF check, it will be concatenating the strings back into a single record. DIG the TXT record and you'll see the split/quotes/spaces.
ssa-test.com. 3600 IN TXT "v=spf1 ip4:1.2.3.1 ip4:1.2.3.2 ip4:1.2.3.3 ip4:1.2.3.4 ip4:1.2.3.5 ip4:1.2.3.6 ip4:1.2.3.7 ip4:1.2.3.8 ip4:1.2.3.9 ip4:2.2.3.1 ip4:2.2.3.2 ip4:2.2.3.3 ip4:2.2.3.4 ip4:2.2.3.5 ip4:2.2.3.6 ip4:2.2.3.7 ip4:2.2.3.8 ip4:2.2.3.9 ip4:3.2.3.1 ip4:3.2.3.2 ip4:3.2." "3.3 ip4:3.2.3.4 ip4:3.2.3.5 ip4:3.2.3.6 ip4:3.2.3.7 ip4:3.2.3.8 ip4:3.2.3.9 ~all"