Enforce STARTTLS and verify MX certificates
SMTP is kept insecure all around the world: as of 2020 and most probably today as well, the large majority of Mail eXchangers do not enforce STARTTLS nor provide a valid PKIX certificate (based on CCADB and/or DANE). And even those few outbound MTAs which do enforce STARTTLS, mostly don’t verify the certificate on the other end.
Opportunistic STARTTLS is defeated by MITM attacks downgrading to plain-text, and the horrific trust-any default policy gets defeated by any self-signed or private certificate in the middle.
Let us enforce inbound / outbound STARTTLS and MX certificate verification, shall we?
MTA-STS is NOT a solution. Outbound MTAs which don’t talk STARTTLS to their peers would also omit to check for an _mta-sts record.
This is nonsense from Google and Microsoft at the IETF, just like for OAuth2.
Using an additional protocol (namely HTTP itself protected by PKIX) for securing SMTP does not enforce ESMTPS, let alone certificate validation.
Enable inbound MTA-STS if you wish, but unless you make STARTTLS and a valid trust chain mandatory at the SMTP level, some clear-text messages will still pass through the network pipes anyhow.
Inbound MX
530 5.7.0 Must issue a STARTTLS command first (https://nethence.com/smtp/)Outbound relay
Recipient's Mail eXchanger does not offer STARTTLS capability (https://nethence.com/smtp/)THE SAD STATE OF SMTP ENCRYPTION https://blog.filippo.io/the-sad-state-of-smtp-encryption/
POSTFIX AND STARTTLS https://pub.nethence.com/mail/postfix-tls
Let’s tune our cipher suites https://pub.nethence.com/security/ciphers
Strong Ciphers (see Other Software section) https://syslink.pl/cipherlist/
Applied Crypto Hardening – 8. Mailservers https://bettercrypto.org/#mailservers