I'll amend my post above to include this, *however* I could not get dma to successfully send using 587 unless INSECURE was enabled. This was not necessary when using 465 and TLS. My reading of STARTTLS implies there is a risk of MITM downgrade attacks, unless dma supports DANE/TLSA etc. Thoughts?
The MITM downgrade isn't any worse in practical terms than MITM proxying of the TLS session on 465, because a significant percentage of the world's mail servers use self-signed certificates. For SMTP, the only reliable mechanism currently widely available is DANE/TLSA, which notably also addresses the previously exploited issue of falsely issued certificates or untrustworthy sub-CA root certificates (both are documented to have happened during recent years, due to malpractice/negligence by supposedly trustworthy CAs). DMA should provide a mechanism to use 25/587 and configure TLS as mandatory (either for all connections in the case of forwarding to a relay, or specific remote hosts if used as a general MTA).
DANE solves most of the trust issues with TLS certificates, allowing the server operator to use more or less whatever they want to use, whether it's self-signed, their own org's CA, or a specific public CA. It also makes it almost impossible for someone with a compromised or improper root-CA cert to actually gain an advantage, unless DANE specifies a public CA and the problem cert is for that particular CA. Without DANE, 465 is essentially fully vulnerable to a MITM attack when used for MTA-to-MTA-via-MX purposes.
Sadly, adoption rates of DNSSEC and DANE are not terribly good at present, meaning that most ESMTPS sessions (on any port) are actually not protected against MITM. There's really no valid excuses for failing to implement both of them (yes, it does take time and skill to implement, and needs some ongoing management, but it's not terribly difficult, and there has been more than enough time for even the largest mail service providers to do it). DNSSEC may be imperfect, but not implementing it is like saying we're not going to fix the fuel tank which is known to frequently explode in a crash because it costs a bit and the fix won't prevent all explosions (in that analogy, it does actually prevent most easier explosions). Yes, I'm saying that not using DNSSEC is now equivalent to refusing to address the problems in a Ford Pinto! It may be imperfect, but it's a hell of a lot better than not using it.
If DMA does not have DANE support, I would grade it as sub-standard for general use on the public Internet, and only suitable for private network use or submission to a single or small set of upstream mail relay(s). I certainly hope that it does support DANE, but I don't know and your phrasing makes me wonder if that important feature is missing.
There is no technical reason why you should not be able to use TLS 1.2 on 587. There is also no technical reason why SMTP AUTH should work on 465 but fail on 587+STARTTLS. Problems with either of those are either misconfiguration (at either end of the connection), or bad implementation (at either end of the connection).
One of the issues with 465 is that it will not be forwarded by some routers, if those routers have the IANA-registered use of it enabled. That's due to the registered protocol being somewhat unusual, and not due to any firewall or filtering rules. So, it's randomly unusable or unreliable over some network paths. All usage of it is non-standard, and always has been, as it has never been part of a published standard; it was deprecated before
RFC 2487 was published, only appearing in earlier drafts of that RFC.