Why does Outlook say the certificate name doesn't match, even though mail still works?

Because the mail server is presenting a certificate issued for a different hostname (usually the server's own hostname) instead of one issued for mail.yourdomain.com. Mail still flows because the connection is still encrypted — the client is just warning you that it can't confirm the name matches, which it shouldn't have to do.

Is it safe to just click 'Accept the risk' and continue?

It'll keep working, but you're bypassing the one check that confirms you're actually talking to your real mail server and not something impersonating it. It's fine as a very short-term workaround, but fix the underlying certificate rather than clicking through it indefinitely.

Should I use mail.yourdomain.com or the server hostname for my mail client?

Either works once the certificate matches. The server hostname (from cPanel → Email Accounts → Connect Devices) is guaranteed to have a valid matching certificate at all times, so it's the more resilient choice if you don't want to think about this again after a migration.

I added the A record but AutoSSL still didn't pick up mail.yourdomain.com. Why?

Check WHM's AutoSSL settings for "Auto-secure additional mail domains" — if it's off, cPanel will secure your main domain and www but deliberately skip the mail subdomain. Turn it on and rerun AutoSSL for the account.

Does this affect webmail (roundcube/horde) too, or just desktop/mobile clients?

Webmail accessed at yourdomain.com/webmail rides on your main domain's certificate, so it's usually unaffected. This issue is specific to connecting a mail client directly to mail.yourdomain.com over IMAP, POP3, or SMTP.

Fix Mail Server SSL Certificate Mismatch

You set up your mailbox in cPanel, pointed Outlook or Thunderbird at mail.yourdomain.com, and everything works — except every single time the client connects, you get a scary certificate warning. Mail still sends and receives fine if you click through it, which is exactly why it's tempting to ignore. You shouldn't: it means your mail traffic isn't verified against the name you're connecting to, and it'll keep popping up (or get worse) until you fix the actual mismatch.

Symptom: "certificate name mismatch" when connecting to mail.yourdomain.com

The warning shows up slightly differently depending on the client, but it's the same underlying problem:

Outlook: "There is a problem with the site's security certificate... the security certificate was issued by a company you have not chosen to trust" or "the name on the certificate is invalid or does not match the name of the site."
Thunderbird: "mail.yourdomain.com uses an invalid security certificate... the certificate is only valid for the following names: server123.yourhost.com"
iPhone/Android Mail: "Cannot Verify Server Identity" with a "Details" screen showing a different hostname than the one you typed in.

Notice the pattern — the client is telling you it received a certificate, just not one issued for the name you connected with. That's the whole bug.

Cause: the mail server is presenting the wrong certificate for that name

cPanel mail services (Dovecot for IMAP/POP3, Exim for SMTP) use SNI (Server Name Indication) to decide which SSL certificate to hand back when a client connects. If a certificate exists for the exact hostname you're connecting to, it gets served. If not, Dovecot and Exim fall back to the server's own hostname certificate — something like server123.yourhostingcompany.com — which obviously doesn't match mail.yourdomain.com.

This happens for one of a few reasons:

No A record for the mail subdomain. Most DNS setups only add an MX record pointing mail delivery at the server, without ever creating an actual A record for mail.yourdomain.com. AutoSSL can only issue a certificate for a name it can validate over HTTP, and it can't validate a name that doesn't resolve.
AutoSSL's "additional mail domains" option is off. Even with the A record in place, WHM only auto-secures the mail. subdomain if "Auto-secure additional mail domains" is enabled under AutoSSL settings. On some accounts it isn't.
The domain moved servers recently. After a migration, DNS may still point mail.yourdomain.com at the old IP, or the new server hasn't run AutoSSL for that domain yet, so the client keeps landing on whatever certificate the server currently has.
Self-managed VPS with Postfix/Dovecot. If you're not on cPanel and manage mail yourself, the certificate paths in dovecot.conf or master.cf may still point at a self-signed cert or an old Let's Encrypt cert that never covered the mail hostname.

Fix 1 (fastest): connect using the server's actual hostname

Every cPanel account has a server hostname — something like server123.getwebup.in — that already has a valid, correctly-matched SSL certificate. You can find it, along with the exact ports, in cPanel → Email Accounts → click the mailbox → Connect Devices. Swap out mail.yourdomain.com for that hostname as your incoming/outgoing server in Outlook, Thunderbird, or your phone's mail settings, and the warning disappears immediately because the certificate name now matches what you typed.

This is a legitimate permanent fix, not just a workaround — plenty of hosts recommend using the server hostname specifically because it's the one guaranteed to stay correctly certified even if a customer's own domain SSL lapses.

Fix 2: get mail.yourdomain.com properly covered by AutoSSL

If you'd rather keep using your own domain name for mail (cleaner for staff who expect mail.yourdomain.com), fix the certificate instead:

In cPanel → Zone Editor, add an A record for mail pointing at your server's IP address (the same IP your domain's main A record uses).
Wait for DNS to propagate — usually 15–30 minutes with a low TTL, sometimes longer. Confirm with dig mail.yourdomain.com +short.
In cPanel, go to Security → SSL/TLS Status, find mail.yourdomain.com in the list, tick it, and click Run AutoSSL. On WHM (if you manage the server), you can also run it per-account under SSL/TLS → Manage AutoSSL → Run AutoSSL.
Give it a few minutes, then reconnect your mail client. Dovecot and Exim pick up the new certificate without a restart in most CloudLinux/cPanel setups; if the warning persists after 10–15 minutes, ask your host to confirm the cert was issued and bound to the mail service.

If you're on WHM and manage the server yourself, also check WHM → SSL/TLS → Manage AutoSSL → Additional Options and make sure "Auto-secure additional mail domains" (sometimes labeled "Include mail.* subdomains") is checked. Without it, AutoSSL will happily secure yourdomain.com and www.yourdomain.com but skip mail.yourdomain.com even with a valid A record.

Fix 3: self-managed VPS running Postfix and Dovecot

If you're not on cPanel, request or renew a certificate that actually covers the mail hostname, then point both services at it:

certbot certonly --standalone -d mail.yourdomain.com

# Dovecot: /etc/dovecot/conf.d/10-ssl.conf
ssl_cert = </etc/letsencrypt/live/mail.yourdomain.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.yourdomain.com/privkey.pem

# Postfix: /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.yourdomain.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.yourdomain.com/privkey.pem

Restart both services after the change:

systemctl restart dovecot postfix

Verify the fix from the command line

Don't just trust the mail client — check what certificate the server is actually presenting for that name:

openssl s_client -connect mail.yourdomain.com:993 -servername mail.yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer

The subject line should show mail.yourdomain.com (or a wildcard covering it). If it shows your server's hostname instead, the certificate still hasn't switched over — give AutoSSL another run or double-check the A record actually resolves to the right IP.

Quick reference

Situation	What to check	Fix
No A record for mail subdomain	`dig mail.yourdomain.com`	Add A record in Zone Editor, then run AutoSSL
A record exists, warning persists	AutoSSL > Additional mail domains setting	Enable it, rerun AutoSSL
Just migrated hosts	DNS still pointing at old server	Update A/MX records, wait for propagation, rerun AutoSSL
Don't want to wait / just need it working	—	Use the server hostname from Connect Devices instead
Self-managed VPS	Dovecot/Postfix cert paths	Issue cert for mail.yourdomain.com, update config, restart services

Prevention

Add the A record for your mail subdomain the same day you set up hosting — not after the first support ticket. If you're a Getwebup customer, we add this automatically on new accounts, but if you migrated DNS elsewhere or manage your own zone, it's worth a 30-second check. And if you ever move hosting providers, treat the mail SSL certificate as part of the migration checklist alongside the website's own SSL — it's easy to remember the site and forget the mailbox.

Mail SSL Certificate Mismatch: Fix the Outlook Warning