Do not accept or install the certificate; open its details, record the server Outlook is contacting and the certificate’s Subject/SAN names, then have the mail administrator or provider correct the mismatch.
Identify the mismatched connection
- In the warning, select View Certificate or Show certificate errors.
- Record:
- The server or website Outlook is trying to reach.
- The certificate Subject.
- Its Subject Alternative Names (SANs).
- Its validity dates and issuing authority.
- Compare the requested server name with the Subject/SAN entries. The exact requested hostname must be covered by the certificate.
- If this occurs on public Wi-Fi, open a public website in a browser and complete any network sign-in page. An intercepting network, proxy, DNS issue, expired certificate, or invalid certificate on the mail infrastructure can produce certificate errors.^1^
Do not choose Yes repeatedly as a permanent workaround. Outlook may display the warning again whenever Autodiscover runs.^2^
If this is a work or custom-domain account
Send the recorded hostname and certificate names to the Microsoft 365, Exchange, DNS, or email administrator.
The administrator should check:
- Whether the domain’s Autodiscover DNS records lead to the intended Exchange or Microsoft 365 endpoint.
- Whether a proxy, firewall, web server, or other unintended host is answering the HTTPS request.
- Whether the certificate bound to that endpoint is current and contains every hostname Outlook uses.
- Whether the certificate chain is trusted.
If the specific environment has DNS and IIS on the same server, an NS record for that server, and SSL enabled in IIS, Microsoft documents this exact warning as an Autodiscover collision. Supported corrections include reissuing the certificate with the domain as a SAN, separating IIS and DNS, removing an unnecessary SSL binding, or configuring Outlook for a specific endpoint.^2^
DNS changes should be handled by the administrator and tested before deployment. Incorrect Autodiscover records can stop Outlook account discovery.
If your organization intentionally uses a self-signed certificate
Installation is appropriate only when all of these are true:
- The service is an organization-controlled, non-Microsoft 365 mail server.
- The displayed server name is correct.
- The certificate is valid by date.
- The only reported problem is an untrusted signing authority.
- Your administrator has confirmed the certificate or deployed its trusted root.
A certificate cannot be fixed by installing it when its hostname is wrong or it has expired. Outlook’s certificate-install option is unavailable for those conditions.^1^
If only this Windows profile is affected
After the server name and certificate have been confirmed as correct, test a clean Outlook profile:
- Close Outlook.
- Open Control Panel → Mail (Microsoft Outlook) → Show Profiles.
- Select Add, create a profile, and add only the affected account.
- Choose Prompt for a profile to be used.
- Start Outlook and select the new profile.
If the warning remains in a new profile, escalate it with the captured certificate details to the email provider or administrator; do not bypass the warning. Creating a fresh profile is a documented client-side test, but it does not repair a server-side hostname mismatch.^3^
References
- How to resolve certificate errors | Microsoft Support
- Resolve AutoDiscover mismatch warning in Outlook
- Invalid Certificate in Outlook - Microsoft Q&A