Currently Domains only manage DNS for the primary domain, and do not manage Alias domain DNS records at all.
This is problematic, because e.g. DKIM selectors change over time, so there is no way for DNS administrators to sensibly maintain the DNS records manually, unless their DNS host happens to support some sort of out-of-spec DNS aliasing hacks, which many do not.
Proposed solution
Add a boolean flag to Domain objects to allow enabling alias domain DNS management (default disabled I suppose, to avoid backwards-incompatible updates) which causes Stalwart publish records for alias domains in addition to the primary domain.
Implementation Details
There is a question as to the shape these records should take. I think the simplest path (since it does not require any changes to TLS cert generation, etc) would be to handle various record types as below:
| Record Type | DNS Record Type | DNS Value | Notes |
|---|---|---|---|
| DKIM public keys | CNAME | Point to primary domain selector record | |
| TLSA records | Ignored | Unnecessary since domain will not receive mail directly | |
| SPF records | TXT | “include:primarydomain.tld -all” | |
| MX records | MX | Duplicate primary domain record | |
| DMARC policy | TXT | Duplicate primary domain record | |
| SRV records | Ignored | MUAs should connect only to the primary domain | |
| MTA-STS policy record | TXT | Duplicate the primary domain’s record, additionally setting the mx property to point to the primary domain’s mail exchangers |
|
| TLS reporting record | TXT | Duplicate primary domain records | |
| CAA records | Ignored | MUAs should connect only to the primary domain | |
| Autoconfig records | Ignored | MUAs should connect only to the primary domain | |
| Legacy Autoconfig records | Ignored | MUAs should connect only to the primary domain | |
| Microsoft Autodiscover records | Ignored | MUAs should connect only to the primary domain |