How Email Works
From the moment you hit send to the second it lands in the inbox: a journey through SMTP, DNS, authentication, bounces and the quirks of email clients.
Start the journeyThe email is composed
From a friendly UI to the raw RFC 5322 message format
From: [email protected]
To: [email protected]
Subject: Lunch tomorrow?
Date: Tue, 18 Aug 2026 19:36:19 +0000
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b_9f3a1c7e"
--b_9f3a1c7e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Hey Bob,
want to grab lunch at noon?
Alice
--b_9f3a1c7e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<html><body><p>Hey Bob,<br><br>want to grab lunch at noon?<br><br>Alice</p></body></html>
--b_9f3a1c7e--Every email follows RFC 5322: a plain-text format with headers, a blank line, then the body. Even attachments and HTML are just text, encoded with MIME and separated by boundary strings.
Anatomy of an email
An envelope, headers and a body: three layers most people never see
The envelope sender and the visible From header can differ. That is how legitimate forwarding works, and also how phishing tries to fool you. SPF, DKIM and DMARC exist to keep these honest.
Transport: two ways to send
Direct SMTP gives you control. Amazon SES handles the hard parts.
- Client → Your MTA EHLO mail.example.com Greet the server and negotiate TLS and authentication
- Your MTA → DNS MX acme.io ? Look up the mail server responsible for the recipient domain
- DNS → Your MTA → mx1.acme.io (priority 10) DNS responds with the MX records
- Your MTA → Receiver MTA MAIL FROM: <[email protected]> Set the envelope sender
- Your MTA → Receiver MTA RCPT TO: <[email protected]> Set the envelope recipient
- Your MTA → Receiver MTA DATA … <message> . Stream the message, terminated by a single dot on its own line
- Receiver MTA → Your MTA 250 OK queued as A1B2C3 Accepted into the receiving queue
- Client → SES API POST /v2/email/outbound-emails HTTPS API call with signed AWS credentials
- SES DKIM sign + configuration set SES signs with DKIM and applies your configuration set
- SES MTA pool → DNS MX acme.io ? SES does the MX lookup for you
- SES MTA pool → Receiver MTA EHLO + STARTTLS + MAIL FROM / RCPT TO / DATA The same SMTP conversation, but from a warmed-up IP pool
- Receiver MTA → SES MTA pool 250 OK Accepted
- SES → SNS events Publish 'Delivery' event You get notified via SNS or an event destination
With direct SMTP you operate your own MTA such as Postfix, Exim or Haraka. You are responsible for IP reputation, warm-up, retries, bounce handling, DKIM keys and TLS. Maximum control, maximum maintenance.
With Amazon SES you make a single HTTPS API call. SES handles DKIM signing, IP rotation across a warm pool and retries with exponential back-off, and it emits bounce, complaint and delivery events to SNS so your application can react.
Authentication
Three DNS-based checks that prove an email really comes from who it claims
SPF: Sender Policy Framework
The receiving server asks: is this connecting IP allowed to send for this domain? SPF lists the authorized IPs and services in DNS. Pass means the IP is authorized.
DKIM: DomainKeys Identified Mail
The sender signs the message with a private key. The receiver fetches the public key from DNS and verifies the signature, which proves the message was not tampered with in transit.
DMARC: policy and alignment
DMARC ties SPF and DKIM to the visible From domain (alignment) and tells the receiver what to do when the checks fail: nothing, quarantine or reject. It also sends aggregate reports back to the domain owner.
Receiving server check
- Connection from an authorized IP ok
- Signature verifies against the public key ok
- From domain aligns with the authenticated domain ok
- DMARC policy: pass ok
Together, SPF, DKIM and DMARC are the modern minimum to reach the inbox. Gmail, Yahoo and Apple now require them for bulk senders. Skip them and your mail bounces or lands in spam.
When delivery fails: bounces
The receiver could not accept the message. Here is why, and what to do about it.
Anatomy of a bounce
Common SMTP responses
Common SMTP responses
Common SMTP responses
Why bounces hurt
- A high bounce rate tanks your sender reputation with mailbox providers.
- Amazon SES puts accounts under review above a 5% bounce rate and pauses sending around 10%.
- Bounces count as spam signals, so even your good emails start landing in junk.
- Repeated bounces to the same addresses can get your sending domain blocklisted.
What to do about it
- Suppression list: Never send to a hard-bounced address again. SES maintains one per account automatically.
- Double opt-in: Confirm new addresses with a click before adding them to your list. This kills typos and spam traps.
- List hygiene: Remove addresses without engagement after 6 to 12 months and re-validate with a verification service.
- Warm-up: Ramp volume up slowly over weeks so receivers learn to trust your IP and domain.
- Authenticate: SPF, DKIM and DMARC, properly aligned. Skipping them is the top cause of reputation blocks.
- Listen to events: On SES, subscribe to the bounce and complaint topics and process them in real time.
Bounces are not bugs, they are feedback. A healthy sending program treats every bounce as a signal: clean the list, fix the authentication, slow down the ramp. The senders who reach the inbox are the ones who pay attention.
Different clients, different worlds
The same email is interpreted very differently depending on who opens it
How it handles images
Loaded through the Google image proxy (googleusercontent.com).
What that means for tracking
Tracking pixels fire as soon as the email is opened, but the request comes from a Google IP, not from the reader. Images are cached, so the pixel fires once.
Privacy posture
Medium: the IP is hidden, but the open itself is still detectable.
Quirks every sender should know
- Supports embedded CSS only partially; complex styles are best inlined
- Clips messages over 102 KB behind a "view entire message" link
- Auto-links URLs and may add its own unsubscribe link for bulk senders
How it handles images
Blocked by default. The reader must click "download images", and images then load directly from the origin server, exposing the reader's IP.
What that means for tracking
Tracking pixels only fire if the reader explicitly loads images, so opens from Outlook are dramatically under-reported.
Privacy posture
High: by default nothing external is loaded.
Quirks every sender should know
- Renders HTML with Word, so flexbox, grid and modern CSS are mostly ignored
- Often the reason marketing emails arrive with broken layouts
- Needs VML for background images and bulletproof buttons
How it handles images
With Mail Privacy Protection, the default since iOS 15, Apple pre-loads all images through a proxy when the message arrives, even if the reader never opens it.
What that means for tracking
MPP makes opens nearly meaningless: every email looks opened, from a rotating Apple IP, and geolocation is obscured too.
Privacy posture
Very high: Apple actively breaks tracking by design.
Quirks every sender should know
- Best CSS support of any major client: flexbox, grid and dark-mode media queries all work
- MPP affects roughly half of all email opens worldwide
- Forces senders to measure clicks instead of opens
The tracking pixel, three ways
- Reader opens the email
- Google fetches the image once
- Caches it on the Google CDN
- Pixel fires from a Google IP
- Reader opens the email
- Images stay blocked
- Reader clicks "download images"
- Pixel fires from the reader's IP
- Email arrives on the device
- Apple pre-fetches via proxy
- Even if it is never opened
- Pixel fires from an Apple IP
The same tracking pixel behaves completely differently depending on the client. That is why the open rate has become an unreliable metric, and why click-based engagement is taking over.
Calendar invitations: iMIP
When Outlook, Google Calendar and Apple Calendar agree on a meeting, they speak email
Scheduling across providers needs no central server: invitations, acceptances and cancellations travel as perfectly ordinary emails. Three standards split the work, and iMIP (RFC 6047) is the bottom layer: it wraps the scheduling message into a mail as a MIME part with Content-Type: text/calendar; method=…
The data format: VEVENT, DTSTART, ATTENDEE, an event as structured text.
The choreography: who may do what, REQUEST, REPLY, COUNTER, CANCEL and the SEQUENCE rules.
The transport: the iTIP message travels as a text/calendar MIME part inside a regular email.
SEQUENCE:0 STATUS:CANCELLED
You are Alice, planning a kickoff. Invite Bob, Carol and Dave: one email with METHOD:REQUEST to all three.
Messages in transit …
Dave counter-proposes 16:00. Only the Organizer may change the event: send an update with a bumped SEQUENCE, or cancel.
Everyone accepted. Same UID, SEQUENCE:1: every attendee's calendar now shows 16:00 automatically.
Cancelled. The CANCEL carries the same UID, so every client knows which event to remove.
NEEDS-ACTION
NEEDS-ACTION
NEEDS-ACTION
- alice → bob, carol, dave METHOD:REQUEST · SEQUENCE:0 The invitation: a VEVENT with ORGANIZER, three ATTENDEE lines and RSVP=TRUE.
- bob → alice METHOD:REPLY · PARTSTAT=ACCEPTED Bob accepts. His client only changes his own PARTSTAT, that is all an attendee may do.
- carol → alice METHOD:REPLY · PARTSTAT=TENTATIVE Carol is unsure and replies with TENTATIVE.
- dave → alice METHOD:COUNTER · DTSTART 16:00 Dave proposes a new time via COUNTER, the decision stays with Alice.
- alice → bob, carol, dave METHOD:REQUEST · SEQUENCE:1 · 16:00 The update: the same UID with SEQUENCE:1 and the new time overwrites the event for everyone.
- bob, carol, dave → alice METHOD:REPLY · PARTSTAT=ACCEPTED All three confirm the new time.
- alice → bob, carol, dave METHOD:CANCEL · STATUS:CANCELLED The cancellation: STATUS:CANCELLED with a bumped SEQUENCE removes the event from every calendar.
Send an invitation and the raw text/calendar part of the latest message will show up here.
Content-Type: text/calendar; method=REQUEST;
charset=UTF-8
BEGIN:VCALENDAR
VERSION:2.0
METHOD:REQUEST
BEGIN:VEVENT
UID:[email protected]
SEQUENCE:0
DTSTART:20260811T130000Z
DTEND:20260811T134500Z
SUMMARY:Kickoff
ORGANIZER;CN=Alice:mailto:[email protected]
ATTENDEE;CN=Bob;ROLE=REQ-PARTICIPANT;
PARTSTAT=NEEDS-ACTION;RSVP=TRUE
:mailto:[email protected]
ATTENDEE;CN=Carol;ROLE=REQ-PARTICIPANT;
PARTSTAT=NEEDS-ACTION;RSVP=TRUE
:mailto:[email protected]
ATTENDEE;CN=Dave;ROLE=REQ-PARTICIPANT;
PARTSTAT=NEEDS-ACTION;RSVP=TRUE
:mailto:[email protected]
END:VEVENT
END:VCALENDARContent-Type: text/calendar; method=REPLY;
charset=UTF-8
BEGIN:VCALENDAR
VERSION:2.0
METHOD:REPLY
BEGIN:VEVENT
UID:[email protected]
SEQUENCE:0
ORGANIZER;CN=Alice:mailto:[email protected]
ATTENDEE;PARTSTAT=ACCEPTED:mailto:[email protected]
REQUEST-STATUS:2.0;Success
END:VEVENT
END:VCALENDARContent-Type: text/calendar; method=COUNTER;
charset=UTF-8
BEGIN:VCALENDAR
VERSION:2.0
METHOD:COUNTER
BEGIN:VEVENT
UID:[email protected]
SEQUENCE:0
DTSTART:20260811T140000Z
DTEND:20260811T144500Z
SUMMARY:Kickoff
COMMENT:16:00 works better for me
ORGANIZER;CN=Alice:mailto:[email protected]
ATTENDEE:mailto:[email protected]
END:VEVENT
END:VCALENDARContent-Type: text/calendar; method=REQUEST;
charset=UTF-8
BEGIN:VCALENDAR
VERSION:2.0
METHOD:REQUEST
BEGIN:VEVENT
UID:[email protected]
SEQUENCE:1
DTSTART:20260811T140000Z
DTEND:20260811T144500Z
SUMMARY:Kickoff
ORGANIZER;CN=Alice:mailto:[email protected]
ATTENDEE;CN=Bob;ROLE=REQ-PARTICIPANT;
PARTSTAT=NEEDS-ACTION;RSVP=TRUE
:mailto:[email protected]
ATTENDEE;CN=Carol;ROLE=REQ-PARTICIPANT;
PARTSTAT=NEEDS-ACTION;RSVP=TRUE
:mailto:[email protected]
ATTENDEE;CN=Dave;ROLE=REQ-PARTICIPANT;
PARTSTAT=NEEDS-ACTION;RSVP=TRUE
:mailto:[email protected]
END:VEVENT
END:VCALENDARContent-Type: text/calendar; method=CANCEL;
charset=UTF-8
BEGIN:VCALENDAR
VERSION:2.0
METHOD:CANCEL
BEGIN:VEVENT
UID:[email protected]
SEQUENCE:1
STATUS:CANCELLED
ORGANIZER;CN=Alice:mailto:[email protected]
ATTENDEE:mailto:[email protected]
ATTENDEE:mailto:[email protected]
ATTENDEE:mailto:[email protected]
END:VEVENT
END:VCALENDARBecause iMIP is just email, in principle anyone can drop events into anyone's calendar, which is exactly what calendar spam exploits. RFC 6047 therefore recommends signed messages (S/MIME), and modern clients only add events from unknown senders after asking first.
The whole journey, at a glance
From composer to inbox in seconds, most of the time
- Compose
- MTA
- DNS / MX
- SPF/DKIM/DMARC
- Bounce?
- Mailbox
- Client renders
The transport protocol: EHLO, MAIL FROM, RCPT TO, DATA and the response codes.
Headers, body and encoding rules: the shape of an email.
How cryptographic signatures are added and verified across mail hops.
Calendar invitations over email: REQUEST, REPLY, COUNTER and CANCEL as text/calendar.
Email is older than the web, and somehow still the most reliable communication protocol on the internet.
Built by Renick Digital Solutions. We develop software, and we know our way around email infrastructure. See what we build