Back on track I've tested both approaches and as there are many users who I've read have similar questions regarding the setup and behaviour of multiple domains I will share my observations below.

Approach 1

In addition to creating the DNS records in my previous post, I also added mail.example2.com as a virtual host for domain example2.com. This allows users to visit https://mail.example2.com and login with user and pass as opposed to user@example2.com and pass.

As LMStone pointed out the email headers show that mail from anyone in example2.com originate from example1.com (this is explained here.) This is also true for content filter notifications.

I noticed that an IMAPS mail client can use the virtual host mail.example2.com, but unlike the webmail access must use the full username, e.g. user@example2.com. Is this the normal behaviour?

Approach 2

Created the DNS records as shown in the previous post and I made the same observations as in Approach 1.

In contrast to Approach 1 when I click "Check MX record" under example2.com in the Admin Console, I get the following message,

"Domain is configured to use SMTP host: mail.example1.com"

I found this thread where a user has the same DNS setup and gets this message. Even though, I can send and receive email, should I do something about this message?

=========================

The headers showing the first domain (mail.example1.com) is a concern, as I don't want any reference to that domain when mail is sent from example2.com. The only solution I can think of is to get a "generic" domain name for the zimbra server, a kind of "umbrella" name like "examplehosting.com." Does this make sense?

I've gone through about 14 pages of google search results for the Zimbra forums relating to multi-domain setups.

The posts I've read discuss two ways of configuring a Zimbra server to handle more than one domain. One approach uses the default (or first domain) as the mx record for all further domains. I guess this is similar to how hosting companies work in that you point your domain to google apps or whatever it is.

With the second method you configure both the public and private DNS records to reflect the new domains. In contrast to the previous approach, each domain looks as if it "lives" on its own email server.

Help me decide what to do.

As Bill pointed out, the first way is really the only public way. If you don't want example1.com users to know about example.com users, then the suggestion to have the Zimbra server be on a "generic" domain like "yonatanmailservices.com" is the way to go (instead of being on example.com).

As Bill pointed out, the first way is really the only public way. If you don't want example1.com users to know about example.com users, then the suggestion to have the Zimbra server be on a "generic" domain like "yonatanmailservices.com" is the way to go (instead of being on example.com).

Hope that helps,
Mark

Ok I've settled on getting an additional domain for the server.

I'm sorry if I haven't "let go" of the approach 1/2 debate, yet. In the interest of understanding when you say "..the first way is really the only public way" is this a convention stated some where? There are many users on these forums who have adopted one or the other that's why I wonder about a stated convention.

I'm sorry if I haven't "let go" of the approach 1/2 debate, yet. In the interest of understanding when you say "..the first way is really the only public way" is this a convention stated some where? There are many users on these forums who have adopted one or the other that's why I wonder about a stated convention.

Fair question!

It's not like I have seen an RFC for this, but as a Zimbra Hosting Provider I can tell you that having the one "master" domain for the Zimbra server(s) simplifies everything -- especially for the clients.

We use the same three MX records (all on reliablenetworks.com) for every hosting client. Regardless of their onboarding method, this alone just makes troubleshooting very straightforward.

If we had to manage unique MX records for every client, it would be quite an administrative challenge.

Plus, not that it's a good reason all by itself, but Google, Postini and lots of other large providers do the same.

That's all I wanted to hear! Makes sense to me, so I will do as you recommend...APPROACH 1 it is

Do you setup virtual hosts for the domains you host on reliablenetworks.com or do you direct your clients to your domain?

If you setup virtual hosts for your clients is this used for webmail access only or <strike>also for POP, IMAP, ActiveSync in desktop & mobile clients</strike> (this is what you mean by "on boarding method")?

That's all I wanted to hear! Makes sense to me, so I will do as you recommend...APPROACH 1 it is

Do you setup virtual hosts for the domains you host on reliablenetworks.com or do you direct your clients to your domain?

If you setup virtual hosts for your clients is this used for webmail access only or <strike>also for POP, IMAP, ActiveSync in desktop & mobile clients</strike> (this is what you mean by "on boarding method")?

We set up virtual domains for some clients but not others. Since we have been running Zimbra since 4.0.3, the virtual domain functionality has improved, but back in the day there were several "gotchas" the specifics of which I no longer remember that led us to avoid using virtual domains if at all possible, and, justified or not, we tend to follow that to this day.

Besides, we name most of our Zimbra servers after wines, and clients seem to enjoy that!

I like your creativity! Final thing I can think of to wrap up my PITA thread

I googled, but I want to verify that it is best practice to have abuse and postmaster addresses for every domain you host (the root and admin accounts are only necessary for the "master" domain), yes?

Yes, you should have abuse (required by the RFCs) and postmaster accounts for every domain you host.

Suggest you set up a separate mailbox on the master domain and add all those addresses as aliases. If you actually set up a mailbox called "abuse@domain.com" you will find it gets locked out periodically when mal-intentioned persons try logging in.