Module 1 · 1.1

English

Nederlands English Deutsch Français Español

What happens when you click Send

Module 1: How your email works · Reading time: 9 minutes

Learning objective: After this lesson you can explain the route an email takes between Send and the recipient's Inbox, and you can point out the difference between the envelope and the headers of an email.

Key concepts: webmail, mail server, SMTP, MX record, IMAP, envelope, headers, Return-Path, Received, Message-ID, SPF, DKIM, DMARC

Webmail is an email program in your browser

Your email isn't stored in your browser, and it isn't on your computer either. It lives on a mail server: a computer that runs day and night, receiving, storing and passing on email. To read that email you need an email program. That could be Outlook, the mail app on your phone, or webmail.

Webmail is simply an email program that runs in your browser. At WebOké that's Roundcube. Roundcube isn't a mail server itself. It talks to the mail server on your behalf, using the same languages that Outlook or Apple Mail use:

IMAP to read, move and delete your email;
SMTP to send email.

If something doesn't work in webmail, the cause is often not webmail itself but what the server does or reports back. And the other way round: if sending works in webmail but not in your email program, the problem is in that program's settings.

From Send to Inbox in five steps

Sanne de Vries (sanne@example.com) runs a flower studio. She sends her customer Ahmed (ahmed@example.net) a quote for a bridal bouquet. This is what happens when she clicks Send.

Handing it to her own server. Webmail passes the message to Sanne's mail server via SMTP. This is also called submission. Sanne has to log in for this, otherwise anyone could use her server to send spam. Email programs use port 465 or 587 for this, with encryption. WebOké webmail sends through the same server you're logged in to.
Looking up the route. Sanne's server looks at the part after the @ in Ahmed's address: example.net. It asks the DNS for the MX record of that domain. That record says which server accepts email for example.net.
Delivering. Sanne's server connects to that receiving server and delivers the message, again using SMTP. Between servers this happens on port 25.
Into the mailbox. The receiving server checks the message (does the address exist, is it spam?) and puts it in Ahmed's mailbox, either in the Inbox or in the spam folder.
Reading. Ahmed opens his email program or webmail. It fetches the message using IMAP and shows it.

Each step can go wrong on its own. That's why an error message always gives you a clue about where it went wrong: could Sanne not log in to her own server (step 1), did her server fail to find the recipient (step 2 or 3), or did the receiving server refuse the email (step 4)?

Envelope and letter: two kinds of addresses

An email is like a letter in an envelope. The servers only look at the envelope. You and Ahmed mainly see the letter.

The envelope is created during the SMTP conversation between two servers. The sending server first says who the email is from (the MAIL FROM command) and then who it's for (RCPT TO). Only then does the message itself follow. The envelope sender address is where error messages go. On final delivery, the receiving server puts it at the top of the message as Return-Path.

The letter starts with headers: lines with a name, a colon and a value. The best known are:

From: the sender you see in your email program;
To and Cc: the recipients you see;
Subject: the subject;
Date: the moment of sending, according to the clock of the sender's program;
Message-ID: a unique identifier for this message. Replies refer to it, which is how an email program knows which messages belong together.

The envelope and the headers don't have to match. If Sanne sends an email with Bcc to her colleague Daan (daan@example.com), Daan is on the envelope but not in the headers. That's why Ahmed can't see that Daan is reading along. And a newsletter often has a Return-Path at the newsletter service, while From is the shop's address. Error messages then end up at the service.

Received lines: an email's travel log

Every server that accepts an email must add a Received header to it, at the very top. This way an email builds up a travel log along the way. So the top Received line is the last step and the bottom one is the first. You read them from bottom to top.

This is roughly what the headers of Sanne's email look like at Ahmed's end (shortened):

Return-Path: <sanne@example.com>
Received: from mail.example.com (mail.example.com [192.0.2.10])
        by mx.example.net with ESMTPS
        for <ahmed@example.net>; Tue, 10 Nov 2026 10:15:04 +0100
Received: from webmail.example.com ([192.0.2.20])
        by mail.example.com with ESMTPSA
        for <ahmed@example.net>; Tue, 10 Nov 2026 10:15:02 +0100
From: Sanne de Vries <sanne@example.com>
To: Ahmed <ahmed@example.net>
Subject: Offerte bruidsboeket
Date: Tue, 10 Nov 2026 10:15:01 +0100
Message-ID: <20261110091501.a1b2c3@example.com>

Read the bottom Received line first. Webmail handed the message to mail.example.com. The letters ESMTPSA mean: encrypted (S) and with login (A). Then mail.example.com passed it on to mx.example.net, Ahmed's server. The part after "from" is the server that offered the email, the part after "by" is the server that accepted it. The times show how long each step took.

A pitfall: a sender can add fake lines at the bottom before sending. So mainly trust the top lines, which were created by servers you know, such as your own provider's server.

Why From can be forged

The SMTP protocol was designed at a time when everyone trusted each other. Nothing in the protocol itself checks whether the sender in From is genuine. So a scammer can send an email with From: sanne@example.com without having anything to do with Sanne.

That's why three checks were added later, which the owner of a domain sets up in their DNS:

SPF says which servers may send email with an envelope sender from that domain.
DKIM puts a digital signature on the message. The recipient checks it with a key from the DNS of the domain that signed it.
DMARC links those two to the domain you see in From, and says what the recipient should do if the check fails: nothing, put it in spam, or reject it.

This is handled by the domain's administrator, not by you as a webmail user. You'll learn exactly how it works in the Email in Order course. For now it's enough to know that the displayed sender proves nothing, and that you can see in the headers whether these checks passed (lesson 2.2).

Sent doesn't mean arrived

If your email is in the Sent folder, you only know one thing for sure: your own server accepted it (step 1). Everything else happens afterwards, sometimes much later.

The receiving server can refuse temporarily. Some servers first ask an unknown sender to try again later (greylisting). Your server then tries again, sometimes for days, and lets you know if it keeps failing.
The receiving server can refuse the email permanently, for example because the address doesn't exist or the mailbox is full. You then get an error message back (a bounce, lesson 8.4).
The email can arrive but end up in the spam folder. Then you get no notification at all.

So if Sanne is waiting for a reply that doesn't come, she first checks whether there's an error message in her Inbox, and asks Ahmed to look in his spam folder.

In practice: how it works in webmail

In webmail you can see a message's headers with the Headers button above the message, or via More > Show source. Lesson 2.2 goes into this in more depth. How webmail and your email program show the same email, you can read in the Roundcube manual under What is webmail. Other webmail, such as Gmail or Outlook.com, works in a similar way, only the button has a different name there (in Gmail, for example, Show original).

Summary

Webmail is an email program in your browser. It talks to the mail server via IMAP (reading) and SMTP (sending).
An email goes from your own server to the server listed in the MX record of the recipient's domain.
The envelope (MAIL FROM, RCPT TO, later Return-Path) is for servers; the headers (From, To, Subject, Date, Message-ID) are for people and programs.
Every server adds a Received line at the top; you read them from bottom to top.
From can be forged; SPF, DKIM and DMARC make forging harder. Sent doesn't mean arrived.

Quiz

Exercise

Exercise A1.1: Reading headers. The material kopregels-1.txt is below this exercise: the headers of a real but anonymised email. Read them from bottom to top and fill in: the domain in From, the domain of Return-Path, how many Received lines there are, and which server received the email last (the top Received line, the part after "by"). The program compares your answers with the answer key and shows for each question whether it's correct, with an explanation of where in the headers you could have found it.

Cookies at WebOké

Cookie settings

Necessary

Marketing