How Email Works

Every day, over 300 billion emails are sent worldwide. Yet most people — including many developers — have no idea what actually happens between clicking "send" and a message appearing in someone's inbox. Email is one of the oldest and most resilient protocols on the internet, first standardized in the early 1980s and still going strong.

This guide walks through the full technical picture: how messages travel across the internet, how servers authenticate senders, why some emails land in spam, and what makes sending a marketing campaign fundamentally different from sending a message to a friend.

The Journey of an Email

An email passes through several systems on its way from sender to recipient. Each system has a specific role, and understanding these roles is key to understanding email as a whole.

Here's the terminology you'll encounter:

Composing and Submitting

When you hit "send" in your email client (the MUA), the message is submitted to a Mail Submission Agent over SMTP on port 587. The MSA requires authentication — you must prove you're allowed to send from that address. This is why you enter your email password or use an app-specific token.

The MSA validates the message, adds some headers (like Date and Message-ID if missing), and passes it to the outbound Mail Transfer Agent.

Routing

The sender's MTA needs to figure out where to deliver the message. It does this by querying DNS for the recipient domain's MX records (Mail eXchange). MX records point to the hostnames of the servers that accept mail for that domain.

$ dig +short MX gmail.com
5  gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.

The numbers are priorities — lower is preferred. The MTA tries each server in order until one accepts the message.

Delivery

The receiving MTA accepts (or rejects) the message based on authentication checks (SPF, DKIM, DMARC — covered below), spam filtering, and server-level policies. If accepted, the message is handed to the Mail Delivery Agent, which sorts it into the correct mailbox, applies user-defined filters, and stores it.

Retrieval

The recipient's email client retrieves messages using IMAP (Internet Message Access Protocol) or POP3 (Post Office Protocol). IMAP keeps messages on the server and syncs state across devices. POP3 downloads messages and typically removes them from the server. Webmail clients like Gmail skip this step entirely — they read directly from the server's storage.

The SMTP Protocol

SMTP (Simple Mail Transfer Protocol) is the standard protocol for sending email. It's a push protocol — it only handles sending, not receiving. It was designed in 1982 (RFC 821) and has been extended many times since, but the core conversation still looks remarkably similar.

Here's what a raw SMTP session looks like:

Port Numbers

Port 25 is used between mail servers and is typically blocked by ISPs for consumer connections to prevent spam. Port 587 is what your email client uses — it requires authentication and encryption via STARTTLS.

Email Anatomy — Envelope vs Headers vs Body

One of the most confusing aspects of email is that there are two sets of sender/recipient information, and they can differ.

Think of it like physical mail: the envelope has a return address and destination address that the postal service uses for routing. Inside the envelope, the letter has its own "From" and "To" at the top — these are what the recipient sees, but the postal service ignores them.

The Envelope

The SMTP envelope consists of two commands:

• MAIL FROM: — the return address (also called the Return-Path or bounce address). If the message can't be delivered, the bounce notification goes here.
• RCPT TO: — the actual destination address(es). This is where the message is physically delivered.

The Headers

Inside the DATA portion of the SMTP conversation, the message has headers that the recipient sees:

Why Envelope and Headers Can Differ

There are legitimate reasons for mismatches:

• BCC: the BCC recipient appears in RCPT TO but not in the To or Cc headers
• Mailing lists: the list server receives the message and re-sends it to all subscribers. The From stays as the original author, but the envelope sender changes to the list's bounce address
• Forwarding: the From header stays the same, but the envelope sender changes to the forwarder
• Marketing email: the MAIL FROM is often a bounce-processing address (like bounces+id@esp.example.com), while From shows the brand's address

MIME and Multipart Messages

Modern emails rarely contain just plain text. MIME (Multipurpose Internet Mail Extensions) allows emails to carry multiple content types in a single message:

• multipart/alternative — the same content in different formats (plain text + HTML). The email client picks which to display.
• multipart/mixed — the message body plus attachments
• multipart/related — HTML body with inline images (referenced via Content-ID)

Content-Type: multipart/alternative; boundary="boundary123"

--boundary123
Content-Type: text/plain; charset="utf-8"

Hello, this is the plain text version.

--boundary123
Content-Type: text/html; charset="utf-8"

<html><body><h1>Hello</h1><p>This is the HTML version.</p></body></html>

--boundary123--

Email Authentication

In the early days of email, there was no way to verify that a message actually came from the domain it claimed to come from. Anyone could send an email pretending to be anyone else. Three complementary protocols were developed to solve this: SPF, DKIM, and DMARC.

SPF — Sender Policy Framework

SPF lets a domain declare which servers are allowed to send email on its behalf. The domain publishes a DNS TXT record listing authorized IP addresses and services.

When a receiving server gets a message, it checks the Return-Path domain (envelope sender), looks up that domain's SPF record, and verifies the connecting server's IP is in the authorized list.

example.com.  IN TXT  "v=spf1 include:amazonses.com include:_spf.google.com -all"

This record says: "Only Amazon SES and Google Workspace are allowed to send email for example.com. Reject everything else (-all)."

Limitation: SPF checks the envelope sender, not the From header. A phishing email can pass SPF if the phisher uses their own domain in the Return-Path while spoofing the From header.

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to outgoing emails. The sending server signs specific headers and the message body using a private key. The signature is included as a DKIM-Signature header.

The receiving server extracts the signing domain (d=) and selector (s=) from the signature, looks up the corresponding public key via DNS, and verifies the signature. If the message was altered in transit, the signature check fails.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9Nhtj...;
  b=dzdVyOfAKCdL...

The public key is published as a DNS TXT record:

s1._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

Limitation: DKIM proves the message wasn't tampered with and was signed by a specific domain, but it doesn't prove that d=example.com matches the From header. A phisher could sign with their own domain while spoofing From.

DMARC — Domain-based Message Authentication, Reporting & Conformance

DMARC ties SPF and DKIM together by adding alignment — requiring that the domain in the From header matches the domain verified by SPF or DKIM (or both).

_dmarc.example.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

DMARC introduces three policy levels:

• p=none — monitor only; don't take action on failures (useful when setting up)
• p=quarantine — send failures to the spam folder
• p=reject — outright reject messages that fail alignment

DMARC also introduces aggregate reports (rua): receiving servers send daily XML reports telling the domain owner how many emails passed or failed authentication. This is invaluable for monitoring and debugging.

How They Work Together

A fully authenticated email setup looks like this:

1. SPF confirms the sending server's IP is authorized for the Return-Path domain
2. DKIM confirms the message body and headers haven't been tampered with, signed by the d= domain
3. DMARC confirms that the From header domain aligns with either the SPF domain or the DKIM d= domain
4. The receiving server applies the DMARC policy if alignment fails

All three passing gives receiving servers strong confidence that the email is legitimate.

Sender Reputation

Authentication proves who you are. Reputation determines whether you're trusted. Even a perfectly authenticated email — SPF pass, DKIM verified, DMARC aligned — can land in spam if the sender has a poor reputation. Mailbox providers track reputation on two axes: the IP address the message was sent from, and the domain associated with the sender.

IP Reputation

Every IP address that sends email accumulates a reputation score with each mailbox provider it delivers to. This score is based on measurable sending behavior: bounce rates, spam complaint rates, spam trap hits, and volume patterns. In the 2000s and early 2010s, IP reputation was the dominant trust signal — domain-level authentication (DKIM, DMARC) wasn't widely adopted yet, so the IP was the most reliable way to identify a sender.

IP reputation comes in two flavors. Shared IPs are used by email service providers like SendGrid or Mailgun, where thousands of customers send from the same pool of addresses. Your reputation is blended with everyone else's — good for low-volume senders who benefit from the pool's established trust, risky if a neighbor sends spam. Dedicated IPs give you a reputation that's entirely your own, but they start cold — you must warm them gradually over weeks by sending to your most engaged recipients first.

Domain Reputation

Domain reputation is the modern primary signal. Mailbox providers track reputation against several domain identifiers:

• DKIM signing domain (d= value in the DKIM-Signature header) — the strongest signal, because it's cryptographically tied to the sender
• Envelope sender domain (the Return-Path / MAIL FROM domain)
• From header domain — the domain recipients see in their inbox

Google retired its domain and IP reputation dashboards from Postmaster Tools in late 2025, shifting to compliance-focused metrics (spam rate, authentication errors, delivery issues) — a signal that Gmail's filtering has moved beyond simple reputation scores toward holistic engagement and compliance signals. Microsoft's SNDS still surfaces IP-level data, but since May 2025 Microsoft also enforces domain-level authentication (SPF, DKIM, DMARC alignment) for bulk senders, with message rejection for non-compliant domains rolling out in 2026. The critical advantage of domain reputation: it persists when you change infrastructure. Switch ESPs, rotate IPs, migrate providers — your domain reputation travels with you.

The Shift from IP to Domain

The shift happened for practical reasons. Cloud-based ESPs made shared IPs the norm — when thousands of senders share the same IP addresses, IP reputation becomes a blunt instrument. Google's 2024 bulk sender requirements made this shift explicit by tying enforcement to domain-level authentication (DKIM alignment and DMARC policies). Yahoo followed with identical requirements, and Microsoft joined in May 2025 with the same SPF/DKIM/DMARC requirements for senders exceeding 5,000 messages per day.

Domain reputation is also harder to game. In the IP-centric era, spammers would burn through IP addresses — send spam until the IP was blocklisted, then move to a fresh one. Domains are more expensive, more visible, and tied to DNS records that take time to establish.

How Providers Weigh Reputation Today

No two mailbox providers weight reputation identically, but the trend is clear — domain reputation is increasingly dominant:

Most smaller ISPs and corporate mail servers still rely heavily on IP reputation and third-party blocklists (Spamhaus, Barracuda). A comprehensive deliverability strategy addresses both signals, but for the major providers, domain reputation and authentication compliance now outweigh IP reputation.

Marketing Email vs Private Email

Sending a marketing campaign to 50,000 subscribers is a fundamentally different operation from sending a message to a colleague. The SMTP protocol is the same, but almost everything around it changes.

Infrastructure

When you send a personal email through Gmail, your message goes through Google's shared mail infrastructure — the same servers used by millions of other Gmail users. Google's IP addresses are already trusted by every ISP on the planet.

Marketing email requires dedicated infrastructure: Email Service Providers (ESPs) like Amazon SES, SendGrid, or Mailgun — or a custom Mail Transfer Agent. These systems handle the complexity of sending at scale: connection pooling, retry logic, bounce processing, and compliance.

IP Warming

As covered in Sender Reputation above, a brand-new IP address has no reputation. IP warming is the process of gradually increasing send volume over weeks, building trust with each ISP. Sending to your most engaged recipients first builds positive signals that let you scale up faster.

Compliance

Marketing email is governed by laws like CAN-SPAM (US), GDPR (EU), and CASL (Canada). Requirements include:

• A visible, working unsubscribe mechanism in every email
• The List-Unsubscribe header for one-click unsubscribe (required by Gmail and Yahoo since 2024)
• Honoring unsubscribe requests within 10 days (CAN-SPAM) or immediately (best practice)
• Not sending to contacts who haven't given consent (GDPR)
• Including a physical mailing address (CAN-SPAM)

Private emails between individuals don't have any of these requirements.

Bounce Processing and Feedback Loops

When a marketing email bounces (the recipient address doesn't exist or the mailbox is full), the ESP must process that bounce and suppress the address from future sends. Continued sending to invalid addresses damages your IP reputation.

Feedback Loops (FBLs) are agreements with ISPs where the ISP notifies you when a recipient marks your email as spam. Processing FBL complaints and removing those recipients is critical for maintaining deliverability.

Private email clients handle bounces by simply showing you an error — there's no automated suppression system needed when you're emailing one person at a time.

Why Emails End Up in Spam

Spam filters have evolved from simple keyword matching to sophisticated systems that consider dozens of signals. Here's what matters most:

Reputation

As detailed in Sender Reputation above, every sending IP and domain carries a reputation score. A poor reputation means your emails go to spam — even if the content is perfectly legitimate.

Engagement Signals

Modern spam filters (especially Gmail's) heavily weight recipient behavior:

• Do recipients open your emails?
• Do they click links?
• Do they reply?
• Do they move your emails out of spam?
• Do they mark your emails as spam?

Low engagement tells ISPs that recipients don't want your email — and they'll start routing it to spam proactively.

Content and Technical Signals

• Authentication failures — missing or failing SPF, DKIM, or DMARC is a major red flag
• HTML quality — broken HTML, excessive images with no text, or hidden text can trigger filters
• URL reputation — links to known-bad domains or URL shorteners can cause issues
• Sending patterns — sudden volume spikes from a domain that normally sends little email

List Hygiene

Sending to old, invalid, or purchased lists is one of the fastest ways to destroy deliverability. Spam traps — email addresses specifically set up to catch senders with poor list practices — are seeded across the internet. Hitting a spam trap is a strong negative signal to ISPs.

Blocklists

Organizations like Spamhaus, Barracuda, and SpamCop maintain blocklists of IP addresses and domains known to send spam. Many ISPs check these blocklists in real time. Getting listed — and getting delisted — can take days to weeks.

How Owlat Fits In

Owlat implements all of the concepts described above as a complete email platform:

• Custom MTA — Owlat's Mail Transfer Agent handles direct SMTP delivery with DKIM signing, adaptive per-ISP throttling, IP warming, bounce processing, and feedback loop integration
• Authentication — When you verify a domain in Owlat, it generates the SPF, DKIM, and DMARC DNS records for you and monitors their status
• Intelligence pipeline — Every outgoing email passes through 10+ pre-send checks including circuit breakers, suppression lists, domain throttling, and engagement-based priority ordering
• Email rendering — The email renderer converts visual editor blocks into cross-client compatible HTML with CSS inlining, Outlook VML fallbacks, and dark mode support
• Provider abstraction — The email system supports multiple providers (custom MTA, Amazon SES, Resend) behind a unified interface with automatic retry and rate limiting

For product-specific setup guides, see Getting Started and Deliverability.