We recently added a new IP range for our San Antonio data center to our SPF record, which many of our customers’ domains reference. This however increased the string length to 134 characters, and tinydns splits the string when it is larger than 127 characters. So our SPF record looked like this…
emailsrvr.com txt "v=spf1 ip4:207.97.227.208/28 ip4:207.97.245.0/24 ip4:204.119.252.0/24 ip4:206.158.104.0/22 ip4:64.49.219.0/28 ip4:66.216.121.0/" "24 ~all"
Technically this is okay, because receivers are supposed to concat these multiple strings together. However, apparently not all SPF systems are this smart. Including the popular SPF checker at DNSStuff.com. So we are changing it to make these systems happy.
There are two IP ranges that we no longer use, which we are taking out of the record… putting the new string length at 92. But as we grow I am sure we will approach 127 chars again. At that point we will probably break our SPF record into a nested set of includes, like hotmail does…
Top: hotmail.com txt "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all"
Example include: spf-a.hotmail.com txt "v=spf1 ip4:209.240.192.0/19 ip4:65.52.0.0/14 ip4:131.107.0.0/16 ip4:157.54.0.0/15 ip4:157.56.0.0/14 ip4:157.60.0.0/16 ip4:167.220.0.0/16 ip4:204.79.135.0/24 ip4:204.79.188.0/24 ip4:204.79.252.0/24 ip4:207.46.0.0/16 ip4:199.2.137.0/24 ~all"
What should Webmail.us customers add to their own SPF records to indicate that their mail might original via a Webmail.us server?
Thanks.
You just have to include the emailsrvr.com SPF record. That way when we add new IPs, you don’t have to update your SPF record. Here is the syntax…
example.com txt “v=spf1 include:emailsrvr.com ~all”
If you run into a live SPF implementation (not just the DNSStuff checker) that doesn’t handle the string concatenation correctly (if it comes up again), please pass it on to me. I like to hunt down the maintainers and guilt them into fixing it.
Also, the validator that I run will handle that correctly things per RFC 4408. It’s not as pretty as the DNSStuff one, but more correct.
I don’t have specific implementations or providers to point at. I just have some people tell me “hey maybe it’s the funky spf record that dnsstuff says is invalid”. So it was easier to fix it, than to prove them wrong.
But if I find any, I will definitely let you know.