Cannot Verify Server Identity: Why Your Mail App Shows It and How to Fix It

• 28 June 2026
• by: Idris Mensah
• in: Email services
• Tags: cannot verify server identity, email ssl error, mail certificate
• note: no comments

You set up your email on a new device, tapped “Save,” and instead of a clean inbox you got a popup: “Cannot Verify Server Identity.” It usually arrives with a worrying line about a certificate, two buttons (often “Details,” “Cancel,” and “Trust”), and no obvious next step. If you are on an iPhone or using Apple Mail, this is one of the most common messages you will ever see during email setup.

Take a breath. This warning is almost never a sign that someone is attacking your email or that the server is broken. In the overwhelming majority of cases, it is your mail app being careful: it tried to confirm the identity of the mail server using its SSL/TLS certificate, and something about that check did not line up. The good news is that the cause is usually small and the fix is methodical. Let’s work through it together, calmly and in order.

Key Takeaways
• “Cannot Verify Server Identity” means your mail app could not confirm the mail server’s SSL/TLS certificate before connecting, so it stopped to warn you.
• The number one cause is a hostname mismatch: you typed your own domain (like `mail.yourdomain.com`) when the certificate is actually issued for your host’s server name (like `mail.yourhost.com`).
• The clean fix is to enter the exact mail server hostname your provider certifies, so the name you connect to matches the name on the certificate.
• Do not reflexively tap “Trust.” That silences the warning without fixing the mismatch and can hide a real problem.
• Other causes include expired or self-signed certificates, wrong ports, a misconfigured server, or a wrong date on your device.

What does “Cannot Verify Server Identity” actually mean?

When your mail app connects to an incoming (IMAP/POP) or outgoing (SMTP) mail server over a secure connection, the server presents an SSL/TLS certificate. Think of that certificate as the server’s ID card. Your device reads the card and asks three questions: Is this certificate issued by a trusted authority? Is it still valid (not expired)? And, critically, does the name on the certificate match the server name I was told to connect to?

If any of those answers is “no,” your mail app refuses to silently trust the connection. Instead it shows “Cannot Verify Server Identity” and waits for you to decide. This is the app doing its job. The certificate is the mechanism that prevents you from unknowingly sending your password and email to an impostor server, so the app would rather interrupt you than guess.

The phrase “verify server identity” is the key. Your device is not saying the email is dangerous. It is saying it could not prove who the server is to its own satisfaction, given the information you provided.

Why does the “cannot verify server identity iphone” warning happen?

There are a handful of distinct causes, and they are worth separating because each has a different fix. The most common, by a wide margin, is the first one.

1. Wrong mail server hostname (the #1 cause). You entered your own domain as the server name, for example `mail.yourdomain.com`, but your host’s certificate is issued for its own server name, like `mail.yourhost.com` or `server123.yourhost.com`. The certificate is perfectly valid, just not for the name you typed. The app correctly notices the names do not match.
2. Self-signed or untrusted certificate. The server is using a certificate that was not issued by a recognized certificate authority, so your device has no chain of trust to follow.
3. Expired certificate. The certificate was valid once but has lapsed, and the host has not renewed it.
4. Hostname mismatch on the server side. The server’s certificate genuinely does not cover the address it answers on, even if you typed everything correctly. This is an owner/admin problem, not a you problem.
5. Server actually misconfigured. SSL is set up incorrectly, or the wrong certificate is installed for that mail service.
6. Wrong date or time on your device. If your device clock is badly off, it may think a valid certificate is expired or not yet valid.

Here is the insight that resolves most of these cases at once: “Cannot Verify Server Identity” is almost never a sign that your email is unsafe or the server is broken. It is overwhelmingly a name mismatch. Your mail app is connecting to a server whose SSL certificate was issued for a different hostname than the one you typed. The classic case is this: your host’s mail server certificate is valid for something like `mail.yourhostingprovider.com`, but you set up your account using `mail.yourdomain.com`. The app correctly notices the name on the certificate does not match what you asked for, and it flags it. The clean fix is *not* to tap “Trust” (which silences the warning without fixing the mismatch). The fix is to enter the exact server hostname your host certifies, so the name you connect to matches the name on the certificate. Match the hostname to the certificate, and the warning vanishes the right way, with security fully intact.

Is it me or is it the server?

Before you start changing settings, it helps to know which side of the connection owns the problem. This quick read saves a lot of time.

• It’s probably you (a settings fix) if the warning only shows on your device, the error names a hostname that you recognize as something you typed, or you used your own domain as the server name. This is the good kind of problem because you can fix it yourself in minutes.
• It’s probably the server if every device and every user gets the warning, the certificate is genuinely expired, or your host confirms the certificate does not cover the hostname they told you to use. In that case the fix lives with whoever administers the mail server.

If you are the account owner on shared or managed hosting, the practical move is to first get the correct settings right on your device, and only escalate to your host if those correct settings still produce the warning.

How do I fix “Cannot Verify Server Identity”? (step by step)

Work through these in order. Most people are fixed by step 1 or 2.

1. Use the exact mail server hostname your host specifies. This is the real fix for the most common cause. Open your account settings and check both the incoming and outgoing server fields. If they show your own domain (`mail.yourdomain.com`, `imap.yourdomain.com`), replace them with the precise server hostname your host provides (often something like `mail.yourhost.com` or a specific server name). When the name you connect to matches the name on the certificate, the warning disappears for the right reason. If you are unsure of the exact value, your host’s control panel or support team can give you the certificate-matched hostname.
2. Verify your incoming and outgoing server settings. Confirm the incoming server type (IMAP is recommended for multi-device use), your full email address as the username, and the same correct hostname in both incoming and outgoing sections. A surprising number of “cannot verify” errors are really one field copied wrong. For a deeper walkthrough, see your provider’s email settings reference.
3. Check SSL and port settings. Secure email uses specific ports. Confirm IMAP over SSL/TLS on port 993, and SMTP on port 465 (SSL) or 587 (STARTTLS). Make sure SSL/TLS is enabled rather than disabled. If you pick a plain, non-secure port, you either lose encryption or the handshake behaves unexpectedly.
4. Do not blindly tap “Trust.” It is tempting, and on rare, well-understood cases (a server you personally administer with a self-signed certificate) it can be acceptable. But tapping “Trust” on a mismatch does not fix the mismatch. It tells your device to ignore the very check that protects your credentials. Only accept an untrusted certificate when you genuinely know and control the server and understand why its certificate is the way it is.
5. Update your operating system and mail app. Certificate-handling and the list of trusted authorities are updated through OS updates. An out-of-date device can reject perfectly valid modern certificates. Install pending updates and try again.
6. Check your device date and time. Set them to automatic. A clock that is days or years off will make valid certificates look expired or not-yet-valid, producing the exact same warning. This is a small step that occasionally solves a baffling case.
7. Remove and re-add the account. If a setup got saved with a bad hostname, editing it sometimes does not fully refresh the stored certificate decision. Deleting the account and adding it cleanly with the correct, certificate-matched settings clears that out.

For the underlying concepts behind ports and encryption, a focused read on SMTP and SSL settings will make the choices above feel obvious rather than memorized.

What should the server owner check?

If you administer the mail server (or you are the domain owner working with your host), the fix is to make sure the certificate covers the hostname your clients actually connect to.

1. Confirm a valid certificate is installed for the mail service specifically, not just for the website.
2. Confirm the certificate covers the hostname you give to users. If you tell people to use `mail.yourdomain.com`, the certificate must include that name. If your certificate only covers the host’s generic server name, either point users to that exact name or issue a certificate that covers your domain’s mail hostname.
3. Renew before expiry and automate renewal so a lapse never reaches your users.
4. Verify the certificate chain is complete so client devices can follow it to a trusted root.

The cleanest outcome is a mail server with a valid, properly-scoped certificate plus clear instructions telling every user the exact hostname that matches it. When those two things line up, nobody ever sees the warning.

Cause and fix at a glance

Cause	What’s happening	Fix
Wrong server hostname (most common)	You typed `mail.yourdomain.com`; cert is for `mail.yourhost.com`	Enter the exact certificate-matched hostname your host specifies
Self-signed / untrusted certificate	Cert not issued by a trusted authority	Install a trusted certificate (owner); only “Trust” if you control the server
Expired certificate	Cert lapsed and was not renewed	Owner renews the certificate; automate renewal
Hostname mismatch on server	Cert does not cover the address it answers on	Owner re-issues a certificate covering the right hostname
Server misconfigured	Wrong/incomplete SSL setup or chain	Owner reinstalls correct cert and full chain
Wrong device date/time	Clock skew makes valid cert look invalid	Set device date and time to automatic
Wrong port / SSL off	Insecure or mismatched port settings	Use IMAP 993, SMTP 465/587 with SSL/TLS on

Why getting this right matters for professional email

A single device showing “Cannot Verify Server Identity” is annoying. But the same root cause, a certificate that does not cleanly match the hostname your team uses, scales into a real headache once several people, phones, laptops, and mail apps are involved. Everyone hits the same wall, and well-meaning users start tapping “Trust” just to make it go away, which quietly erodes the security your certificate was supposed to provide.

This is why professional email on your own domain deserves a properly-certified mail server and clear, certificate-matched settings handed to every user. For the full picture of running email well on your own domain, our complete guide to professional business email hosting walks through the foundations, from setup to security.

How DarazHost keeps your devices warning-free

DarazHost provides the exact, certificate-matched mail server hostnames and settings for your email, so your devices connect to a properly-certified server with no identity warnings. Every mailbox is backed by free SSL on the mail server, and our 24/7 support team will give you the precise IMAP and SMTP host, port, and security settings for any device you use. Instead of guessing at hostnames and gambling with the “Trust” button, you get the one correct configuration that makes the warning disappear the right way, with security fully intact.

Frequently asked questions

Is it safe to tap “Trust” on “Cannot Verify Server Identity”? Only when you genuinely know and control the server, such as a personal server with a self-signed certificate you set up yourself. For ordinary email accounts, tapping “Trust” hides a mismatch rather than fixing it and weakens the protection on your credentials. Fix the hostname instead.

Why does only my iPhone show this when my laptop is fine? Different mail apps and operating systems enforce certificate checks with different strictness, and they may store the settings slightly differently. iPhone and Apple Mail are notably strict about hostname matching, so an error that one device tolerates will be flagged loudly by another. The underlying fix, a matched hostname, is the same.

Can a wrong date on my phone really cause this email certificate error? Yes. Certificates are only valid within a date range. If your clock is badly wrong, your device may conclude that a perfectly valid certificate is expired or not yet active, producing the same warning. Setting date and time to automatic rules this out.

What’s the difference between “mail server certificate not trusted” and a hostname mismatch? “Not trusted” usually means the certificate’s issuer is not in your device’s list of trusted authorities (often a self-signed certificate). A hostname mismatch means the certificate is trusted and valid but issued for a different name than the one you connected to. Both surface as “Cannot Verify Server Identity,” but the mismatch is far more common and is fixed by correcting the hostname.

I corrected the hostname and still get the warning. Now what? At that point the problem is likely on the server side: an expired certificate, an incomplete chain, or a certificate that does not cover the hostname your host told you to use. Contact your host with the exact error text and the hostname you are using, and ask them to confirm the certificate covers it.