You open Gmail, Outlook, or your favorite email app, write a message, attach a few files, and click Send. A second later, the email appears in your Sent folder, making it feel like the message simply traveled from your computer to someone else's inbox.
But that's not really what happens.
Behind that single click, multiple systems work together. Your message has to leave your device, reach your email provider, find the recipient's mail server, pass security checks, get stored, and finally synchronize with the recipient's device.
Unlike a typical chat message, email follows a store-and-forward model. A message can be accepted, queued, inspected, stored, and forwarded by different systems before reaching the final mailbox.
So what actually happens after you press Send?
Let's follow the journey.
1. Your Email Is Prepared
Suppose you're sending an email to:
alex@example.com
You might write:
To: alex@example.com
Subject: Project Update
Hi Alex,
The project is almost complete.
I'll send the final version tomorrow.
Thanks,
Nayan
Before anything travels across the internet, your email application creates the message that needs to be transmitted. An email is more than the text displayed on screen; it also contains headers and metadata used by mail systems during processing.
Common headers include:
FromToSubjectDateMessage-IDContent-Type- Attachment information
For example, Message-ID can identify a particular email, while Content-Type tells the receiving system how to interpret its content.
If your email contains an attachment, the message also needs to represent it using email standards such as MIME, or Multipurpose Internet Mail Extensions.
So before your email leaves your device, it has already been converted into a structured message ready for transmission.
2. Your Email App Connects to Your Mail Provider
When you press Send, your application communicates with an email service.
If you're using Gmail, Google's infrastructure handles the message. With Outlook, Microsoft's infrastructure handles it. The exact architecture differs between providers, but the basic idea is the same: your application submits the message to a mail service that takes responsibility for delivery.
Several protocols can be involved.
SMTP
SMTP, or Simple Mail Transfer Protocol, is primarily responsible for submitting and transferring email between mail systems.
IMAP
IMAP, or Internet Message Access Protocol, is mainly used for accessing and synchronizing messages stored on a mail server.
That's why an email you read on your laptop can also appear as read on your phone.
POP3
POP3, or Post Office Protocol version 3, is another email retrieval protocol. Traditionally, it was designed around downloading messages from a server.
A simplified view is:
Sending / transferring → SMTP
Synchronizing mail → IMAP or provider APIs
Traditional retrieval → POP3
Modern applications may also use provider-specific APIs and synchronization systems.
3. The Connection Is Protected and Your Account Is Authenticated
Your email credentials and message aren't normally sent as plain network traffic. Modern email services use TLS (Transport Layer Security) to protect communication between systems.
You may encounter secure communication through:
HTTPS
SMTPS
IMAPS
For SMTP submission, port 587 is commonly used with TLS protection.
However, an important distinction is that encryption in transit isn't automatically end-to-end encryption. TLS protects communication between systems, but it doesn't necessarily mean that only the sender and recipient can access the message.
Your provider must also establish that you're authorized to send the email. Older systems commonly used usernames and passwords, while modern applications may use mechanisms such as OAuth 2.0 and access tokens.
Authentication answers:
"Who are you?"
Authorization answers:
"Are you allowed to perform this action?"
Once this is confirmed, the provider can process the message for delivery.
4. DNS Helps Find the Recipient's Mail Server
Your email is addressed to:
alex@example.com
Your mail provider needs to determine which server is responsible for receiving messages for example.com.
This is where DNS, or Domain Name System, becomes important.
DNS doesn't only map domain names to IP addresses. It also stores several types of records, including MX records.
MX stands for Mail Exchange.
An MX record tells sending mail systems which servers are responsible for receiving email for a domain.
For example:
example.com
MX 10 mail.example.com
MX 20 backup.example.com
The numbers represent priorities, which help a mail system determine which destination to use.
You can inspect MX records yourself:
dig MX example.com
Or:
nslookup -type=MX example.com
At this point, the sending system has gone from knowing an email address to discovering the infrastructure responsible for receiving mail for that domain.
5. Your Laptop Usually Isn't Sending Directly to the Recipient
A common misconception is that clicking Send creates a direct connection between your laptop and the recipient's computer.
Usually, it doesn't.
Your email provider handles most of the delivery work.
A simplified journey looks like this:
Your Device
↓
Your Email Provider
↓
Recipient's Mail Provider
↓
Recipient's Mailbox
↓
Recipient's Email App
The real infrastructure can be much more complicated. Large providers may use load balancers, multiple mail servers, message queues, databases, distributed storage, and security services.
The important idea is that your device doesn't need to understand the entire delivery infrastructure. It submits the message to its mail provider, which takes responsibility for moving it toward its destination.
6. SMTP Transfers the Email Between Mail Systems
Once the sending mail system knows which server should receive the message, the two systems can communicate using SMTP.
A simplified SMTP conversation might look like:
Client: EHLO mail.sender.com
Server: 250 OK
Client: MAIL FROM:<nayan@sender.com>
Server: 250 OK
Client: RCPT TO:<alex@example.com>
Server: 250 OK
Client: DATA
Server: 354 Start mail input
The message contents are then transmitted. After the message has been completely sent, the receiving system can respond with something like:
250 Message accepted
This demonstrates an important concept:
Email delivery is a conversation between mail systems.
The receiving server can accept the message, reject it, temporarily defer it, or perform additional processing.
This is also where the store-and-forward model becomes useful. If the destination server is temporarily unavailable, the sending system can keep the message in a queue and retry later.
7. Email Authentication: SPF, DKIM, and DMARC
Getting a message to the recipient's mail server doesn't automatically mean it will appear in the inbox.
Modern email systems use authentication technologies to help determine whether a message claiming to come from a domain is legitimate.
SPF
SPF, or Sender Policy Framework, allows a domain owner to publish which servers are authorized to send email for that domain.
This information is published through DNS.
A simplified SPF record might look like:
v=spf1 include:_spf.provider.com ~all
The receiving system can compare the sending server with the domain's SPF policy.
In simple terms, SPF asks:
Is this server authorized to send mail for this domain?
DKIM
DKIM, or DomainKeys Identified Mail, uses cryptographic signatures.
The sending mail system adds a signature to the message. The receiving system retrieves the corresponding public key from DNS and verifies it.
Sending System
↓
Private Key
↓
DKIM Signature
↓
Email
↓
Receiving System
↓
Public Key from DNS
↓
Signature Verification
DMARC
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, works alongside SPF and DKIM.
A domain owner can publish a policy describing how receiving systems should handle messages that fail relevant authentication checks.
Email
↓
SPF / DKIM
↓
DMARC Policy
↓
Accept / Quarantine / Reject
Together, these technologies provide receiving systems with additional signals when evaluating incoming messages.
8. Spam, Malware, and Security Checks
Even if an email passes authentication checks, it can still be classified as spam.
Modern filtering can consider signals such as:
- Sender reputation
- IP and domain reputation
- Authentication results
- Message content
- Links
- Attachments
- Sending patterns
- Previous interactions
- User reports
Providers may also scan attachments for malware and examine links or patterns associated with phishing.
The exact filtering algorithms are generally proprietary and can change over time. That's why two similar emails can sometimes receive different treatment.
One may reach the inbox while another ends up in spam.
So the journey isn't simply:
Send → Inbox
There are several security and filtering decisions in between.
9. What Happens to Attachments?
Suppose you attach:
project.zip
Email systems don't simply treat that file like an ordinary file transfer. Email messages use standards such as MIME to represent different types of content.
For example:
Content-Type: text/plain
or:
Content-Type: text/html
Attachments can also be represented using MIME headers and encoded so they can travel through systems designed around email message formats.
Historically, binary information was commonly encoded using mechanisms such as Base64. This increases the size of binary data, meaning an email with a large attachment can consume more data than the original file itself.
Attachments may also pass through security systems that scan them for malicious content before delivery.
10. The Email Is Stored in the Recipient's Mailbox
Once the receiving system accepts the message, it needs somewhere to store it.
For a large provider, this usually isn't one file sitting on one physical computer. Large providers operate distributed storage and processing infrastructure.
A simplified representation is:
Receiving Mail Server
↓
Mail Processing
↓
Security / Filtering
↓
Mailbox Storage
The exact architecture varies between providers, but the important result is that the message becomes part of the recipient's mailbox.
The store-and-forward model also helps when a destination server is temporarily unavailable.
For example, the destination might respond with:
421 Service temporarily unavailable
The sending system can then:
1. Queue the message
2. Wait
3. Retry delivery
4. Deliver it when available
If delivery continues to fail, the sender may eventually generate a bounce or delivery failure notification.
11. How Does the Recipient's Phone Know About the Email?
Once the email is in the recipient's mailbox, another system needs to tell the recipient's device that something changed.
Depending on the provider and application, synchronization can involve persistent connections, push notification infrastructure, provider-specific APIs, or other mechanisms.
A simplified sequence is:
New email reaches mailbox
↓
Provider detects mailbox change
↓
Notification / synchronization signal
↓
Recipient's phone
↓
Email application synchronizes
↓
Message appears
This is why a notification can appear only a few seconds after the sender presses Send.
The email isn't necessarily traveling directly from the sender's laptop to the recipient's phone. The mailbox and synchronization infrastructure are in the middle.
12. TLS Is Not the Same as End-to-End Encryption
This distinction is important.
TLS protects communication while data is moving between systems.
For example, a connection between two mail servers can be encrypted using TLS. But that doesn't automatically mean only the sender and recipient can read the email.
In many conventional email systems, the provider operates the mailbox and associated infrastructure and may be able to access stored message contents.
Technologies such as PGP or S/MIME can provide message-level encryption.
The basic idea is that the sender encrypts the message using the recipient's public key, and the recipient uses the corresponding private key to decrypt it.
Sender
↓
Recipient's Public Key
↓
Encrypted Message
↓
Internet
↓
Recipient's Private Key
↓
Readable Message
So:
TLS protects the communication channel.
End-to-end encryption protects the message itself between the intended endpoints.
These are different security concepts.
13. Why Email Can Be Spoofed and Why Delivery Can Be Delayed
You may receive an email that appears to come from someone you know:
From: CEO@example.com
But the displayed sender address alone doesn't guarantee that the message was genuinely sent by that person.
SPF, DKIM, and DMARC help reduce certain types of sender impersonation, but no single mechanism makes every email automatically trustworthy.
Email delivery can also take longer than usual because of:
- Mail server overload
- DNS problems
- Security filtering
- Temporary server failures
- Queueing
- Large attachments
- Additional security scanning
So email isn't really:
Send → Receive
It's closer to:
Create
↓
Authenticate
↓
Submit
↓
Resolve
↓
Transfer
↓
Verify
↓
Scan
↓
Store
↓
Synchronize
↓
Display
That's a lot of infrastructure hiding behind one button.
14. The Complete Journey
Let's put everything together.
When you click Send, your email client prepares the message, including its headers, body, and attachments. It then communicates with your mail provider, where your account is authenticated and authorized.
The mail system determines the recipient's domain and uses DNS to find the appropriate MX records. It then communicates with the recipient's mail infrastructure using SMTP.
The receiving system can evaluate SPF, DKIM, and DMARC information, perform spam and malware checks, and decide whether to accept the message. If accepted, the email is stored in the recipient's mailbox.
Finally, synchronization and notification systems let the recipient's application know that a new message is available.
The complete journey looks like this:
Your Email Client
↓
Your Mail Provider
↓
Authentication
↓
DNS / MX Lookup
↓
Recipient Mail Server
↓
SMTP Transfer
↓
SPF / DKIM / DMARC
↓
Spam & Malware Filtering
↓
Mailbox Storage
↓
Synchronization
↓
Recipient's Email App
The Bigger Picture
Email isn't handled by one giant machine called "the email server."
Instead, it is a collection of systems working together:
- Email clients
- SMTP servers
- DNS infrastructure
- MX records
- SPF, DKIM, and DMARC
- Spam filters
- Malware scanners
- Message queues
- Distributed storage
- Synchronization systems
- Notification services
Each component has a different responsibility. Your email client doesn't need to understand the entire internet; it simply submits the message to the appropriate service, and the mail infrastructure handles the rest.
Final Thoughts
The next time you click Send, remember that you're not simply moving text from one computer to another.
A single email can involve DNS lookups, SMTP connections, TLS, authentication, SPF, DKIM, DMARC, spam filtering, malware scanning, MIME processing, queues, distributed storage, and mailbox synchronization.
And yet, from your perspective, the entire process is reduced to one simple action:
Click Send.
That's one of the most interesting things about the internet. The interfaces we use every day often hide enormous amounts of engineering underneath them.
The next time an email arrives almost instantly, you'll know there was much more happening behind the scenes than:
Send → Receive
Top comments (0)