The Invisible Journey Every Email Takes
Every time you receive an order confirmation or password reset, an invisible chain of events fires in milliseconds. Understanding that chain — even at a high level — makes you a far more effective developer or digital communicator. This guide breaks down how email actually works, from the moment a send button is pressed to the message landing in an inbox.
The Core Protocol: SMTP
SMTP (Simple Mail Transfer Protocol) is the standard protocol for sending email. Defined in RFC 5321, it has been the backbone of internet email since the early 1980s. When your application or email client sends a message, it speaks SMTP to a mail server, which then relays the message toward its destination.
Key things to know about SMTP:
- It operates on port 25 (server-to-server), port 587 (submission with authentication), or port 465 (SMTPS, encrypted).
- It is a push protocol — it delivers mail outward. Receiving email uses different protocols (IMAP or POP3).
- SMTP servers are called MTAs (Mail Transfer Agents). Well-known examples include Postfix, Sendmail, and the servers behind services like SendGrid or AWS SES.
Step-by-Step: What Happens When an Email Is Sent
- Composition: Your application constructs an email message in MIME format, including headers (From, To, Subject, Date) and a body (plain text and/or HTML).
- Submission: The message is submitted to your outbound SMTP server (your MTA) using authenticated SMTP on port 587.
- DNS Lookup: Your MTA looks up the recipient domain's MX (Mail Exchange) records in DNS to find out which server accepts mail for that domain.
- Relay: Your MTA connects to the recipient's MTA and delivers the message using SMTP. There may be intermediate relay servers along the way.
- Delivery: The recipient's MTA places the message in the appropriate mailbox.
- Retrieval: The recipient's email client fetches the message using IMAP or POP3.
Understanding Email Headers
Email headers are metadata fields prepended to every message. They document the message's journey and are invaluable for debugging deliverability problems. Key headers include:
- From: The displayed sender address.
- Reply-To: Where replies should be directed (can differ from From).
- Return-Path: Where bounce messages are sent — critical for bounce management.
- Received: Added by each server that handles the message, creating an audit trail.
- Message-ID: A unique identifier for the message.
- DKIM-Signature: A cryptographic signature used to verify the message wasn't tampered with in transit.
Plain Text vs. HTML Email
Modern emails are almost always sent as multipart/alternative MIME messages, containing both a plain text version and an HTML version. Email clients choose which to display based on user preferences and client capabilities. Best practice is always to include both:
- Plain text: Maximum compatibility, always accessible, preferred by some users and spam filters.
- HTML: Rich formatting, branding, images, and buttons. Required for modern transactional email design.
Why This Matters for Notification Systems
If you're building or managing automated notification emails, understanding the underlying mechanics helps you:
- Debug why messages aren't being delivered.
- Correctly configure authentication records (SPF, DKIM, DMARC) to improve deliverability.
- Interpret bounce codes and understand what went wrong.
- Choose the right sending infrastructure for your volume and use case.
Email may look simple from the outside, but it's a remarkably robust distributed system — and knowing how it works gives you a real edge in keeping your notifications reliable.