hi guys, I have struggled with this for hours and am no closer to a resolution in my mind. when setting up a shared Webhosting server that also provides email, I am struggling to know whether one should have domains on the server using: A. incoming and outgoing mail server as mail.clientsdomain.com or B incoming and outgoing mail server as host.fqdn.com the reason I am asking about this is that the Microsoft Outlook app on mobile phones appears to be an absolutely finicky program to configure and seems to automatically want to use mail.clientsdomain.com as the incoming and outgoing mail server. when I go into thunderbird on a desktop pc, I am finding that the auto-detect is about as reliable as a water bucket with holes in it...sometimes it detects, other times one has to stuff around with options to get it to select the option that I know works (even though initially thunderbird says it doesn't). so what are the failsafe mail server settings to use for hosting client's mail? Where is the best place to find the right tutorial on configuring the best setup for email for many domains?
Search for e-mail autodiscovery or autoconfigure, that is a method on the e-mail server side to set it up so clients autoconfigure settings given the domain name.
Apparently in cpanel you can have multiple domains with email ssl certificates on a single IP address (shared hosting). I didn't think postfix + dovecot could do this? How can I configure my server so shared hosting clients can all have their own SSL that works with email Ie clients use their own mail.client1domain.com, mail.client2domain.com etc, for incoming and outgoing mail server in Outlook? Or is this unworkable and I need to go with host.fqdn.com for incoming and outgoing mail server for clients Outlook app? Also, point me to best tutorial for configuring the shared hosting mail server for the above (I don't host DNS, that is external at clients domain registrars)
This works with postfix and dovecot as well, just add all subdomains used for email to a single ssl cert, e.g. an LE ssl cert. But there is a limit of max. 100 domains in a cert. But personally, I won't go that route and I don't do it on any server. My servers have a single domain ssl cert for the hostname of the server. When you are the hoster, then its absolutely fine in my opinion when your customers use a subdomain of your host domain as connection details in their mail client, this evens strengthens your brand and it's the way larger ISP's handle it. E.g. when you use the google gsuite business accounts, then your mail server is smtp.gmail.com and not a subdomain of your own domain and when you use outlook365 then the smtp and pop servers are smtp.office365.com and outlook.office365.com as well and not your own domain.
Ah ok. Why is it that some control panel auto installers for mail clients such as rhunderbird, or outlook, or windows 10 mail, insist on setting the incoming outgoing to mail.clientdomain.com instead of hostname.fqdn.com (mail server itself). Are they doing this because the expectation is that clients will purchase additional IP address for their domain? How many clients actually do this on shared hosting? Isn't the idea of shared hosting mainly because clients are trying to save money and don't want their own ip address? Finally, if I set incoming/outgoing to host.fqdn.com , the email client gets authentication errors....as soon as I use mail.clientdomain.com (same username and password) it works.i don't understand why this happens? Is the the host SSL cert causing this? The host.fqdn.com ssl is fqdn.com. does it need to be host.fqdn.com?
The simple reason is, they don't know the right name, unless you do what @Taleman suggested in #2, the topic is named autodiscovery. That's not directly related. Actually larger hosters will do what I suggested, if you have more then lets say 5 or 10 clients, you will use a central mail server and mail server name. No matter if you sell shared hosting or not. You will not use any subdomains of client domains to name or access your central mail server. when you installed your server correctly, then the ssl cert of the mail system contains the server hostname and only the server hostname. If your cert contains fqdn.com but not the mail server hostname, then you installed a wrong ssl cert in your mail system.
ok, so if my server/mail server is host1.apples.com with IP 12.34.56.78, in order to ensure this works without errors is the following correct... 1. host1.apples.com would need an SSL certificate for apples.com 2. apples.com would need to be a virtual host on the system and that SSL set to be used by postfix 3. client.com dns would need to be: - A Record client.com points to 12.34.56.78 - MX Record client.com points to host1.apples.com 10 What would happen if the client MX Record is as follows -MX Record client.com points to mail.client.com Even if client.com had its own hosting SSL cert, would the above dns record throw SSL certificate errors and authentication errors on email client apps (such as outlook on mobile phone) because my server only has a single ip address for all clients? If i change the mxrecord at my clients registrar to host1.apples.com, will it stop their mail client applications from working (because they were setup when dns mxrecord was mail.clientdomain.com)
No. The SSL certificate has to fit the domain one is connecting to. If you set your mx to host1.apples.com, then the other servers or your users are connecting to host1.apples.com and surely want to have a certificate that is valid for host1.apples.com. Depends on your configuration. The webserver needs to know, it is responsible for local delivery of apples.com. The SSL certificate needs to be valid for the domain, the others are connecting to. If you want them to connect to mail.domain.com, then they want to see a certificate for mail.comain.com A record points to the web servers IP address MX record points to the mail servers host name A record of the mail servers host name points to the mail servers IP address If a mail is being sent to [email protected], then the sending server will make a DNS request for the MX record of client.com. It will get mail.client.com and will do a DNS request for the A record of mail.client.com. This will return an IP address and the server will try to connect to that and deliver the email. This server needs then a SSL certificate, valid for mail.client.com Changing your mx record will not change anything for your clients. The MX record is only being used by other mail servers to determine where to send mails to. Look here: https://practical365.com/exchange-server/mx-record/
ah i think i understand that. essentially, my hosting server is also a mail server. Therefore all client domains on my server will need an mxrecord pointing at it. because the client domains are not purchasing their own ip addresses for domains, they are using my server one. This means that Postfix must provide the my webhosting/mail server SSL certificate only for client emails. I will get my client to change their dns record to reflect that because currently they are using mail.clientdomain.com (which obviously doesnt have a valid SSL for postfix). Can i ask, what role does dovecot play in SSL for client email apps such as outlook? Dovecot can have multiple SSL certs on a single ip address yes? Isnt Dovecot what is being used to download the messages via IMAP to client email apps? In Dovecot, all my client domains have their own SSL certs. so is my clients Outlook email mobile phone app issue (invalid SSL cert) a postfix one or dovecot?
