Comment 150 for bug 308181

Although RFC8314 is on the standards track, it's more a "best practices" document than an actual protocol definition.

It's true that Thunderbird does not implement configuration via DNS SRV (this bug here).
There are several fundamental reasons:

1. Arbitrary DNS lookups - bug 545866 / bug 14328 - are not implemented by Gecko.
   I've spent a lot of time implementing it, over 8 years ago (April 2010),
   only for the patch to be ignored and not reviewed. Forgive me when I'm a little less excited today.

2. DNSSEC is very hard to administrate without shooting yourself in the foot, and consequently,
   it's not widely deployed on second level domains. APNIC says:
   "Unfortunately, our recent study showed that DNSSEC deployment is still very low
   (only ~1% of .com, .net and .org domains deploy DNSSEC)"
   https://blog.apnic.net/2017/12/06/dnssec-deployment-remains-low/
   On most domains, DNS is completely insecure. I don't see it gaining quickly, either.
   APNIC <https://stats.labs.apnic.net/dnssec/XA> actually shows declining deployment in the last year.
   Without DNSSEC, DNS SRV is no more secure than http. In that light, comment 61 is a little ironic.

3. DNS SRV does not give us some critical information we need to configure the accounts.
   Specifically, which form the username needs to be transmitted. Is it bbob, or <email address hidden>, or
   even something like EXAMPLE\\bbob? Get it wrong, and the configuration doesn't work.
   Sure, we can try them all. And risk authentication failures and - worst case - triggering
   3-failures-in-a-row-and-you're-out security mechanisms.
   We're back to guessing and trail&error.
   That defeats the entire point of getting an authoritative configuration that will definitely work.
   If we were to support DNS SRV, then only as a second-class, fallback, legacy format.

DNS SRV is not widely used now. Why trying to establish a mechanism that has known shortcomings?

I think people here want this, because they want a standards-based mechanism. I fully concur with that.
But I'd rather make a new standard than implement a bad standard that nobody else implements anyway.