Mail SSL Certificate Mismatch: Fix the Outlook Warning

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:

1. 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).
2. Wait for DNS to propagate — usually 15–30 minutes with a low TTL, sometimes longer. Confirm with dig mail.yourdomain.com +short.
3. 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.
4. 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

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.