check if the receiving server supports TLS on port 25 in a trustworthy manner (via DNSSEC-secured TLSA RR)
optionally allow verifiable self-signed certificates while DNSSEC's root serves as a trust anchor (instead of the traditional public CA model)
pin CA or certificate for CA-issued certificates. As long as a CA-issued certificate is used, usage of DANE does not break the traditional way to validate a certificate (without DANE).
safely block connections to DANE-secured mail servers if DANE verification fails.
Using DANE
there is no way to just downgrade connections which otherwise use STARTTLS (e.g. via MITM-proxy attack).
there is no need to still trust into the traditional public CA model (while the public CA model still can serve as an additional trust anchor).
there is no need to rely on opportunistic encryption and to trust any certificate while this still is allowed for mail servers which are not DANE-secured (better-than-nothing approach).
There's a bunch of large E-Mail providers which already have DANE support (like web.de while they initially only had a widely-critisised concept they called "E-Mail made in Germany"). Postfix already supports DANE, as it seems.
Securing port 25 with DANE is not about end-to-end encryption (sending mail client to receiving mail client). But there's more to come by extending the DANE framework in the future (WIP like OPENPGPKEY and SMIMEA is on its way). That said, this issue is not about end-to-end encryption.
Mail servers with DANE support can
Using DANE
There's a bunch of large E-Mail providers which already have DANE support (like web.de while they initially only had a widely-critisised concept they called "E-Mail made in Germany"). Postfix already supports DANE, as it seems.
Securing port 25 with DANE is not about end-to-end encryption (sending mail client to receiving mail client). But there's more to come by extending the DANE framework in the future (WIP like OPENPGPKEY and SMIMEA is on its way). That said, this issue is not about end-to-end encryption.