Without new code/libs to parse the TXT RR, SPF doesn't work. ...
that could be one of the reasons why, two years before the advent of SPF, i wrote up and circulated jim miller's idea from 1998. if you want to know about the paths not taken, see <http://sa.vix.com/~vixie/mailfrom.txt>.
On the other hand, having to deploy a new BIND that supports the presumably newly-defined RR type just to publish an SPF record would almost certainly doom it to near-zero deployment. Also, remember that if we find out that the format was b0rked, publishing a new TXT is a lot easier than getting another version of an SPF RR deployed....
i think the TXT RR choice was made so that applications could treat the contents as a meta-language and extend it forever, thus not having to know in advance what the ultimate goals and means would turn out to be. personally i prefer the MX RR and a stylized name, but i was trying to solve the problem rather than create an industry. (ymmv.)
Compare and contrast the uptake of SPF with DNSSEC :)
(Yes, I know there's *other* issues with deploying dnssec - but all those weird RR's probably scare off a lot of people...)
i suspect it's not the number of RR's or even the obscurity of those RR's, but rather the fact that the RR's keep changing in number, kind, and name, that makes dnssec seem like it's going to be hard to deploy. take heart, though -- we're *close*. real close. the next deployment barrier will be that your parent domain has to register your keys, and in the early days, will probably have an unjustifiably poor cost:benefit ratio for doing so. it will NOT, unless i'm completely confused, be that there are too many RR's. -- Paul Vixie