Provide for additional domains to have their own nameservers

I support email for a second domain that I have no control over the nameservers they use. I finally saw the text in the MiaB maintenance guide to “Configure its nameservers to be the same nameservers on your first domain name”. Not an option for me here.

I have kludge things together. I would much rather have MiaB allow for different nameservers for each domain supported.

The nameservers used by a domain are not defined in Mail in a Box, but rather at the domain registrar. So, as long as nobody changes them to point to Mail in a Box, the current nameservers will continue to be used for this domain.

Of course, you or whoever controls the domain and its current nameservers will then need to manually create all the necessary DNS records for email functionality. For more information, see the ‘External DNS’ section in the Mail-in-a-Box admin interface.

That is basically what I had to do. I had to spin up another authoritative server with “proper” NS RR. When MiaB could have done the job, but for the wrong NS RR.

Also, and I have not tried to do packet capture on this, MIAB is sending out XFR notifies to the wrong Nameservers. I suspect they just ignore those, but still.

Thus the current situation of handling additional domain nameservers is a lost opportunity.

And that is why I posted this note in the Improvements discussion area.

To be honest, I’m not entirely sure what you’re trying to achieve.

In most cases, when someone wants to use an email service with their own domain name, they need to manually set the appropriate DNS records in the control panel of their DNS provider—often even when both DNS and email are hosted by the same provider.

Also, most people and many companies that use their own domain names don’t run their own authoritative name servers. Instead, they rely on their DNS provider’s name servers for their public DNS records. So, if you check the name servers of their domains, you’ll usually see something like ns1.dnsprovider.com, not ns1.theirdomain.tld. The same goes for their MX records, where you often see something like: mail.protection.outlook.com :wink:

Mail-in-a-Box includes an authoritative DNS server to simplify the setup process for non-experts, since configuring all the necessary DNS record for sending email reliably can be tricky. But there’s absolutely nothing wrong with continuing to use your existing DNS provider and their name servers for all, or just some, of the email domains you’re hosting on your Mail-in-a-Box server.

In turn, that of course also means there’s nothing wrong with hosting the email and managing the DNS for otherdomain.tld on your box, even if your box is actually running under box.domain.tld and the nameserver on your box is named ns1.box.domain.tld. Especially if you don’t want to make your life more complicated than necessary. :wink:

1 Like

small addition… :wink:

I no longer use Mail-in-a-Box myself, but just for fun, I run my own NSD servers on three small VPS instances. I host multiple domains on them, and it would never even occur to me to set up separate name servers for each of those domains. I mean, why would I?

The only reason I can think of why you would want to to that would be multi-tenancy, which Mail-in-a-Box isn’t really designed for anyway, since it only supports a single admin account and no domain-specific admin roles.

However, this would mainly be an issue if your ‘client’ needed to manage their mailboxes themselves (which actually seems like a far bigger issue to me). As for DNS, you can simply provide them with all the necessary DNS records, which they would then enter in the control panel of their DNS provider, just like they would have to do with any other email provider. Then you set up their mailboxes. Done!

By the way, other similar email appliances like Mailcow don’t come with a built-in authoritative name server. Many email providers don’t offer that either, or if they do it’s a separate service. Most SoHo users I know simply use the nameservers and the DNS panel of their DNS provider, which is usually also their registrar.