These things tend to -- until they don't (by which time you don't notice).
> ... and nobody told me not to until years later.
Instead of trying to enumerate all of the wrong ways to do things, the RFCs -- the authoritative documents -- will describe the right way to do things (although, in some cases, they do explicitly identify some things one must not do). If an RFC is ambiguous or unclear, that's a deficiency which should be addressed.
--
> And apparently I'm still doing it wrong, I recently learned I'm supposed to point the MX of the various domains to whatever certificate the mail server will use.
In general, the following has worked quite well for a long time:
1. Choose the "one true name" that your mail server will be known as.
foo.example.com
2. Create an A RR for the hostname that points to the IP address of the server.
foo.example.com. -> 192.0.2.25
3. Ensure that the PTR RR for the IP address of the server resolves to the chosen name (cf. "forward-confirmed reverse DNS").
25.2.0.192.in-addr.arpa. -> foo.example.com
4. Configure your MTA to use foo.example.com as its "official" name (in EHLO/HELO greetings, Received: headers, and so on). If you run POP3/IMAP4 daemons on the same host, configure them to also use the same name.
5. Ensure that the MX RR for any hosted domains reference the one true name.
6. If you wish to use additional hostnames to refer to this server ("mail.example.com", a "mail" subdomain for each of your hosted customer domains, etc.), create CNAME RRs for them that point to the one true name.
7. Acquire and install a certificate for the one true name of the server ("foo.example.com") AND any other names that the server is known by (i.e., any hostnames from step six) and configure your MTA (and POP3/IMAP4 servers) to use it.
--
A few related points:
Notice the common theme: use the "one true name".
The above steps assume that everything is running on a single host that has a single IP address. If it has multiple IP addresses available, you can "get more creative" and use "multiple true names" (this is almost done for "cosmetic" purposes, however; there are no technical reasons to do so).
I did not mention SPF, DKIM, or DMARC, but you'll want to configure them all - and they should all use the "one true name" of your mail server.
Some mail clients nowadays can make use of the "autoconfig" [0] and/or "autodiscovery" [1] methods, eliminating the need for the end user to manually set up their MUA. Additional RRs will need to be created to support these methods; "autoconfig" will also require a web server and some additional configuration.
Postfix added support for SNI a few years ago (I can't speak to other MTAs). As with HTTPS, this allows using multiple "per-domain" certificates instead of a single certificate with all names. I don't know which, if any, mail clients currently support and, I have no firsthand experience using it. I mention it just in case it may be something you want to look into.
These things tend to -- until they don't (by which time you don't notice).
> ... and nobody told me not to until years later.
Instead of trying to enumerate all of the wrong ways to do things, the RFCs -- the authoritative documents -- will describe the right way to do things (although, in some cases, they do explicitly identify some things one must not do). If an RFC is ambiguous or unclear, that's a deficiency which should be addressed.
--
> And apparently I'm still doing it wrong, I recently learned I'm supposed to point the MX of the various domains to whatever certificate the mail server will use.
In general, the following has worked quite well for a long time:
1. Choose the "one true name" that your mail server will be known as.
2. Create an A RR for the hostname that points to the IP address of the server. 3. Ensure that the PTR RR for the IP address of the server resolves to the chosen name (cf. "forward-confirmed reverse DNS"). 4. Configure your MTA to use foo.example.com as its "official" name (in EHLO/HELO greetings, Received: headers, and so on). If you run POP3/IMAP4 daemons on the same host, configure them to also use the same name.5. Ensure that the MX RR for any hosted domains reference the one true name.
6. If you wish to use additional hostnames to refer to this server ("mail.example.com", a "mail" subdomain for each of your hosted customer domains, etc.), create CNAME RRs for them that point to the one true name.
7. Acquire and install a certificate for the one true name of the server ("foo.example.com") AND any other names that the server is known by (i.e., any hostnames from step six) and configure your MTA (and POP3/IMAP4 servers) to use it.
--
A few related points:
Notice the common theme: use the "one true name".
The above steps assume that everything is running on a single host that has a single IP address. If it has multiple IP addresses available, you can "get more creative" and use "multiple true names" (this is almost done for "cosmetic" purposes, however; there are no technical reasons to do so).
I did not mention SPF, DKIM, or DMARC, but you'll want to configure them all - and they should all use the "one true name" of your mail server.
Some mail clients nowadays can make use of the "autoconfig" [0] and/or "autodiscovery" [1] methods, eliminating the need for the end user to manually set up their MUA. Additional RRs will need to be created to support these methods; "autoconfig" will also require a web server and some additional configuration.
Postfix added support for SNI a few years ago (I can't speak to other MTAs). As with HTTPS, this allows using multiple "per-domain" certificates instead of a single certificate with all names. I don't know which, if any, mail clients currently support and, I have no firsthand experience using it. I mention it just in case it may be something you want to look into.
--
[0]: https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird...
[1]: https://tools.ietf.org/html/rfc6186