Updated 10 hours ago
Click Send and your message vanishes into the ether. A moment later, it appears in someone else's inbox, possibly on the other side of the world. What happened in between?
The answer is a story of trust. Your email passes through a chain of servers, each one asking the same questions: Who are you? Can I trust you? Will you take responsibility for this message? The technology is complex, but the social dynamics are ancient.
Composing: The Message Takes Shape
You open Outlook, type a message to colleague@company.com, attach a document, click Send.
Behind the scenes, your email client builds a structured message following RFC 5322. It adds headers—From, To, Subject, Date, a unique Message-ID. If you attached files, it encodes them using MIME, converting binary data into text that can safely travel through systems designed decades ago for plain text.
The message is ready. Now it needs somewhere to go.
First Handshake: Your Outgoing Server
Your email client connects to your provider's SMTP server—smtp.yourprovider.com—on port 587. What follows is a conversation:
The server announces its capabilities. STARTTLS means it can encrypt the connection. AUTH means it requires authentication.
Your client requests encryption:
The connection upgrades. Everything from here travels through an encrypted tunnel—your password, your message, invisible to anyone listening on the wire.
Now authentication:
Your email client has proven its identity. Only now will the server accept your outgoing mail. This prevents strangers from using your provider's servers to send spam.
Handing Over the Message
With trust established, your client transmits:
Your email client displays "Message sent." Your part is done. But the message's journey has barely begun—it's sitting in a queue on your provider's server, waiting for the next leg.
Finding the Destination
Your provider's server extracts the domain from the recipient address: colleague@company.com → company.com. Where does mail for company.com actually go?
It asks DNS:
MX records—Mail Exchange records—point to the servers that handle incoming mail for a domain. The numbers are priorities: lower is better. mail1.company.com is the primary; mail2.company.com is the backup.
Another DNS query resolves mail1.company.com to an IP address: 203.0.113.50. Now your provider's server knows exactly where to connect.
Second Handshake: Server to Server
Your provider's server reaches out to 203.0.113.50 on port 25—the standard port for server-to-server email:
Again, the dance of capabilities and encryption. The servers negotiate TLS, upgrading to an encrypted channel before any message content flows.
The Identity Crisis
Here's the fundamental problem with email: anyone can claim to be anyone. I could configure a server to announce itself as "whitehouse.gov" and start sending messages. In the early days of email, this was rampant.
So before accepting your message, the recipient's server runs authentication checks:
SPF (Sender Policy Framework): Is your provider's IP address actually authorized to send mail for yourprovider.com? The server checks DNS records that list approved senders.
Reverse DNS: Does your provider's IP address have a valid reverse DNS entry? Legitimate mail servers identify themselves; spammers often don't bother.
DKIM (DomainKeys Identified Mail): Does the message carry a cryptographic signature that can be verified against public keys in DNS? This proves the message hasn't been tampered with.
Reputation: Is your provider's IP address on any blacklists? Has it been seen sending spam?
These checks happen in milliseconds. They're the digital equivalent of checking someone's ID, calling their references, and looking them up in a database of known troublemakers—all before deciding whether to accept a package from them.
Transfer of Responsibility
Authentication passes. Your provider's server transmits the message:
That "250 OK" is a promise. The recipient's server has taken responsibility for this message. Your provider's server can now delete it from its queue—if something goes wrong from here, it's not their problem.
The recipient's server stamps the message with a Received header, documenting the handoff:
These headers accumulate as a message travels. Reading them bottom-to-top tells the complete story of its journey.
Local Delivery
The recipient's mail server hands the message to its Mail Delivery Agent. This component:
- Verifies colleague@company.com exists
- Runs spam filters and applies rules
- Checks that the mailbox isn't over quota
- Writes the message to storage
Your email now sits in your colleague's mailbox, waiting.
The Final Mile
Minutes later, your colleague's email client checks for new mail. Using IMAP, it connects:
Five new messages. The client fetches headers, displays the list. Your colleague sees your name, clicks. The client retrieves the full message and attachments.
Journey complete.
When the Chain Breaks
Email delivery can fail at any link:
- DNS misconfiguration: The sending server can't find where to deliver
- Full mailbox: The recipient's server rejects new messages
- Spam filters: Legitimate mail gets quarantined
- Authentication failures: SPF, DKIM, or DMARC checks fail
- Network issues: Servers can't connect to each other
Most failures generate bounce messages—automated replies explaining what went wrong. Understanding the journey helps you read these bounces and fix the underlying problems.
The Invisible Infrastructure
Behind every step lies additional complexity:
Queueing: If delivery fails temporarily, servers retry for days before giving up.
Load balancing: Large providers spread mail across hundreds of servers.
Virus scanning: Attachments are checked for malware.
Logging: Every handshake is recorded for troubleshooting.
The whole journey typically takes seconds. But the infrastructure that makes it possible—the DNS records, the authentication systems, the trust relationships between providers—took decades to build.
What to Remember
Email is a chain of trust negotiations. Your client proves identity to your server. Your server proves identity to the recipient's server. Each handoff involves verification, encryption, and an explicit transfer of responsibility.
The SMTP protocol is a conversation—servers literally talking to each other, asking permission, confirming receipt. DNS MX records tell senders where to find recipients. SPF, DKIM, and DMARC answer the question that haunts all Internet communication: "Are you really who you say you are?"
Next time you click Send, you're not just transmitting data. You're initiating a series of introductions, verifications, and promises that span the globe in seconds.
Frequently Asked Questions About Email Delivery
Was this page helpful?