I couldn't find any information related to my problem, so I hope you can help me find out a solution for it.

We are working with an Exchange Server 2016 in a company that has a domain in a registrar (managed by a 3rd party company) with a redirect on root domain to second domain which hosts a website.

Let's say our client has a domain company.comand points to a website hosted in secondarydomain.com

Now, they wanted to control the email flows, add some security and "unlimited" mailbox space on their accounts, so they asked us to install an email service in their servers using company.com domain, which is the current domain used for their email accounts hosted outside.

The problem I'm facing is with the certificate. Companies usually offer certificates for Exchange Servers, which most are wildcard domain certificates (*.company.com). The problem with that is that we tried to use a Let'sEncrypt certificate for testing purposes with a wildcard domain and we couldn't make it work. Our Exchange Server is accessible from outside using exchange.company.com and points to an A record XXX.XXX.XXX.XXX, but when Outlook tries to compare the certificate retrieved from exchange.company.com with the root domain of the certificate (company.com), which is a redirect to the webserver on YYY.YYY.YYY.YYY, certificate cannot be verified.

This comes into an Outlook constantly asking if you "accept the certificate and keep using Outlook at your own risk", because the certificate in that webserver does not cover any domain/subdomain in company.com.

Any workaround/suggestion to make the certificate work as expected with Exchange Server hosted in my client's company and his website in their registrar?


As mentioned before, we also offer domain registration and management, so any kind of redirects or whatever is required to point to that server, but keeping company.com domain for email addresses (like Office 365) could be a solution, but I don't know if it is possible to achieve, if we need to attach a wildcard certificate for the root of that domain used for redirects nor if a service installed in a server for redirecting is required.


If you want to use Office 365 without changing your registrar, you need to do configure your DNS to something like:

company.com    MX    <token MX>.mail.protection.outlook.com
Autodiscover   CNAME autodiscover.outlook.com
@              TXT   v=spf1 include:spf.protection.outlook.com -all

Instead of using Outlook, configure our own DNS to resolve in a similar way.

  • Can you point the DNS entry exchange.domain.com to the internal IP? – HannesS May 6 at 14:49
  • @HannesS I could, but will break Outlook outside using OWA/Autodiscover, because they are accessing outside using the same subdomain, so my problem doesn't get solved so easy. Also, server should be accessible from outside with SSL protection. "Security" first, always :) – DaGLiMiOuX May 6 at 22:34
  • Have you used the test Email Autoconfiguration to view the process of connectivity? What's the autodiscover address? You can post the results here. – joyceshen May 7 at 6:00
  • @DaGLiMiOuX - I'm suggesting a split-brain DNS here, sorry, maybe not written clear enough ;-) You can point your internal DNS to the internal IP, leaving everything from external the same. I believe you have an ActiveDirectory DNS Server on site, so you can add a zone like "exchange.domain.com" and point the @ record to your internal IP. Outlook clients inside your network will check the autodiscover and will be redirected to the exchange internal ip, and presented the same certificate as outside clients :-) – HannesS May 7 at 6:17
  • @HannesS thank you for your suggestion. Yes, that's something we were thinking too, but what happens when clients are outside? (e.g. from their homes). Will still having the same problem with the certificate validation. Another solution would be creating a wildcard certificate, point the DNS to my public IP and redirect port 53 to my active directory DNS, install the certificate in the default site, then add a website redirect within the server. But that will incur into managing the DNS and I don't think that the 3rd party manager will agree :) – DaGLiMiOuX May 7 at 7:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.