How to Connect a Self-Hosted Mail Server to a Modern Email Client

Running your own mail server is the easy part compared to what happens next: getting Outlook, Apple Mail, Thunderbird, and a phone to actually talk to it. Most of the pain isn't the server — it's a client rejecting a certificate it doesn't recognize, or a login that fails because the auth mechanism doesn't match what Dovecot offers.

This is the last-mile setup: hostnames, TLS, ports, and authentication, in the order that actually gets you connected on the first try.

Before you start: what you need from the server#

You need four pieces of information before opening any client, and guessing at them is where most failed setups start.

• The mail server's hostname exactly as it appears on the TLS certificate — for example mail.yourdomain.com, not the bare IP address
• IMAP and SMTP port numbers the server is actually listening on (check with a config dump or a port scan, don't assume defaults)
• Which encryption the server expects on each port: implicit TLS or STARTTLS
• Whether the certificate is from a public CA (Let's Encrypt) or self-signed — this changes whether the client trusts it automatically

You can get the first two straight from the server instead of guessing. Run doveconf -a | grep -A2 ssl_cert to see which certificate file Dovecot is actually presenting, then openssl x509 -in <that path> -noout -subject -ext subjectAltName to read the exact name or names a client has to match. A hostname that isn't in that output will always trigger a mismatch warning, no matter how confident the config file looks.

For ports, ss -tlnp | grep dovecot (or netstat -tlnp on an older distribution) lists what the process has actually bound to. A config file can declare a port that the running service never opened — usually after an edit that needed a restart it didn't get — and a port scan from the config alone won't catch that.

Does my mail server need autodiscover?#

No, but without it you're typing every setting by hand. Autodiscover (Microsoft's protocol) and Autoconfig (Mozilla's, used by Thunderbird) let a client find IMAP/SMTP settings from just an email address and domain.

Dovecot and Postfix don't include either out of the box. Some Mailcow and iRedMail builds add an autoconfig XML file at a well-known URL, but a plain Postfix-and-Dovecot install almost never has it. If your client asks for an email and password and finds nothing, that's expected — switch to manual setup instead of troubleshooting a feature you never enabled.

Steps: connecting the client#

1. 1

   Choose manual/advanced account setup

   Skip the client's auto-configuration wizard. It will try Autodiscover or Autoconfig, fail silently or with a vague error, and waste ten minutes before you reach the manual form anyway.

2. 2

   Enter the incoming server (IMAP)

   Hostname: the exact name on your certificate. Port 993 with SSL/TLS (implicit), or port 143 with STARTTLS if 993 is closed. Username is normally your full email address, not just the local part.

3. 3

   Enter the outgoing server (SMTP)

   Port 465 with implicit TLS, or port 587 with STARTTLS — never port 25 for client submission; that port is for server-to-server relay and most providers block outbound connections to it anyway.

4. 4

   Set the authentication method

   Pick "Password" or "Normal password" in the client, which maps to SASL PLAIN or LOGIN on the Dovecot side. Only use OAuth-style options if your server actually runs an OAuth2 SASL mechanism, which most self-hosted stacks don't.

5. 5

   Accept or install the certificate

   A public CA cert connects silently. A self-signed cert triggers a warning — verify the fingerprint against the one printed on your server before accepting it, then move on.

6. 6

   Send a test message to yourself

   This confirms both directions at once: IMAP pulled it into the inbox and SMTP relayed it out and back in.

Where these settings actually live in each client#

The four values — hostname, port, encryption, username — are identical everywhere. What changes is which menu you dig through to enter them, and whether the client tries to hide the manual form behind an autodetect step first.

• Outlook (Windows): File → Add Account → Advanced options → "Let me set up my account manually" → Internet Email. IMAP/SMTP hosts, ports, and encryption method all sit on one screen.
• Outlook (Mac): Outlook → Settings → Accounts → + → New Account. If autodetect fails, the manual IMAP fields appear automatically on the next screen — no separate menu to find.
• Apple Mail: Mail → Settings → Accounts → + → Other Mail Account to create it, then Mail → Settings → Accounts → Account Information / Server Settings afterward to edit host, port, and TLS separately for incoming and outgoing.
• Thunderbird: Account Settings → Account Actions → Add Mail Account. Enter the password, then click "Configure manually" before Thunderbird finishes its own autodetect — editing settings after autodetect already succeeded is harder than starting manual.
• K-9 Mail / FairEmail (Android): both walk through a full manual wizard with separate certificate-trust prompts for IMAP and SMTP. Accept each one individually — trusting the incoming server's certificate doesn't also trust the outgoing one.

Platform differences worth knowing before you configure#

The protocol is identical everywhere, but where the settings live — and how forgiving the client is about a mismatched certificate — varies enough to change your setup order.

What the manual settings screen looks like#

Every client's manual setup screen is asking for the same four things, just arranged differently: hostname, port, encryption method, and username. Once you recognize the pattern, filling in a client you've never used before is mostly a matter of finding where it hid the fields.

IMAP TLS certificate error in email client: what it actually means#

A TLS error is the client telling you the certificate presented by the server doesn't match what it expected — not that encryption itself failed. Three causes cover almost every case.

• Hostname mismatch — you connected to mail.yourdomain.com but the certificate was issued for a different name, often the server's bare hostname like host.provider.net
• Self-signed or private-CA certificate — valid encryption, just not signed by an authority the client's trust store already recognizes
• Expired certificate — Let's Encrypt certs renew every 90 days; a broken renewal cron job is the single most common cause of a cert that worked last month and doesn't today

Installing a self-signed certificate so clients stop warning#

A warning on every connection isn't dangerous by itself, but it trains you to click through security prompts without reading them — a bad habit for the one time the warning is real. Installing the certificate as trusted removes it permanently instead of dismissing it each time.

• Windows: open the certificate file (or export it via certmgr.msc), then import it into "Trusted Root Certification Authorities" for the local machine, not just the current user, if other apps on the same machine also need to trust it.
• macOS: open the certificate file in Keychain Access, locate it under the System keychain, and set its trust setting to "Always Trust".
• iOS/iPadOS: AirDrop or email the certificate to the device and install the profile under Settings, then also enable it under Settings → General → About → Certificate Trust Settings — installing the profile alone does not fully trust it for TLS.
• Android: Settings → Security → Encryption & credentials → Install a certificate → CA certificate. Expect a persistent "Network may be monitored" notice afterward; that's Android's standard warning for any user-installed CA certificate, not a sign of a problem.

What to do when it still doesn't work#

Work through causes in order of how often they're the actual problem, not in the order they feel scary.

Testing a port from the command line before you blame the client#

Before changing another client setting, confirm the server is reachable at all. This turns a vague "it doesn't work" into either a network problem or a client problem in under a minute, and it's the fastest way to rule out half the causes table above at once.

• openssl s_client -connect mail.yourdomain.com:993 — a working handshake prints the certificate chain; a hang or "connection refused" means the port isn't reachable, which isn't a certificate problem at all.
• openssl s_client -starttls imap -connect mail.yourdomain.com:143 — the STARTTLS equivalent; look for the server's greeting after the handshake completes, not just a clean exit.
• nc -zv mail.yourdomain.com 993 (or Test-NetConnection on Windows) — a fast yes/no on whether the port is open, with no TLS negotiation involved.
• Run all three from a network outside the server's own LAN. A port that's open locally but blocked at the router or a cloud provider's firewall looks identical to a client until you test from somewhere else.

A faster way to stay on top of a self-hosted inbox#

Getting IMAP and SMTP configured is a one-time job. Living in that inbox every day — sorting what matters from what doesn't, drafting replies, keeping a shared mailbox from becoming a swamp — is the part that keeps costing time after setup is done.

AI Emaily connects to any IMAP/SMTP account, self-hosted included, the same way the client you just configured does, and adds triage, drafting in your voice, and a searchable Context brain on top. Every AI action needs your approval before it sends — nothing goes out on its own — and every change is logged and reversible. We build AI Emaily, and it's a 7-day free trial on the Pro plan, card required, $0 if you cancel before day 7.