How does email actually work? The protocols behind every message

You hit Send. Half a second later your friend's phone buzzes. In between, half a dozen specialized servers, three or four protocols, and a small chain of cryptographic checks have all done their jobs without you knowing about any of them.

Email is older than the web (1971 for the first protocol, 1982 for SMTP, the version we still use), and the architecture has accreted layers without ever fundamentally changing. Most people use email for decades without understanding it. That's fine — but if you've ever wondered why your mail goes to spam, what an MX record is, or why "DMARC" keeps coming up, this is the explainer.

The four protocol pieces

Email is multiple protocols stitched together. The four you should know:

SMTP — Simple Mail Transfer Protocol. How servers send mail to each other (and how your client submits new mail to your provider).
IMAP — Internet Message Access Protocol. How your client reads mail from your server. Modern default.
POP3 — Post Office Protocol. Older alternative to IMAP. Mostly retired.
MX records (DNS) — How servers find each other. "If you want to send mail to example.com, here are the servers that accept it."

Plus a layer of authentication on top: SPF, DKIM, DMARC. We'll get to those.

The journey of a single email

You send a message from alice@example.org to bob@recipient.com. Here's what happens.

Step 1 — Your client to your provider (SMTP submission)

Your mail app (Gmail in the browser, Apple Mail, Outlook, whatever) opens an SMTP connection to your provider's outbound mail server (smtp.example.org, port 587 for submission, or 465 for legacy SMTPS). It authenticates with your username and password — or more commonly today, an OAuth token.

You hand over the message. Your provider's submission server accepts it, checks you're authorized to send from alice@example.org, and queues it for outbound delivery.

Step 2 — Your provider's outbound to recipient's inbound (DNS + SMTP)

Your provider needs to find the right server to send mail to bob@recipient.com. It does a DNS lookup for recipient.com's MX records:

$ dig MX recipient.com
recipient.com.    3600    IN    MX    10 mx1.recipient.com.
recipient.com.    3600    IN    MX    20 mx2.recipient.com.

The number is priority — lower is preferred. Your provider tries mx1.recipient.com first; falls back to mx2.recipient.com if mx1 is unreachable.

Your provider opens an SMTP connection to mx1.recipient.com on port 25. They greet each other, your provider hands over the message envelope (sender, recipient) and then the message body. The recipient server accepts (or rejects with a numeric code).

Step 3 — Authentication checks

This is where modern email gets interesting. Before accepting the message, the recipient server checks:

SPF (Sender Policy Framework). Looks up example.org's SPF record in DNS. The record lists which IPs are allowed to send mail for that domain. If your provider's outbound IP isn't on the list, fail or mark as suspicious.
DKIM (DomainKeys Identified Mail). Your provider signed the message with a private key. The recipient looks up the matching public key in DNS (selector._domainkey.example.org). If the signature verifies, the message hasn't been tampered with and provably came from someone holding the private key.
DMARC (Domain-based Message Authentication, Reporting & Conformance). Your domain's DMARC policy says how strict to be. "If SPF or DKIM fails, reject" or "quarantine" or "pass through but report." Sets the rules for the previous two checks.

If everything passes: high reputation, lands in inbox. If anything fails: spam folder or rejection, depending on the recipient's policy.

Step 4 — Reverse DNS sanity check

The recipient server also checks the reverse DNS of your sending IP. If 203.0.113.5 reverse-resolves to a hostname that matches your sending domain, that's a positive signal. If it's missing or generic ("c-203-0-113-5.example-isp.net"), suspicion rises.

This is one of the hardest parts of running your own mail server — getting reverse DNS right.

Step 5 — The message lands

Recipient server stores the message in bob@recipient.com's mailbox, alongside everything else.

Step 6 — Bob's client retrieves it (IMAP)

Bob's mail app polls his provider's IMAP server (port 993 with TLS) for new messages. IMAP fetches mailbox listings, message headers, and (on demand) full bodies.

Modern email clients also use IMAP IDLE — a long-lived connection where the server pushes notifications when new mail arrives, so Bob's client buzzes within seconds of delivery.

Step 7 — Read receipts and sync

Bob reads it. His IMAP client tells the server, which marks the message as read on the server, which propagates to all his devices.

Why email goes to spam

Each of the above is a chance to get marked as spam. Common reasons:

No SPF, or SPF doesn't list the sending IP.
No DKIM, or DKIM signature fails to validate.
No DMARC, or DMARC says reject and SPF/DKIM failed.
Reverse DNS is missing or generic.
Sending IP has bad reputation (on a blacklist, or recently used for spam).
Content is suspicious — too many links, too many spam keywords, too much HTML, too little text.
First-time sender to this recipient — gets extra scrutiny.

If you're running your own server: SPF + DKIM + DMARC + clean rDNS + a clean IP gets you into inbox almost everywhere. Skip any of these and expect spam-folder relegation.

What MX records look like

$ dig MX gmail.com
gmail.com.    3600    IN    MX    5 gmail-smtp-in.l.google.com.
gmail.com.    3600    IN    MX    10 alt1.gmail-smtp-in.l.google.com.
gmail.com.    3600    IN    MX    20 alt2.gmail-smtp-in.l.google.com.
gmail.com.    3600    IN    MX    30 alt3.gmail-smtp-in.l.google.com.
gmail.com.    3600    IN    MX    40 alt4.gmail-smtp-in.l.google.com.

Five servers, prioritized. Try the first; fall back as needed.

You can check the MX records of any domain using our hostname lookup tool.

Why running your own email is hard

The protocols are simple. The reputation game is hard.

To run a working personal mail server in 2026 you need:

A static IP (no major receiver accepts mail from dynamic ranges).
Reverse DNS that matches your sending domain.
SPF, DKIM, DMARC configured correctly.
A clean IP not on any blacklist.
Slow ramp-up of sending volume — receivers throttle new senders.
Vigilant attention to bounces and spam complaints.

Even with all of that, big providers (Gmail, Outlook, iCloud) periodically downrank smaller senders for opaque reasons. Many people who tried self-hosting in 2020 gave up by 2023.

The pragmatic alternative: relay outbound through a service like Postmark, Mailgun, Amazon SES, Resend, or SendGrid. They handle reputation. You handle content.

How email encryption works (or doesn't)

Two layers exist:

Transport encryption (STARTTLS)

When two SMTP servers connect, they upgrade to TLS via STARTTLS. The connection is encrypted between them. But:

Either side can refuse TLS (fall back to plaintext).
The recipient server can read the message after delivery.
Your provider can read messages before sending.

Almost all major providers use TLS today, but the system is opportunistic — not strict. MTA-STS is a newer standard that lets domains declare "always require TLS to me," which closes that loophole when supported.

End-to-end encryption (PGP, S/MIME)

The message body is encrypted by the sender's client and only the recipient's client can decrypt. Servers in between see only ciphertext. Strong, but adoption has been near-zero outside niche communities. Email's original design didn't anticipate end-to-end encryption.

For sensitive content: don't use email. Use a real end-to-end encrypted messenger.

Quick FAQ

Why is email so old? The internet's original killer app, designed when "internet" meant a few thousand academic computers. The protocols are robust enough that nobody's wanted to redo them; the patches accumulated instead.

Why don't we just replace SMTP? We've tried. Internet Mail 2000 was an early attempt. Nothing's gotten universal adoption. Email's value is in being universally interoperable; replacing it requires every provider to switch, which won't happen for one new protocol.

Why are some emails delayed? Greylisting (recipient initially rejects, sender retries, recipient accepts on retry) is one cause. Spam filtering and queue depth are others. Modern email is usually instant; small delays still happen.

Can email be read in transit? Mostly no, with caveats. STARTTLS is usually negotiated and active. Some carriers and servers don't enforce it strictly, so theoretical interception exists. End-to-end encryption (PGP) is the only reliable defense.

How do I check if my domain is configured for email properly? Tools like mxtoolbox.com and mail-tester.com test SPF, DKIM, DMARC, and reputation for free.

TL;DR

Email goes through:

Your client → your provider (SMTP submission, port 587/465).
Your provider looks up the recipient's MX records via DNS.
Your provider connects to the recipient's MX server (SMTP, port 25).
Recipient checks SPF, DKIM, DMARC, reverse DNS.
Message lands in recipient's mailbox.
Recipient's client fetches via IMAP (port 993).

Forty-plus years later, this is still how it works. The protocols are simple. The reputation game on top of them is the hard part.