This MTA-STS solution is pennies per month and uses commercial SSL certificates; it's what we do.
You will need an Amazon Web Services account to do this though. https://www.missioncriticalemail.com/2022/10/12/host-your-mta-sts-text-file-for-pennies/ Hope that helps, Mark -- _________________________________________________________________ L. Mark Stone, Founder North America's Leading Zimbra VAR/BSP/Training Partner For Companies With Mission-Critical Email Needs Winner of the Zimbra Americas VAR Partner of the Year - Two Years Running ! ----- Original Message ----- | From: "Edmund Lodewijks via mailop" <[email protected]> | To: [email protected] | Sent: Thursday, October 30, 2025 2:00:37 PM | Subject: Re: [mailop] DANE with self-signed cert trouble | Thank you, all, for your replies! | | On 2025/10/30 18:56, Viktor Dukhovni via mailop wrote: |> There is a non-trivial minority of SMTP servers that have self-signed |> certificates. Barring some reason to expect otherwise (MTA-STS policy?), |> SMTP clients broadly tolerate unvalidatable server certificates, |> including self-signed as one of many ways that can happen. That's just |> basic unauthenticated opportunistic TLS. | | I see. So, a CA signed certificate would be the way to go then. | | I do have an mta-sts policy, which would be causing the havoc with Gmail | (I never thought of that!). | | Not sure why Protonmail also drops mails to my server, but I have | reached out to their support and hope to receive an explanation. | | Considering that some big players (e.g. Gmail and Fastmail) only use | mta-sts (and don't want to go near DANE[0]), it would not make sense to | not use mta-sts? In which case a CA cert would be required. | |> |> For example, the backup MX of the Armenian NIC, "isoc.amnic.net" has |> a self-signed cert and matching TLSA records: | | I can't see that they have an mta-sts policy. | |> |> Likewise both MX hosts of a Czech health insurance provider: |> |> cpzp.cz. IN MX 10 posta.cpzp.cz. |> cpzp.cz. IN MX 30 postc.cpzp.cz. | | Nor do they have a mta-sts policy that I could find. | |> So you should be able to field a DANE-validatable self-signed cert and |> not have trouble receiving mail from either non-DANE SMTP clients or |> DANE-enabled SMTP clients (provided the TLSA records match that cert or |> its public key). | | If I understand correctly, a mta-sts policy would be in the way of this | working. I suppose the process would be (from such a server's point of | view): | | 1. We don't use DANE, so check for MTA-STS | 2. MTA-STS says: need CA cert | 3. Hey, I am presented a self-signed cert! -> Bye! | |> name = *.pm.me |> name = *.protonmail.ch |> name = *.protonmail.com |> name = *.protonvpn.ch |> name = *.protonvpn.com |> name = protonmail.com |> depth = 0 |> Issuer CommonName = R13 |> Issuer Organization = Let's Encrypt | | So, there we go. Protonmail could then, if I understand correctly, | receive emails from Gmail, Fastmail etc (no DANE, but MTA-STS) because | they have a CA cert. | | If I understand all this correctly, then that would mean that I would | need to either drop mta-sts (seems counter-productive), or use a CA | certificate. | | And, in the latter case, if memory serves me well, if I re-use the same | private key for the certificate generation, together with a "3 1 1" tlsa | record, then I won't have to change the tlsa record every time the | certificate is renewed (which would be a pain, especially with even | shorter turnaround times for LE certs next year). I also seem to | remember a tool called 'danebot' by you, Viktor (if I may address you | so), as a wrapper around certbot to preserve the private key. | | Thank you all for your enlightening replies! | | Kind regards, | Edmund | | | [0]: https://www.fastmail.com/blog/dnssec-dane/ | _______________________________________________ | mailop mailing list | [email protected] | https://list.mailop.org/listinfo/mailop _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
