Fix SSL "Certificate Name Mismatch" Warnings on Mail

A customer called in last week convinced their email had been hacked. Outlook kept throwing a red padlock warning every time Send/Receive ran: "The server you are connected to is using a security certificate that could not be verified... the name on the certificate is invalid." Nothing was actually broken — their mail was flowing fine. The certificate on the mail service just didn't match the hostname their mail client was using to connect. Here's what's really going on and how to make the warning go away for good, not just click through it.

Symptom: What You're Actually Seeing

This shows up a little differently depending on the client:

• Outlook: "The server you are connected to is using a security certificate that could not be verified" with a mismatch reason, often triggered on every Send/Receive cycle.
• Thunderbird: "This site uses a certificate that is not valid... The certificate is only valid for the following names: server123.yourhost.com" instead of mail.yourdomain.com.
• iPhone/Android Mail: "Cannot Verify Server Identity" with a "Details" screen showing a completely unfamiliar hostname.

The giveaway is always the same: the certificate the mail client received belongs to some other hostname — usually the server's own name, like server123.yourhostingcompany.com or box456.skyserver.in — not the domain you typed into your email settings.

Cause: Your Mail Client Is Connecting to the Wrong Name

On shared cPanel hosting, dozens (sometimes hundreds) of domains sit on one physical server. That server has exactly one hostname, and AutoSSL issues a genuine, trusted certificate for that hostname. When your mail client is configured to connect to mail.yourdomain.com or yourdomain.com for IMAP/SMTP, the mail service still answers — but it presents the server's own certificate, because that's the one it has. The name on the cert (the server hostname) doesn't match the name you dialed (your domain), so TLS validation fails on the hostname check even though the connection itself is encrypted correctly.

This is not a hack, not malware, and not a sign your site is compromised. It's a mismatch between what you told the mail client to connect to and what certificate actually covers that address. Three things commonly trigger it:

• Auto-configuration (Outlook's autodiscover, or a phone's built-in mail setup) guessed mail.yourdomain.com instead of the real server hostname.
• An old client profile was set up years ago using the domain name, before you understood the shared-server SSL scope.
• Someone copied "mail.yourdomain.com" out of a generic setup guide instead of checking the actual recommended settings in cPanel.

Fix 1: Point the Mail Client at the Server's Real Hostname

This is the fastest, zero-cost fix and the one we recommend to most shared-hosting customers. cPanel already tells you the correct value:

1. Log in to cPanel → open Email Accounts.
2. Click Connect Devices next to the mailbox in question.
3. Note the Mail Client Manual Settings block — it lists the exact incoming/outgoing server name (something like server123.yourhostingcompany.com) that matches the SSL certificate.
4. In Outlook/Thunderbird/your phone's mail app, edit the account and replace both the incoming (IMAP/POP) and outgoing (SMTP) server fields with that exact hostname.
5. Keep "Require SSL/TLS" enabled and use the ports below.

Because the hostname now matches the certificate's Common Name/SAN entry exactly, the warning disappears — no plugin, no purchase, no waiting.

Fix 2: Get a Certificate That Actually Covers mail.yourdomain.com

If you'd rather keep using your own domain name for mail settings (useful if you're documenting instructions for staff, or the server hostname looks unprofessional in error messages), you need a certificate that covers mail.yourdomain.com specifically:

• AutoSSL: cPanel's AutoSSL will automatically include mail.yourdomain.com as a Subject Alternative Name if that subdomain resolves to the server and the domain is active on the account. Check SSL/TLS Status in cPanel, tick the domain, and click Run AutoSSL if it isn't already covered.
• DNS check first: make sure mail.yourdomain.com has an A record pointing at the server (or is covered implicitly because it resolves the same as the main domain). AutoSSL can't secure a hostname it can't validate over HTTP.
• CAA records: if your zone has a CAA record restricting issuance to a specific CA, confirm it allows Let's Encrypt (or whichever CA AutoSSL uses) — otherwise validation silently fails.

Once AutoSSL reissues with mail.yourdomain.com in the SAN list, existing client configs using that hostname stop throwing the warning — no client-side changes needed.

Fix 3: Clear a Stale Autodiscover/Autoconfig Cache

Outlook and some mobile clients cache autodiscover results aggressively. If you've already fixed the certificate or switched hostnames and the warning persists:

• Outlook: close it, delete the account profile, and recreate it manually rather than editing in place — cached autodiscover XML can reapply the wrong server name.
• Android/iOS: remove the mail account entirely and re-add it, rather than editing existing settings.
• Check for a stale autodiscover.yourdomain.com or SRV record pointing somewhere unexpected — this is a separate but related cause worth ruling out.

Prevention

A few habits keep this from coming back:

• Always pull mail settings fresh from cPanel's Connect Devices screen rather than reusing an old setup guide or a colleague's config.
• If you migrate to a new server or change hosting providers, re-check the server hostname in mail client settings — it changes even if your domain doesn't.
• If you standardize on mail.yourdomain.com for all staff, verify AutoSSL has actually issued for that name after any DNS changes, since a moved A record can silently drop it from the next AutoSSL run.
• Document whichever approach you pick (server hostname vs. domain-based) so the next person setting up a mailbox doesn't reintroduce the mismatch.

Frequently Asked Questions

Is this warning a sign my email was hacked?

No. It's purely a hostname-vs-certificate mismatch. Your traffic is still encrypted; the client is just refusing to trust the name on the certificate. If you're worried, verify the certificate details shown in the warning belong to a legitimate hosting-related hostname, not something unfamiliar or unrelated to your host.

Why does the certificate show the server's hostname instead of my domain?

Because on shared hosting, one SSL certificate (issued to the server's own hostname) covers mail services for every domain on that server by default. Your domain only gets its own name on the certificate if AutoSSL has specifically issued a SAN entry for mail.yourdomain.com.

Will switching to the server hostname break my email in the future?

Only if you change hosting providers or the server is decommissioned, at which point you'd update settings anyway during migration. For day-to-day use on the same host, the server hostname is stable and won't change unexpectedly.

Can I just ignore the warning and click through it?

You can, and mail will keep working, but most clients will keep nagging on every sync and some mobile clients refuse to proceed without re-confirming trust repeatedly. It's a five-minute fix, so there's little reason to live with it.

Does this affect webmail (Roundcube/Horde) too?

Rarely — webmail is usually accessed via the browser at a URL that already matches the AutoSSL-covered hostname, so this specific warning is almost always a desktop/mobile mail client issue, not a webmail one.