What happens when you click Send

Module 1: How your mail 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 a mail program in your browser

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

Webmail is simply a mail 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 mail;
SMTP to send mail.

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 mail program, the problem is in that program's settings.

From Send to Inbox in five steps

Emma Smith (emma@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 Emma's mail server via SMTP. This is also called submission. Emma has to log in for this, otherwise anyone could use her server to send spam. Mail programs use port 465 or 587 for this, with encryption. WebOké's webmail sends through the same server you're logged in to.
Looking up the route. Emma's server looks at the part of Ahmed's address after the @: example.net. It asks the DNS for the MX record of that domain. That record says which server accepts mail for example.net.
Delivery. Emma's server contacts 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, in the Inbox or in the spam folder.
Reading. Ahmed opens his mail program or webmail. It fetches the message with IMAP and shows it.

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

Envelope and letter: two kinds of address

An email is like a letter in an envelope. The servers only look at the envelope. You and Ahmed mostly 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 mail 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, so a mail program knows which messages belong together.

The envelope and the headers don't have to match. If Emma sends an email with her colleague Tom (tom@example.com) in Bcc, Tom is on the envelope but not in the headers. That's why Ahmed can't see that Tom 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: the travel log of an email

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

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

Return-Path: <emma@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: Emma Smith <emma@example.com>
To: Ahmed <ahmed@example.net>
Subject: Quote for bridal bouquet
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 trust the top lines most, as they 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: emma@example.com without having anything to do with Emma.

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

SPF says which servers may send mail 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 refuse 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 course Email in order. 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 delivered

If your email is in the Sent folder, you only know one thing for sure: your own server has accepted it (step 1). The rest 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 tells you 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. Then you get an error message back (a bounce, lesson 8.4).
The email can arrive but land in the spam folder. Then you get no notification at all.

So if Emma 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 the headers of a message 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 mail program show the same mail together is explained 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 (in Gmail, for example, Show original).

Summary

Webmail is a mail 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 delivered.

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 you could have found it in the headers.

Cookies at WebOké

Cookie settings

Necessary

Marketing