Skip to content

Cookie settings

Choose which kinds of cookies you allow. You can change your choice at any time via Cookie settings at the bottom of every page. Privacy statement

Necessary

Always on

Needed to log in, keep your cart and remember your choices. These are always on.

Which cookies?
  • weboke_sessie, weboke_klant, weboke_remember: your session and staying logged in
  • weboke_basket: your cart
  • wkBtwIncl: showing prices with or without VAT
  • wok_cookies: your cookie choice, 12 months

Measures which ad leads to a visit or order, so we do not pay for ads that do nothing.

Which cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), up to 90 days
  • OpenAI Ads, ads in ChatGPT
  • wok_aff: which partner referred you to us (affiliate programme), 60 days

4.6

Country and language

Each country has its own site, with prices and VAT for that country.

View

Module 2 · 2.1

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.

SettingWhat it isCommon value
Account typeThe protocol for reading mailIMAP (lesson 1.3)
Incoming serverThe name of the server for reading mailGiven by your provider
Incoming port and securityThe door and the lock993 with SSL/TLS (POP3: 995)
Outgoing serverThe name of the server for sending mailOften the same as incoming
Outgoing port and security587 with STARTTLS or 465 with SSL/TLS (lesson 1.4)
UsernameWhat you log in withUsually your full email address
PasswordThe password for the mailboxNot the password for your client panel
Outgoing authenticationDo 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:

NameWorks if...Risk
server12.hosting.example (the server's own name)Always: the server's certificate is issued for this nameChanges 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 thereStops working if your website moves elsewhere
mail.example.commail.example.com points to the server and appears in the certificateOften 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

1. Why is the username almost always the full email address?



2. Your website moves to a different company. Your mail stays where it was. Your mail program has example.com set as the server. What's likely to happen?



3. Thunderbird automatically fills in mail.example.com and you get a certificate warning. What's the cause?



4. Which DNS record tells programs that follow RFC 6186 where the IMAP server with direct TLS is located?



5. Logging in to webmail works, but it doesn't on your phone. What do you now know?



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.

Exercise Z2.1: What would a mail program find?

Enter your email address and the server name you use. The server looks up the name, connects to port 993 (without logging in) and checks what autoconfiguration data exists in the DNS and on the web.






What you enter and what we find isn't stored. Your browser remembers your answers and whether you've passed the exercise. If you're signed in, we only save that you got the exercise (almost) right in My courses; you can delete that there too.

Further reading

The steps in these articles apply to WebOké's panels; with other providers it works similarly.

One moment…

Set up your domains

For each domain, arrange the nameservers, the link to your hosting and who becomes the owner.

Loading your domains…