I'm sorry this page needs to exist, it's partly my fault. I created the first "large scale" SPF record (for eBay and PayPal), and agreed that this was the best way to do it. I guess the people after me agreed too, because 20 years later it's still pretty much the same shape as when I made it!
But I don't have any regrets, the format was pretty straightforward and offered a lot of flexibility. The biggest issue was the parsing libraries handling all of the "include" statements correctly.
Eh, SPF is one of the few things I don't hate about modern e-mail. Pretty easy to figure out / tweak / parse. I like dealing with it way more than MTA-STS.
SPF flattening is difficult to get correct and then you have to check it every so often to update it.
DNSControl automates this. https://docs.dnscontrol.org/language-reference/domain-modifi...
(It’s open source)
As someone managing dns for a lot of orgs, the part that kills me is the amount of crappy sass'es that demand you add a big include to your spf. If they already have a skim record thats plenty to get mail through, except their validator wizard thing wont let you use the tool until it finds their string in your record. That means no flattening either.
> SPF record syntax follows one shape:
The first six words do not scream "human written" to me.
Comes up 99% AI-generated on Pangram.
The overall structure of the document is no different than any other tech reference or RFC that I've read over the decades
True. It's a 25 minute read instead of 1hr+
I could tell before opening the link, but the pill tags and neon color palette are also a huge signal.
That’s obvious. But a genuine question: why does it matter? This seems to be a detailed reference document for a very technical purpose (and SEO juice for the company I guess).
If that’s what you want, you would be better served by RFC 7208: <https://www.rfc-editor.org/info/rfc7208/>