Every mail client needs the same six facts: the incoming server's name, its port, its encryption mode, the outgoing server's name, its port and encryption mode, and the username and password. For a modern server that means IMAP on 993 with TLS from the first byte, and SMTP submission on 465 (TLS from the first byte) or 587 (plain connection upgraded with STARTTLS), logging in with the mailbox's login name. Get those six right and Thunderbird, Outlook, Apple Mail and every Android client will work. Get the encryption mode wrong for the port - the single most common mistake - and the client either hangs or reports a certificate or protocol error that tells you nothing useful.
This post covers the settings, the four clients most people use, how to make clients discover the settings on their own with autoconfig and autodiscover, and the errors you will meet on the way.
The settings every client asks for#
Mail access is two separate jobs. Reading uses IMAP (or the older POP3, or the newer JMAP), and the client talks to the mailbox server. Sending uses SMTP submission: the client hands a message to its own server, which then delivers it to the recipient's server over port 25. A client never sends to port 25 itself, and almost every residential and mobile network would block it if it tried.
| Job | Protocol | Port | Encryption | Notes |
|---|---|---|---|---|
| Read mail | IMAP | 993 | Implicit TLS | The default choice |
| Read mail | IMAP | 143 | STARTTLS | Same protocol, upgraded after connecting |
| Read mail | POP3 | 995 | Implicit TLS | Downloads and usually deletes from the server |
| Send mail | Submission | 465 | Implicit TLS | Recommended by RFC 8314 |
| Send mail | Submission | 587 | STARTTLS | Equally fine, more widely remembered |
| Server to server | SMTP | 25 | Opportunistic STARTTLS | Not for clients |
Two terms confuse people because clients name them inconsistently. Implicit TLS means the encrypted session starts immediately on connect; clients call it "SSL/TLS", "SSL" or just "TLS". STARTTLS means the connection starts in plain text and is upgraded before the password is sent; clients call it "STARTTLS" or, confusingly, also "TLS". Port 993 and 465 are implicit. Port 143 and 587 are STARTTLS. Choose "SSL/TLS" on 587 and the client waits for a TLS handshake the server will never start; choose STARTTLS on 465 and the server waits for a TLS handshake the client never sends. Both look like a timeout.
Choose IMAP over POP3 unless you have a specific reason. IMAP keeps the mail on the server and synchronises folders, read flags and sent items across every device. POP3 was designed for one computer downloading mail and deleting it from the server, which is exactly wrong for someone with a phone and a laptop. IMAP vs POP3 vs JMAP compares the three properly, including why JMAP is better on paper and still rare in clients.
The remaining fields:
- Username. Whatever the server uses as the login name. On most self-hosted servers that is the full address (
anna@example.com), but it can be a bare account name. Use what the mailbox was created with. - Password. The mailbox password. If the account has two-factor authentication, an app-specific password is usually needed for IMAP and SMTP, because neither protocol can prompt for a code.
- Authentication method. "Normal password" (Thunderbird) or "Password" (Outlook) is correct over TLS - the password is protected by the encrypted connection. The "encrypted password" options are older challenge-response schemes that many servers do not offer, and choosing one the server does not support produces an authentication failure with a correct password.
- Outgoing authentication. Always on, with the same credentials. A submission server that accepts unauthenticated mail is an open relay, and a correctly configured one rejects you with "relay access denied".
Host names and certificates#
Every client checks that the TLS certificate the server presents was issued for the host name you typed. Type 203.0.113.25 or server42.somehost.net when the certificate says mail.example.com and you get a warning. Clicking through it works, and it also teaches every person in the organisation to click through certificate warnings, which is the habit an attacker on hotel wifi relies on.
The clean setup is one name for everything, usually mail.example.com:
- Create an
Arecord formail.example.compointing at the mail server's address. DNS records explained covers the record types if this is new. - Make sure the server's certificate covers that name. Stalwart can obtain and renew certificates through ACME (Let's Encrypt and similar), so this is configuration rather than a purchase.
- Use
mail.example.comas both incoming and outgoing host in every client.
The MX record for the domain should point at the same name. It does not have to, but having one host name for receiving, reading and sending means one certificate and one thing to explain to users. MX records explained covers priorities and backup MX if you have more than one server.
Thunderbird#
Thunderbird has the best automatic configuration of any client, and the most transparent manual mode.
- Open Account Settings, then Account Actions, then Add Mail Account.
- Enter your name, the address and the password, and choose Continue.
- Thunderbird looks for settings (the order is described in the autoconfig section below). If it finds them, it shows IMAP and SMTP with host names and ports. Check them, then choose Done.
- If it finds nothing or guesses wrong, choose Configure manually and fill in the table above: IMAP,
mail.example.com,993, SSL/TLS, Normal password; SMTP,mail.example.com,465, SSL/TLS, Normal password. Use Re-test to confirm before saving.
Thunderbird's guesses are reasonable but not always right. If it has picked STARTTLS on 143 when your server also offers 993, either works, but changing it to 993 with SSL/TLS removes one moving part.
Two settings worth checking afterwards, under the account's Copies and Folders: where sent mail is stored (it should be the server's Sent folder, not a local folder, so sent items appear on your phone too) and whether drafts are kept on the server. Thunderbird for Android, the client formerly known as K-9 Mail, uses the same setup logic and the same autoconfig lookups.
Outlook#
Outlook comes in two quite different versions on Windows, and the difference matters for a private mail server.
Classic Outlook (the Microsoft 365 desktop application) talks to your server directly. Use File, Add Account, enter the address, open Advanced options, tick "Let me set up my account manually", and pick IMAP. Enter the incoming and outgoing server, port and encryption method from the table. Outlook calls implicit TLS "SSL/TLS" and the upgraded mode "STARTTLS"; older builds offered "Auto", which is best avoided because it hides what was chosen.
The new Outlook for Windows and Outlook on the web handle non-Microsoft IMAP accounts by synchronising them through Microsoft's cloud. Your server sees connections from Microsoft's addresses rather than from the user's computer, and a copy of the mailbox is held by Microsoft. For many people that is acceptable. For an organisation that runs its own mail server precisely to keep mail on its own hardware, it defeats the point, and is worth a sentence in whatever you tell your users.
Outlook on macOS, iOS and Android has its own account flow and, for IMAP accounts, has also used Microsoft's synchronisation service. Check current behaviour in Microsoft's documentation if it matters to you, because it has changed between versions.
Common Outlook errors map back to the table: "The server does not support the specified connection encryption type" is a port and mode mismatch, and a repeated password prompt is almost always the username format.
iPhone, iPad and Mac#
Apple Mail does not use Thunderbird-style autoconfig. It tries to guess from the address, and when it cannot, it asks.
On an iPhone or iPad: open Settings, go to Mail (under Apps on iOS 18 and later), then Mail Accounts, Add Account, Other, Add Mail Account. Enter name, address, password and a description, then choose Next. Pick IMAP, and fill in Incoming Mail Server and Outgoing Mail Server with the host name, username and password. iOS tries TLS on the standard ports and saves the account if it succeeds.
If your server uses non-standard ports, iOS will fail the first check. Save the account anyway, then edit it: the incoming port is under the account's Advanced settings, and the outgoing port is under the SMTP server entry in the account. Set "Use SSL" on, the port, and authentication to Password.
On a Mac, the flow is Mail, Add Account, Other Mail Account, with the same fields. For more than a handful of devices, Apple supports configuration profiles (.mobileconfig files) that contain the whole account definition; Apple Configurator creates them, and users install them with one tap. That is the Apple equivalent of autoconfig, and it is the right tool for a team.
Android: Gmail app, Samsung Email, Thunderbird#
Android has no single mail client. The three you will meet most:
- Gmail app. Add another account, choose Other, enter the address, choose Personal (IMAP), then the password, then the incoming and outgoing server settings. The Gmail app connects to your server directly for IMAP accounts.
- Samsung Email. Add account, enter address and password, choose Manual setup and IMAP, then the server details. Its security type labels vary between versions, so check the port it fills in beside the choice and make sure the pair matches the table above.
- Thunderbird for Android. Uses the same autoconfig lookups as desktop Thunderbird, so a domain with autoconfig set up configures itself.
Whichever client people use, push email on Android depends on IMAP IDLE, where the client holds a connection open and the server tells it about new mail. Battery optimisation kills those connections on some phones, which shows up as mail arriving only when the app is opened. That is a phone setting, not a server problem.
Autoconfig and autodiscover: letting clients find the settings#
Typing six settings into every device is where support time goes. Two conventions let clients configure themselves from the address alone.
Autoconfig is Mozilla's format, used by Thunderbird, Thunderbird for Android and some other clients. Given anna@example.com, Thunderbird looks in roughly this order: a configuration bundled with the client, https://autoconfig.example.com/mail/config-v1.1.xml, https://example.com/.well-known/autoconfig/mail/config-v1.1.xml, Mozilla's public ISP database, the ISP database entry for the domain your MX points at, and finally guesses at common host names and ports. Publishing the file means the first useful lookup succeeds:
<?xml version="1.0" encoding="UTF-8"?><clientConfig version="1.1"> <emailProvider id="example.com"> <domain>example.com</domain> <displayName>Example mail</displayName> <incomingServer type="imap"> <hostname>mail.example.com</hostname> <port>993</port> <socketType>SSL</socketType> <authentication>password-cleartext</authentication> <username>%EMAILADDRESS%</username> </incomingServer> <outgoingServer type="smtp"> <hostname>mail.example.com</hostname> <port>465</port> <socketType>SSL</socketType> <authentication>password-cleartext</authentication> <username>%EMAILADDRESS%</username> </outgoingServer> </emailProvider></clientConfig>socketType is SSL for implicit TLS and STARTTLS for the upgraded mode. password-cleartext sounds alarming and means "send the password inside the TLS session", which is correct. %EMAILADDRESS% is replaced by whatever the user typed; use %EMAILLOCALPART% if your logins are bare account names.
Autodiscover is Microsoft's equivalent, used by classic Outlook. The client posts a request to https://autodiscover.example.com/autodiscover/autodiscover.xml (and a few other locations, including https://example.com/autodiscover/autodiscover.xml and an SRV record at _autodiscover._tcp.example.com) and expects an XML response describing the IMAP and SMTP servers. Unlike autoconfig it is a POST, so a static file on an ordinary web server does not answer it; something has to respond to the request.
Stalwart can serve both kinds of request itself, provided the client can reach it over HTTPS on those names. If that is awkward, the autoconfig file is static and can live on any web host with a valid certificate - a small site on a web hosting plan with the proxy slot pointed at autoconfig.example.com does the job.
There is also a DNS-only option, RFC 6186 SRV records, which name the IMAP and submission servers directly:
_imaps._tcp.example.com. 3600 IN SRV 0 1 993 mail.example.com._submissions._tcp.example.com. 3600 IN SRV 0 1 465 mail.example.com._submission._tcp.example.com. 3600 IN SRV 0 1 587 mail.example.com.Few clients rely on them, so treat them as a cheap extra rather than a replacement for autoconfig.
Using a mail server on RE:NODE#
The Mail Server line runs Stalwart, which speaks SMTP, IMAP and JMAP and has a web admin where you create domains and mailboxes. Clients connect to the server's address and to the ports allocated to the plan - each Mail plan carries five - so read the address and the port numbers from the panel rather than assuming the standard ones in the table above. If a port number differs from the standard, put that number in the client and keep the encryption mode that matches the listener (implicit TLS or STARTTLS); the autoconfig file and the SRV records both take any port.
Port 25 is a separate matter. Receiving mail from other servers on the internet needs it, a container cannot open it by itself, and support forwards it to your server on request (one mail server per address). That has nothing to do with clients: they always use IMAP and submission, never 25. Likewise the DNS records that make the domain work for the outside world - MX, SPF, DKIM, DMARC - are yours to add at your DNS host. The Stalwart setup walkthrough covers creating the domain, mailboxes and DKIM key in the web admin before any client is configured.
Troubleshooting client connections#
The client times out. Wrong port, wrong encryption mode for the port, or a network that blocks the port. Test from the command line, which removes the client from the question:
$ openssl s_client -connect mail.example.com:993 -servername mail.example.com$ openssl s_client -connect mail.example.com:587 -starttls smtp$ openssl s_client -connect mail.example.com:465 -servername mail.example.comA connection that prints a certificate chain and then a server greeting (* OK for IMAP, 220 for SMTP) proves the port and TLS mode work. A hang on 993 that works with -starttls imap on 143 tells you which mode the listener actually uses.
Certificate warning. The certificate's names do not include the host you typed. The openssl output above shows the subject and alternative names; compare them with the client's server field.
Password rejected, password definitely correct. Username format (full address versus account name), an authentication method the server does not offer, or two-factor authentication requiring an app password. Repeated failures can also trigger the server's own brute-force protection, after which even the right password fails for a while.
Receiving works, sending fails with "relay access denied". Outgoing authentication is off in the client. Turn it on and use the same credentials as incoming.
Sending works, nothing arrives from outside. Not a client problem. The MX record, port 25 reaching the server, or the sender's mail being rejected as spam - why email goes to spam covers the last one from the sender's side.
Sent messages appear twice, or not at all, in Sent. The client saves a copy of each sent message to the server's Sent folder over IMAP. If the client is pointed at a local folder, sent mail is missing on other devices; if two clients both have special-folder mappings pointing at different folders, you get Sent and Sent Items side by side. Map every client to the same server folder.
FAQ#
Should I use port 465 or 587 for sending?
Either. 465 uses TLS from the first byte and RFC 8314 recommends it for submission; 587 with STARTTLS is equally secure when the client requires the upgrade. Pick one, match the encryption mode to it, and use the same choice in every client so support questions have one answer.
Why does my phone only get new mail when I open the app?
The phone is closing the client's long-lived IMAP connection to save battery, so the server cannot tell it about new mail. Exclude the mail app from battery optimisation, or accept a polling interval. The server is behaving normally.
Can I use POP3 instead of IMAP?
You can if the server offers it, but you probably should not. POP3 downloads mail to one device and usually deletes it from the server, so a second device sees nothing. IMAP keeps one copy on the server that every device shares, which is what almost everybody actually wants.
Do I need autoconfig if I only have five users?
No. Five people can be set up by hand in an afternoon. Autoconfig starts paying off when users set up their own devices, or when phones get replaced every year and nobody remembers the settings. It is one static file, so it is cheap to add later.
Is it safe to read company mail through the new Outlook?
It works, but the mail is synchronised through Microsoft's cloud rather than fetched directly from your server. Whether that is acceptable depends on why you run your own server. If keeping mail on your own hardware is the reason, point users at a client that connects directly, such as Thunderbird or classic Outlook.




Comments
Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.