More servers than you might expect
Pressing “send” feels like handing a letter directly to a person. In practice, an email passes through a chain of servers, each with a narrow job, and several automated checks decide whether it is accepted and where it ends up. Most of the time the whole trip takes seconds. Occasionally it takes much longer, and understanding the steps helps explain why.
The main roles
Email systems divide the work among a few kinds of software.
- Mail user agent (MUA): the app or web page you use to write and read messages, such as a phone mail app or a webmail site.
- Mail submission server: the first server that receives your outgoing message. It usually requires you to sign in, which stops strangers from sending mail through it.
- Mail transfer agent (MTA): a server that passes messages on toward the recipient’s server.
- Mail delivery agent (MDA) and mailbox: the software that stores the message in the recipient’s mailbox.
The protocols
Email relies on a few standard protocols. SMTP (Simple Mail Transfer Protocol) moves messages between you and your provider, and from one provider to another. To read your mail, an app typically uses IMAP, which keeps messages on the server so that several devices stay in sync, or the older POP3, which usually downloads messages to one device. Webmail hides all of this behind a browser page, but the same servers are working behind it.
A message’s journey
Suppose Alex sends a message to Sam, who uses a different provider.
- Composing and submitting. Alex’s mail app connects to the submission server, signs in and hands over the message.
- Looking up the destination. The sending server reads the part of Sam’s address after the @ sign and asks DNS for that domain’s MX records. These name the servers that accept mail for the domain. If there are several, they come with priorities, and the sender tries them in order. This is one of several jobs handled by the domain name system.
- Connecting. The sending server opens a connection to Sam’s provider’s mail server and announces who the message is from and who it is for.
- Checks. The receiving server decides whether to accept it. If the recipient does not exist, it refuses the message, which leads to a bounce notice.
- Transfer. If accepted, the message content is passed across. Both servers usually try to encrypt this connection, though it depends on both sides supporting it.
- Filtering. Before reaching the mailbox, the message is scanned for spam and malicious content.
- Delivery. The message is stored in Sam’s mailbox, ready for Sam’s app to fetch it.
Along the way, each server adds a line to the message’s headers recording that it handled it. Most mail apps hide these, but they can be revealed through a “show original” or “view source” option, and they are useful for tracing delays.
How receiving servers judge senders
Email was designed in an era when almost everyone on the network could be trusted, so the sender’s “From” address can be forged easily. Three standards were added later to help receivers check authenticity.
- SPF (Sender Policy Framework): the domain owner publishes in DNS a list of servers allowed to send mail for that domain. The receiver checks whether the connecting server is on it.
- DKIM (DomainKeys Identified Mail): the sending system attaches a digital signature to the message. The receiver looks up a public key in DNS and checks that the signature matches and the message was not altered. The idea is related to public key cryptography.
- DMARC: the domain owner states how receivers should treat messages that fail SPF or DKIM checks, for example by rejecting or quarantining them, and where to send reports.
These help, but they are not perfect. A message that passes all three has been shown to come from a server authorized by that domain. It has not been shown to be honest. Scammers can register their own domains and set up authentication correctly, so phishing emails can still pass the checks.
Spam filtering
Providers combine many signals when deciding whether to send a message to the inbox, the spam folder or nowhere at all. These may include authentication results, the sender’s history, whether recipients tend to mark the sender’s mail as spam, the presence of suspicious links, and patterns in the text. The exact rules are not public and change over time, so legitimate mail occasionally ends up in spam and unwanted mail occasionally gets through.
Why delays and bounces happen
If the receiving server is busy or temporarily unreachable, the sending server does not give up immediately. It queues the message and retries at intervals, often for a day or more, before returning a failure notice. A “soft” bounce suggests a temporary problem, like a full mailbox. A “hard” bounce suggests a permanent one, like an address that does not exist.
Encryption and privacy
Encryption on the connection between servers protects against eavesdropping on that hop, but it generally does not protect the message once it sits in a mailbox. Your provider can usually read what is stored there. Some systems offer end-to-end encryption, where only the sender and recipient can read the contents, but it is not the default for ordinary email, and the subject line and addresses are often still visible. The article on message encryption covers how that approach differs.
Practical takeaways
- A familiar-looking sender name is not proof of identity. Check the actual address and be cautious with unexpected links or attachments.
- If an important message is missing, check the spam folder and ask the sender whether they received a bounce.
- Many email problems come down to DNS settings, so a domain owner who sends mail should make sure the SPF, DKIM and DMARC records are set up as their provider recommends.