The same protocol wrangling plays out in the SSL space, and the periodic breakage of old standards is a well-sung melody. That just changes the problem, rather than answering it: When you receive a DNS-delivered DKIM signature, can you trust it? There are DNS security extensions, like DNSSec, but they suffer similar challenges: A patchily adopted and therefore optional add-on to an established protocol, and so the cycle perpetuates. Secondly, they introduce complexity and secondary vulnerabilities - now you have to manage DNS as well as e-mail, and DNS is a common target for attack, either through direct tampering, hijacking or spoofing.
If you demand DKIM, you won't be able to exchange e-mail with an awful lot of people. For a start, those are two of the surviving schemas that emerged from a flurry of competing proposals in the early part of the millennium - many failed to gain traction, and even now DKIM and SPF are not universally supported, much less mandated. This highlights the difficulties in adding security to a pervasive protocol like SMTP.
SPF and DKIM are other examples of optional security layers - Sender Policy Framework and DomainKeys Identified Mail use DNS records to publish, respectively, IP addresses and cryptographic keys of valid mail exchanges, so spoofed mail can be identified and processed. Look at e-mail, for example, which is particularly relevant since High-Tech Bridge picked on e-mail providers. And since those optional mechanisms are layered on top of the e-mail standards, they are not universally supported, used, or even considered. Unfortunately, those security layers are optional, not mandatory, and in many cases they are simply outright kludges - workarounds which, while clever, make the system even more complicated.
Engineers at the IETF, therefore, prioritise stability and availability, leaving security to be layered on top. If one hop demands a different protocol, large parts of the Internet could simple cease to function. Because of that ubiquity, it is highly risky to meddle with the core protocol. When you send e-mail from A to B, it doesn't matter what vendor's implementations are sitting at each end and how many hops the message traverses en route, it will use SMTP - often many times - to get there. Some of those existing services, like HTTP and SMTP, are practically universal. Crypto like SSL is agnostic - it's not a Web technology at all and is applied to all sorts of services. In the case of the Web, that's HTTP, In the case of e-mail, that's SMTP, and so on. It has been layered on top of existing protocols. SSL, like many other encryption technologies, is not a core protocol.
So, why the tardiness in updating to more secure options? Unfortunately, there's an easy answer to this: It is really hard to update core protocols without breaking the Internet, and because security has always been considered less of a priority than interoperability and stability. The Poodle attack in 2014 demonstrated how SSLv3 could be successfully attacked with relative ease. SSLv3 is ancient, and has been broken thoroughly enough for the IETF to formally deprecate it, meaning any service claiming to be standards compliant is required not to support SSLv3 at all, not merely to avoid it by preference. This week we learned that a lot of Web-mail providers still support vulnerable SSLv3 encryption, potentially leaving their users open to attack.