You write a message, check the address, and press send. A second later it has gone from your outbox, and a moment after that your colleague’s phone buzzes on the other side of the country. It feels like a single action, as simple as dropping a letter into a slot.
Behind that second sits a chain of handovers between programs and machines that have never met, following rules first written down decades ago. Knowing roughly how the chain works makes a few everyday mysteries easier to understand: why some emails take twenty minutes, why a perfectly normal message ends up in spam, and what the “undo” button is really doing.
Your mail client hands the message over
The program you write email in is called a mail client. It might be an app on your phone, a desktop program, or a web page such as the one your email provider gives you. Its job is to help you compose messages and show you the ones you receive. It does not deliver anything by itself.
When you press send, the client packages your message into a standard format. That package has two parts. The headers hold details like the sender, the recipients, the subject and the date. The body holds what you wrote, along with any attachments, which are converted into plain text so they can travel through systems that were originally designed only for text.
The client then connects to an outgoing mail server run by your provider and hands the package over using a protocol called SMTP, the Simple Mail Transfer Protocol. This first step is often called submission. Your client logs in with your account details, so the server knows the message really comes from you, and the connection is normally encrypted so nobody on the same network can read it in transit.
If you use webmail, this step happens inside your provider’s own systems rather than between your device and a server, but the idea is the same: the message is handed to the provider’s outgoing mail system, which takes responsibility for it from there.
Finding where the message should go
Your provider’s server now has a message addressed to, say, sam@example.org. It needs to work out which computer accepts mail for example.org. It does this with the Domain Name System, or DNS, the same directory the internet uses to turn website names into addresses.
Every domain that receives email publishes one or more MX records, short for mail exchanger. These say which servers handle incoming mail for that domain, with a priority number so that backup servers can take over if the main one is unavailable. Your provider’s server looks up the MX records for example.org, picks the preferred server, then looks up that server’s network address.
This is why an email address has two halves. The part after the @ tells the sending server where to deliver. The part before it is only interpreted at the other end, by the receiving system, when it decides which mailbox to put the message in.
Server talks to server
Next, your provider’s server opens a connection to the recipient’s mail server and speaks SMTP again. The conversation is surprisingly polite and structured. The sending server introduces itself, states who the message is from, lists the recipients, and then transfers the message itself. At each step the receiving server replies with a numbered code saying whether it accepts.
Most servers today try to encrypt this connection using TLS, the same technology behind the padlock in your browser. Server-to-server encryption has become common, though it is not guaranteed on every route, which is one reason sensitive information is better sent by other means.
If the receiving server is down, busy or temporarily refusing mail, the sending server does not give up. It puts the message in a queue and tries again later, at increasing intervals, often for several days. Only after that period does it give up and send you a bounce message explaining that delivery failed. If the address simply does not exist, the receiving server usually says so straight away, and the bounce arrives within seconds.
Checking the message is genuine
SMTP was designed at a time when the people on the network largely trusted each other. It does not, on its own, check that a message claiming to come from your bank actually came from your bank. Anyone can write any address in the “From” line. To deal with forged mail and spam, receiving servers now run a series of checks before accepting a message into your inbox. Three of them rely on information that domain owners publish in DNS.
SPF: who is allowed to send
SPF, the Sender Policy Framework, lets a domain publish a list of the servers that are allowed to send mail on its behalf. When a message arrives, the receiving server checks whether the machine that connected to it is on that list for the sending domain. If a message claiming to be from a domain arrives from an unrelated server, that is a warning sign.
DKIM: a tamper-evident seal
DKIM, DomainKeys Identified Mail, works more like a wax seal. The sending server adds a digital signature to the message, created with a private key that only the sender holds. The matching public key is published in DNS. The receiving server uses it to check that the signature is valid, which shows that the message came through a system controlled by that domain and that the signed parts were not altered on the way.
DMARC: what to do when checks fail
DMARC, Domain-based Message Authentication, Reporting and Conformance, ties the other two together. It asks whether the domain in the visible “From” address lines up with a domain that passed SPF or DKIM. It also lets the domain owner publish a policy telling receivers what to do with mail that fails: deliver it anyway, send it to spam, or reject it outright. Receivers can also send reports back to the domain owner, which helps organisations spot people trying to impersonate them.
None of these checks decides by itself whether a message is spam. They establish whether the sender is who it claims to be. After that, receiving systems apply their own filters, which look at the content, links and attachments, the sender’s past behaviour, and how other recipients have treated similar messages.
Email was built for a small network of people who trusted each other, and much of what happens after you press send is an effort to cope with the fact that this is no longer true.
Arriving in the mailbox and reaching your devices
Once the receiving server accepts the message, it passes it to the part of the system that stores mail. It works out which mailbox the local part of the address refers to, applies any rules the recipient has set up, such as filters or forwarding, and files the message in the right folder.
At this point the message is sitting on a server. Getting it onto the recipient’s phone and laptop is a separate job, handled by a different protocol. Most people today use IMAP, the Internet Message Access Protocol, or a provider’s own equivalent. With IMAP, the server keeps the master copy of every message and folder, and each device keeps itself in sync. Read a message on your phone and it shows as read on your laptop. Delete it on the laptop and it disappears from the phone.
An older protocol, POP3, works differently: it downloads messages to one device and, by default, removes them from the server. It still exists, but it fits poorly with a world in which most people read mail on several devices.
How quickly a new message appears depends on the device and app. Many apps hold a connection open so the server can notify them immediately, while others check at intervals to save battery. Phones often rely on the operating system’s push notification service to wake the mail app when something arrives.
Why email is sometimes late or lands in spam
Most emails arrive within seconds. When one does not, the cause is usually somewhere along the chain above.
Queues and retries. If the receiving server was briefly unavailable or overloaded, your provider will have queued the message and tried again later.
Greylisting. Some servers deliberately refuse the first attempt from an unfamiliar sender and accept it when it is retried. Legitimate servers retry; many spam tools do not. The cost is a delay of minutes for the first message.
Heavy filtering. Workplace systems may scan attachments and links in detail before releasing a message, which takes time.
Device sync. The message may have arrived on the server promptly, but the recipient’s app has not checked yet.
Messages land in spam for a different set of reasons. A domain with missing or broken SPF, DKIM or DMARC records looks less trustworthy. So does mail sent through a server that has recently been used for spam, messages with lots of links or unusual attachments, and newsletters that many recipients mark as junk. Small organisations often discover their mail is going to spam because nobody ever set up these DNS records after changing email provider.
Consider Leon, who runs a two-person bookkeeping practice. After moving his business email to a new provider, clients started finding his invoices in their spam folders. His domain still had an SPF record listing only the old provider’s servers, so every message now came from an “unauthorised” sender. Updating the record and turning on DKIM signing in the new provider’s settings fixed the problem within a day.
What “unsend” really does
Many mail apps now offer an undo or unsend button for a few seconds after you press send. It can feel as though the app is reaching into someone else’s inbox to retrieve your message. It is doing something much simpler.
When undo is turned on, the app does not send the message immediately. It holds it for a short delay, often somewhere between a few seconds and half a minute depending on the app and your settings. If you press undo during that window, the message is never handed to the outgoing server at all. Once the delay has passed and the message has been delivered to the recipient’s server, it cannot be pulled back by the sender, because it now sits on a machine the sender does not control.
Some workplace email systems offer a separate “recall” feature for messages sent within the same organisation. It depends on both people using the same system and on the message not having been opened, so it is unreliable enough that you should treat any sent email as sent.
A few habits follow from all this:
Turn on the undo delay and set it as long as your app allows, if you ever send in a hurry.
Add the recipient’s address last, so a half-finished message cannot go out by accident.
If you own a domain, check that its SPF, DKIM and DMARC records are in place and up to date.
When a message seems lost, check the spam folder before resending, and give queued mail a little time.
Pressing send starts a relay that crosses several independent systems, each doing its own job and checking the work of the one before. It usually runs so smoothly that nobody notices, and knowing where it can stall makes the occasional delay a lot less puzzling.
Written by
Owen Achterberg
Owen writes about the practical side of work: handovers, tools and the systems behind everyday technology. He spent ten years in IT support before he started writing.
