There are two possible reasons for this.
Firstly SMTP host name matching has traditionally been defined quite vaguely. You can check the historical notes about this in RFC 6125 (a recent RFC about best practicises for host name verification, not yet widely implemented). RFC 3207 (Secure SMTP over Transport Layer Security) doesn't give much details as to where the host name should be in the certificate. RFC 4954 (SMTP Service Extension for Authentication) gives more details and talks about Subject Alternative Names, but it's in the context of SASL. Ambiguous or vague host name matching specifications are often a reason why no correct attempt to match the host name is made at all, unfortunately.
Secondly, SSL/TLS is rarely used between Mail Transfer Agents (MTA). What you're doing by getting the MX DNS record and trying to send an e-mail directly to it is typically done my MTAs, not so much by a Mail Submission Agent.
Typical usage of SSL/TLS for SMTP is between a Mail User Agent (the e-mail client) and a Mail Submission Agent (your ISP's e-mail server, where you have to authenticate).
SSL/TLS between MTAs is hard to set up, because not every server supports it and it's hard to know which MTAs will support it. Some people advocate "optimistic TLS" support, whereby you try to see whether the server you're talking to supports TLS and fall back to plain SMTP if it doesn't. There's unfortunately little to gain by doing so, since you're obviously vulnerable to MITM attacks as soon as you're willing to downgrade anyway.
In addition, the MX entry you get may itself have been compromised (at least without DNSSEC).
Overall, this actually makes it quite hard to rely on any form of transport security for e-mail beyond the MUA/MSA connection. This probably explains why there's little emphasis on configuring MX servers properly for SSL/TLS.