12

I have an email server (mail) that currently hosts one domain example1.com. The server is behind NAT and I have split-dns configured on the LAN.

The time has come to host additional domains on the same email server and after many hours of googling I have read conflicting information on how to create the public (external) and internal DNS records. There seems to be two approaches to configuring the MX and A records which I will demonstrate below.

APPROACH 1

External DNS for example1.com

example1.com      7200 MX 10 mail.example1.com.
mail.example1.com 3600 A  213.xx.xx.xx

External DNS for example2.com

example2.com      7200 MX 10 mail.example1.com.
mail.example1.com 3600 A  213.xx.xx.xx

In the first approach the MX record for example2.com points to the first domain, e.g. example1.com.

This seems to be how email hosting companies like Google Apps and ISPs work.

The problem with this method for my situation is that I don't want emails from example2.com to show that they originate from example1.com. The "solution" to this would be that I purchase a third domain let's say mail.myemailserver.com which would be used as the default (or first) domain for the email server.

APPROACH 2

External DNS for example1.com

example1.com      7200 MX 10 mail.example1.com.
mail.example1.com 3600 A  213.xx.xx.xx

External DNS for example2.com

example2.com      7200 MX 10 mail.example2.com.
mail.example2.com 3600 A  213.xx.xx.xx

In the second approach the MX record for the second domain points to its own domain, e.g. example2.com.

What I'm asking for is have I understood the configuration of multiple domains hosted on a single server and is there a best practice or advice on which approach I should implement in my own environment.

joshu
  • 771
  • 3
  • 12
  • 28
  • In APPROACH 1, External DNS for example2.com, `mail.example1.com 3600 A 213.xx.xx.xx` - there is an error and instead of `mail.example1.com` should be `mail.example2.com` or there is specific case? – dikkini Mar 26 '19 at 07:24

2 Answers2

7

Both approaches are valid, do know that this record will not show as the originating address. When you send an email to one of your configured addresses, the sending MTA will look up the MX record configured for your domain. It will get the IP from that domain and it will open an SMTP session with your SMTP server (or one of your SMTP servers if you have configured more than one).

Even without an MX record it will work, because then the MTA just looks up the A record for your domain. (providing your A record points to your SMTP server of course)

Lucas Kauffman
  • 16,818
  • 9
  • 57
  • 92
  • thanks for your explanation. Are there any advantages or disadvantages of either approach? – joshu May 01 '12 at 21:11
  • Well the better approach is to use an MX record, the reason for this is that it might be you want to split your mail server from your webserver for example. Then you can configure MX records for multiple mail servers while your A record still points at the correct webserver. – Lucas Kauffman May 01 '12 at 21:13
  • Just so I've understood when you say "an MX record" you are referring to _approach 1_, right? ;) – joshu May 01 '12 at 21:18
  • Actually to both approaches :p. An MX record is configured to point to a mailserver for a domain. In the end it just goes looking for an IP and connects to that IP, it doesn't care about what MX record is configured as long as the A record that goes with the MX record (so mail.example1.com and mail.example2.com ) point to an IP. – Lucas Kauffman May 01 '12 at 21:25
  • Cool I understand. One final thing. I might have overlooked this in my question, but for _approach 2_ I would need to add a new zone for example2.com, yes (not necessary in _approach 1_)? – joshu May 01 '12 at 21:34
  • You would need to do that anyway because you have 2 different domains to manage. Every domain has its own zonefile. Since example2 is also present in approach 1, you would still need to add a zonefile for it. – Lucas Kauffman May 01 '12 at 21:39
  • sorry I should have explicitly said add a new zone to the **internal DNS**, e.g. "for approach 2 I would need to add a new zone **internal DNS** for example2.com, yes (not necessary in approach 1)? – joshu May 01 '12 at 21:57
  • of course, it works the same, it doesn't matter if it's internal or external, the protocol stays the same :) – Lucas Kauffman May 01 '12 at 22:21
  • I'm very grateful for you patience and help! I'll try to setup the second domain tomorrow. Thanks again. – joshu May 01 '12 at 22:24
  • Glad to help :) – Lucas Kauffman May 01 '12 at 22:25
3

Both approaches are perfectly valid. Approach 1 is probably better if you would like to use TLS later on.

By the way, the mail exchanger record doesn't show where mails originate but where they will be sent to.

Oliver
  • 5,883
  • 23
  • 32
  • You mentioned TLS. Are you referring to webmail via SSL? If so then yes that is already configured for the first domain. Regarding the origin of the mail won't the headers contain example1.com if I use _approach 1_? – joshu May 01 '12 at 21:08
  • @yonatan No, the received header only contains mailservers that are passed, the content is their IP and the reverse dns of that IP, not the MX record. – Lucas Kauffman May 01 '12 at 21:13
  • No, I'm referring to encrypted SMTP. I'm not sure if this is a problem, but when you use this, you typically have one certificate installed (e.g. containing the common name mail.example1.com). If a server connects to mail.example2.com and is presented with the certificate mail.example1.com, this might cause a problem. As for the mail headers: at some point you will certainly have a mention of example1.com in the headers, no matter how you do it. Why waste your time to work around this? – Oliver May 01 '12 at 21:21
  • @oliver the two domains are for two independent companies that's why I want it to look as if the domains are hosted on two separate email servers even though they are not. – joshu May 01 '12 at 21:32
  • 1
    If this is an absolute must for you, you should go with approach 2 then. As said, this is perfectly valid. – Oliver May 01 '12 at 21:35