Module 2 · 2.1
English
The information you need
Module 2: Setting up your mailbox · Reading time: 10 minutes
Learning objective: After this lesson, you'll know the information every mail program needs, be able to choose the right server name, and understand how programs try to find that information themselves and why that sometimes goes wrong.
Key concepts: incoming server, outgoing server, port, security, username, password, outgoing authentication, server name vs. mail. name, autodiscover, autoconfig, ISPDB, SRV records (RFC 6186), configuration profile
The settings checklist
Whichever program you use, you always fill in the same information. If you understand this list, you can set up any program, even one that doesn't appear in this course.
| Setting | What it is | Common value |
|---|---|---|
| Account type | The protocol for reading mail | IMAP (lesson 1.3) |
| Incoming server | The name of the server for reading mail | Given by your provider |
| Incoming port and security | The door and the lock | 993 with SSL/TLS (POP3: 995) |
| Outgoing server | The name of the server for sending mail | Often the same as incoming |
| Outgoing port and security | 587 with STARTTLS or 465 with SSL/TLS (lesson 1.4) | |
| Username | What you log in with | Usually your full email address |
| Password | The password for the mailbox | Not the password for your client panel |
| Outgoing authentication | Do you also need to log in when sending? | On, with the same details |
Three things most often go wrong here.
The username. A shared mail server holds mailboxes for thousands of domains. info exists there a thousand times over. That's why the username is almost always the full address: info@example.com. Programs sometimes fill in only the part before the @. Check this for both incoming and outgoing.
The password. Every mailbox has its own password. That's different from the password you use to log in to your hosting provider or client panel. If you've forgotten it, set a new password for that mailbox in the panel and enter it on all your devices.
The outgoing server. Many programs mark the outgoing server as "optional" or leave the username blank. Then you can read mail but not send it.
Which server name?
For the server name, you often have three candidates. Say your domain is example.com and your mailbox is on a shared server called server12.hosting.example:
| Name | Works if... | Risk |
|---|---|---|
server12.hosting.example (the server's own name) | Always: the server's certificate is issued for this name | Changes if your provider moves you to a different server |
example.com (your domain name) | Your domain points to the same server and has a valid certificate there | Stops working if your website moves elsewhere |
mail.example.com | mail.example.com points to the server and appears in the certificate | Often not included in the certificate: certificate warning |
No single name is always best. The question is always: does this name point to the server where my mailbox is, and does it appear in that server's certificate? If both are yes, you're fine. If you can't check this, the name your provider gives you is the safest choice. In exercise Z2.1, you'll have the program check this for you.
A common mistake happens when your website moves: you've used example.com as your mail server for years, your website moves to a different company, the A record points there, and suddenly your mail stops working. Your mail program then tries to connect to the other company's web server. The MX record is fine (mail still arrives), but your program can't reach it.
How programs search on their own
You often don't need to type in the information yourself. Modern programs try to find it automatically as soon as you enter your email address. There are several methods, and each program tries a few:
Autodiscover (Microsoft). Outlook requests a settings file from https://autodiscover.example.com/autodiscover/autodiscover.xml or https://example.com/autodiscover/autodiscover.xml, or looks for an SRV record _autodiscover._tcp.example.com. With Microsoft 365, there's a CNAME autodiscover pointing to autodiscover.outlook.com (DNS course lesson 7.1).
Autoconfig (Thunderbird and others). Thunderbird checks https://autoconfig.example.com/mail/config-v1.1.xml and then Mozilla's database (ISPDB), which contains the settings for many major providers. If it finds nothing, it tries to guess names: imap.example.com, mail.example.com, smtp.example.com, and it checks your MX record.
SRV records (RFC 6186, extended in RFC 8314). In DNS, you can specify where each service runs:
_imaps._tcp.example.com. 3600 IN SRV 0 1 993 server12.hosting.example.
_submissions._tcp.example.com. 3600 IN SRV 0 1 465 server12.hosting.example.
_submission._tcp.example.com. 3600 IN SRV 0 1 587 server12.hosting.example.Not every program looks for these, but it helps. You can read how SRV records work in lesson 5.1 of the DNS course.
Configuration profile (Apple). For iPhone, iPad and Mac, you can download and install a .mobileconfig file. It contains all the settings. Many panels can create such a file (lesson 2.3).
Why automatic setup sometimes goes wrong
Automatic discovery is handy, but not smart. Typical mistakes:
- Thunderbird guesses
mail.example.com, which exists but isn't in the certificate. Result: a certificate warning. - Outlook finds an old file from your previous provider through autodiscover, or thinks your address is a Microsoft 365 account, and keeps asking for a Microsoft password.
- A program chooses port 587 with "SSL/TLS" or leaves the username blank.
- The program finds the settings of your website provider instead of your mail provider, because it's looking at
example.com.
So always check what's been filled in, even if the program says it succeeded. Almost every program has a manual setup or advanced settings button: use it if the automatic attempt fills in something different from what your provider specifies.
Test in webmail first
If it doesn't work, first test your username and password in your provider's webmail. If logging in there works, you know the mailbox exists and the password is correct. Then the fault lies in your program's settings. If it doesn't work there either, there's no point searching further in your program. See lesson 2.5.
In practice: the details at WebOké
For a WebOké mailbox, you fill in: IMAP, incoming and outgoing server your domain name (if your website is also hosted with WebOké and has a valid certificate) or your package's server name (in the form linuxNNNN.webawere.nl, found in My WebOké under your product and in the welcome email), ports 993 and 587 or 465, username your full email address, outgoing authentication on. With other providers, it works similarly: the server name is in the welcome email or client panel, and the ports are almost always the same.
Summary
- Every program needs the same information: protocol, servers, ports, security, full email address as username, mailbox password, outgoing authentication.
- A server name is good if it points to your mailbox's server and appears in the certificate.
- Programs search on their own through autodiscover, autoconfig, ISPDB, SRV records or a profile. Always check afterwards what they found.
- If you have problems, first test in webmail whether the username and password are correct.
Quiz
Exercise
Exercise Z2.1: What would a mail program find? Enter your email address and the server name you use (or want to use). Answer: does this name point to a server offering IMAP on 993, does the name appear in the certificate, and does your domain have records for automatic setup (autoconfig, autodiscover or SRV)? The program checks the same things live: it looks up the name, connects to 993, 465 and 587, reads the certificate and checks which of the known settings can be found in DNS and on the web.
Further reading
The steps in these articles apply to WebOké's panels; with other providers it works similarly.
- DirectAdmin guide 8.1: All settings at a glance: servers, ports and security
- WebOké manual 7.1: Email with WebOké: mailboxes, webmail and your email program
- Certificate error when collecting email
- Free DNS course 5.1: SRV records
- RFC 6186 (SRV for mail programs), RFC 8314 section 5.1 (
_submissions._tcp)
