A message is not one trip
When you press send, it can feel like the message flies straight to the other person. In reality, it is handed along a short chain of programs, each doing a specific job. Usually the whole process takes a few seconds, but several separate systems are involved.
The main roles are:
- A mail client, the app or webpage you write in.
- An outgoing mail server, run by your email provider, which takes your message and sends it on.
- An incoming mail server, run by the recipient’s provider, which receives and stores it.
- The recipient’s mail client, which fetches and shows it.
Names for these roles vary. You may see terms such as mail transfer agent for a server that moves mail, and mail delivery agent for the part that files it into a mailbox.
Step 1: You hand the message to your provider
When you hit send, your mail client passes the message to your provider’s outgoing server using a protocol called SMTP, short for Simple Mail Transfer Protocol. Your provider usually asks you to be signed in first, so it knows the message is really from you.
The message has two parts: the envelope and the content. The envelope states the sender and recipients for the purposes of delivery. The content has the headers (such as From, To, Subject and Date) and the body. Servers read the envelope to decide where to send it, while you see the headers and body.
Step 2: Finding the destination
Your provider needs to know which server accepts mail for the recipient’s domain, the part after the @ sign. It finds out through the domain name system, the internet’s address book. The domain’s records include entries called MX records, which name the mail servers responsible for that domain, often with a priority order so that a backup server can take over.
That server name then has to be turned into an IP address, another lookup, so that your provider’s server knows where on the internet to connect.
Step 3: The handoff between servers
Your provider’s server opens a connection to the destination server and, again using SMTP, offers the message. Both servers go through a short exchange: introductions, the sender and recipient addresses, then the message itself. If the connection supports it, the transfer is encrypted in transit, which protects against casual eavesdropping on the route. This does not mean the message is end-to-end encrypted; the servers at each end can still read it. The topic of what protects what is covered in more detail in the article on end-to-end encryption.
Sometimes there are extra hops. A message may pass through a forwarding service, a mailing list or a company’s security gateway before reaching the final mailbox. Each hop typically adds a line to the headers, which is why viewing the full headers of a message can show its route.
Step 4: Checks on arrival
Before accepting a message, the receiving server often checks whether it appears to be genuine. Three common mechanisms work together:
- SPF lets a domain publish a list of servers allowed to send mail on its behalf. The receiver compares the sending server against that list.
- DKIM adds a digital signature to the message, which the receiver can verify using a public key published by the sending domain. It helps show the message was not altered in transit.
- DMARC lets a domain state what receivers should do when SPF and DKIM checks fail, such as deliver, quarantine or reject, and where to send reports.
These checks make it harder to forge a sender’s domain, though they do not prove a message is trustworthy. A scammer can still send from a domain they own that merely looks similar. The receiving server also applies spam filters, which weigh many signals and decide whether a message goes to the inbox, the junk folder or is refused.
Step 5: Storage and pickup
If the message is accepted, it is placed in the recipient’s mailbox on their provider’s server. Mail is then read through one of two broad methods:
- IMAP keeps mail on the server and lets your devices show a synchronised view. If you read or delete a message on your phone, your laptop reflects the change. Most modern setups work this way.
- POP3 typically downloads messages to one device, and often removes them from the server. It is older and less convenient with several devices.
Webmail skips this choice, since you read directly on the provider’s site. Phone apps may also use push notifications, in which the provider alerts the device that new mail has arrived.
When something goes wrong
Most failures fall into a few categories.
A bounce message comes back if delivery fails permanently, for example if the address does not exist or the mailbox is full. The error text usually says why. Typos in addresses are a common cause.
A delay may occur when the destination server is busy or temporarily unreachable. The sending server generally retries for some time, often hours to days, before giving up and sending a failure notice. Exact retry periods vary by provider.
Mail in junk happens when a filter judges the message suspicious. A new domain, a missing authentication record or content that resembles spam can all play a part.
Mail that never appears might have been rejected without a bounce, held in quarantine by a company system, or caught by a rule the recipient set up.
What this means for you
You do not need to manage any of this day to day, but a few practical points follow. Email works across providers because the servers agree on shared standards, not because one company runs it. A message passes through systems you do not control, so avoid sending highly sensitive details by plain email. If an important message seems missing, check junk, ask the sender to confirm the address and look at any bounce notice. And if you run your own domain, setting up SPF, DKIM and DMARC correctly is one of the best ways to help legitimate mail arrive.