What Happens When You Press Send on an Email

Pressing Send sets off a small postal bureaucracy. Your app hands the message to your provider's outgoing server using SMTP, that server asks the internet's directory where the recipient's domain receives mail, the message hops from server to server — each stop running it through fraud and spam inspection — and it finally lands in a mailbox on the recipient's server, waiting for their app to fetch it. The whole trip usually takes seconds. It is also far more fragile than it looks.

Submission: Your App Hands the Letter to the Post Office

The journey does not start with the recipient. It starts with submission: your email client or webmail composes a standard message — headers like From, To, Date, and Subject plus the body — and delivers it to your provider's outgoing mail infrastructure over SMTP, the Simple Mail Transfer Protocol.

SMTP is a sending protocol only; it never retrieves mail. Modern clients submit over port 587 with authentication, or port 465 with an encrypted TLS connection from the start, while server-to-server relay traditionally uses port 25. The client identifies itself, provides the envelope sender, names the recipient, and transmits the message. If your provider's server is down or your credentials are wrong, the failure happens right here, before anything leaves home.

One nuance people miss: the "envelope" the servers read is not the same as the From line you see. The envelope sender is what authentication checks later will actually verify — a distinction that matters enormously when fraud enters the picture.

The Address Book of the Internet: DNS and MX Records

Your provider now needs directions. It takes the part of the address after the @ sign and asks the Domain Name System for that domain's MX records — Mail Exchange records. These records list the servers authorized to receive email for the domain, each with a priority number where a lower number means try me first: 10 mail1.example.com beats 20 mail2.example.com.

The sending server resolves the winning hostname to an IP address and opens an SMTP conversation: EHLO to introduce itself, MAIL FROM for the envelope sender, RCPT TO for the recipient, DATA for the message itself, with numeric status codes after each step. If the preferred server refuses the connection, the sender walks down the priority list — redundancy is built into the protocol, which is one reason email has survived for half a century.

And email is patient in a way that surprises people used to instant messaging. It is a store-and-forward system: if the receiving server is temporarily unavailable, the sending server queues the message and retries later, sometimes for days. Delivery can be delayed by greylisting, throttling, or a full queue — a reminder that "sent" and "delivered" were never the same thing. Much of this traffic ultimately rides across the ocean floor, on the same fiber arteries that carry the rest of the internet's load.

The Border Inspection: SPF, DKIM, and DMARC

Before any message is trusted, the receiving server inspects its papers. Three DNS-published records do the work. SPF (Sender Policy Framework) lists which servers are allowed to send on the domain's behalf — if your message arrives from an IP the domain never authorized, it fails. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the message, letting the receiver verify that the signed parts were not altered in transit and that the signing domain takes responsibility for them. DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties them together: it requires alignment between the domain you see in the From line and the domains that passed SPF or DKIM, and it publishes the domain owner's policy for failures — accept, quarantine, or reject.

This inspection got teeth in recent years. In 2024, Gmail and Yahoo began requiring valid SPF, DKIM, and DMARC from bulk senders, with roughly 5,000 messages a day marking the bulk threshold. Through 2025, Gmail moved from politely deferring non-compliant mail to rejecting it outright, and Outlook.com returns outright access-denied errors for high-volume senders that fail authentication. Miss the three records, and your message does not go to spam — it is refused at the door.

Alongside authentication, the receiving server weighs spam signals: sending-IP reputation, malware or suspicious attachments, malformed formatting, complaint rates, and content patterns. It may accept the message to the inbox, file it in spam, or bounce it. Every one of these judgments runs on metadata and reputation, not on reading your words — though that metadata is exactly why email sits at the center of the identity-privacy debate.

Delivery, Storage, and the Final Fetch

Once accepted, the message is stored in the recipient's mailbox on the server. Email delivery ends at the server, not the screen. What happens next is the recipient's app checking in: IMAP is designed for reading and syncing mail that stays on the server across devices, while POP3 is mainly for downloading it off. When the app syncs, the message finally appears.

This two-stage design explains several everyday mysteries. An email "arrives" on your laptop but not your phone? One client fetched via POP3 and pulled it off the server. A message shows as read everywhere at once? IMAP sync. An email you sent at noon bounces at midnight? The sender's queue retried until it expired. None of these are bugs; they are the store-and-forward architecture working as designed.

There is one more quiet truth about this final stage. The recipient's server accepted the message, but acceptance is not approval — filters can still quarantine it, and a DMARC policy of reject from the sender's own domain can have the receiver discard forgeries before they ever reach the mailbox. Your inbox is the end of a chain of handoffs, lookups, queues, and inspections, each of which could have gone differently.

The next time you press Send, picture it: a standard-formatted envelope, a DNS lookup for the right post office, a relay of server-to-server handoffs with retry queues, a border inspection of cryptographic papers, and a mailbox waiting at the far end. It feels instant because fifty years of engineering made the bureaucracy invisible. It works because, at every step, the message carries proof of where it came from.