You press Send, and a moment later the message appears in someone else's inbox, perhaps on the other side of the world. It feels instant and simple, yet several systems work together in that moment: your mail app, your outgoing server, the internet's directory of names, the recipient's server and finally their mailbox. This guide explains how email works from start to finish in plain language, naming each part, following one message on its journey, showing where things commonly go wrong and linking to deeper guides on each stage.
The parts of the email system
Email is a chain of cooperating programs, each with a name. The names look technical, but each does something easy to picture.
- Mail user agent (MUA). The app you use to read and write email, such as Gmail in a browser, Outlook, Apple Mail or a phone app.
- Mail submission agent (MSA). The part of your outgoing server that accepts a message from your app, checks that you are allowed to send and takes responsibility for it.
- Mail transfer agent (MTA). The program that moves messages between servers. It looks up where to send each message and connects to the next server. Read more in what a mail transfer agent is.
- Mail delivery agent (MDA). The program at the final server that places the message in the recipient's mailbox.
- Mailbox store and access server. Where the message is kept, and the service your app uses to read it, usually IMAP or POP3.
- DNS. The internet's directory. Without it a server would not know where to send mail for a given domain.
The protocols: SMTP, IMAP and POP3
Three protocols do most of the work.
- SMTP (Simple Mail Transfer Protocol) sends mail, both from your app to your server and between servers. See what SMTP stands for.
- IMAP lets your app read mail that stays stored on the server, so that every device sees the same mailbox. See what IMAP is.
- POP3 downloads mail to one device, and usually removes it from the server.
For the differences side by side, read IMAP vs POP3 vs SMTP.
The journey of one email, step by step
Imagine that Priya, who has the address [email protected], writes to Sam at [email protected].
- Priya writes and sends. Her mail app builds the message: headers such as From, To, Subject and Date, then the body, and any attachments encoded in a standard format. See MIME and attachments.
- Her app connects to her outgoing server. It uses SMTP, usually on port 587, and logs in with her credentials. The connection is upgraded to an encrypted one before the password is sent. See SMTP settings, ports and authentication.
- Her server accepts the message and puts it in an outgoing queue.
- The server looks up the destination. It takes the domain after the @, recipient.example, and asks DNS for its MX records. These name the servers that accept mail for that domain, in order of priority. See DNS records for email.
- The server connects to the recipient's server on port 25, which servers use to talk to each other, and starts an SMTP conversation. Port 25 is usually blocked for ordinary users, which is why apps use 587. See which SMTP port to use.
- The two servers talk. The sending server announces itself, says who the message is from (the envelope sender) and for whom it is intended, then sends the message data. Encryption is used if both sides support it. See email TLS and STARTTLS.
- The receiving server runs checks. It looks at the sender's SPF, DKIM and DMARC results, the sending IP's reputation, blocklists and spam filters. See email authentication explained.
- It accepts, defers or rejects. A 2xx reply means accepted. A 4xx reply means try again later. A 5xx reply means permanent failure, and a bounce goes back to Priya. See queued and deferred email.
- The delivery agent files the message in Sam's mailbox, in the inbox or in spam depending on the filters.
- Sam's app fetches it. It connects over IMAP or POP3, and the message appears.
Each server along the way adds a Received line to the message headers, so afterwards you can read the path. Our guide on email headers shows how.
Why email sometimes fails
| Stage | What can go wrong | What you see |
|---|---|---|
| Sending from the app | Wrong password, blocked port, no connection | The message stays in the outbox, or an authentication error appears |
| Looking up the domain | Typo in the domain, missing MX records | A bounce saying the domain was not found |
| Server to server | Greylisting, rate limits, blocklists | A delay, or a bounce with a 4xx or 5xx code |
| Receiver checks | Failed authentication, spam filtering | Spam placement or a rejection |
| Mailbox | Mailbox full, account disabled | A bounce about quota or a missing user |
| Reading | IMAP settings wrong, sync problems | The message arrived but does not show in your app |
If a message will not send at all, start with why emails will not send. If it came back with an error, see what a Mail Delivery Subsystem message means.
How email works for websites and apps
A website that sends receipts, password resets or newsletters does the same thing without a person at a keyboard. The application builds the message and hands it to a sending service, which acts as the outgoing server. There are two ways to hand it over.
- SMTP. The app connects to a relay as a mail app would. It is the simplest route, because nearly every framework and plugin already supports it.
- An HTTP API. The app sends a request that describes the message. It adds features such as templates, tags and detailed responses.
Our guide to choosing between SMTP and an API compares them, and SMTP relay and the email API are the two ways to send with us. A sending service also manages the hard parts: retries, bounce handling, reputation and logs. After sending, webhooks tell your app what happened to each message.
Email is not private by default
Email travels through several servers and is stored at each end. Encryption in transit protects it from eavesdroppers on the network, but each provider can read the message at rest unless you use end-to-end encryption, which is separate and needs both sides to set it up. Treat ordinary email as a postcard in an envelope: reasonably private, and not for secrets.
Key points to remember
- Your app talks to your server; your server talks to theirs; their app talks to their server.
- DNS decides where a message goes, and authentication decides whether it is trusted.
- Every step can fail in a visible way, and the error code tells you where.
- Good sending practice, from authentication to a clean list, is what makes the system work for you.
Send from your own app without running a mail server Use SMTP or the API, and see what happened to every message.
References and further reading
Frequently asked questions
How does email work in simple terms?
Your mail app sends the message to your outgoing server over SMTP. That server looks up the recipient's domain in DNS, connects to their server and hands the message over. Their app then fetches it with IMAP or POP3.
What is the difference between SMTP and IMAP?
SMTP sends mail between apps and servers and between servers. IMAP lets an app read and manage mail stored on a server.
What is an MX record?
It is a DNS record that names the mail servers accepting mail for a domain, with priorities. Sending servers use it to find where to deliver.
Why do some emails take a long time to arrive?
Greylisting, rate limits and busy servers can delay delivery. The sending server retries after a temporary failure, so the message often arrives later.
Is email encrypted?
Usually in transit between servers and apps, if TLS is supported. Providers can still read stored mail unless you use end-to-end encryption.