SMTP, IMAP, and POP3 Explained: How Email Actually Travels Across the Internet

You click send and an email arrives on the other side of the world within seconds. The experience feels instant and seamless, like a direct channel between two people. But underneath that simplicity is a chain of servers, lookups, and protocol handshakes that has been evolving since the early 1980s. Understanding how email actually travels — what SMTP, IMAP, and POP3 do, where DNS fits in, and how authentication layers work — is not just interesting trivia. It explains why emails sometimes bounce, why spam filters exist, why some services can receive but not send, and how a temporary email service like TempMailKit plugs into the same infrastructure as a corporate mail server. This guide explains every piece in plain English.

The Three Core Protocols and What They Do

Email uses three separate protocols because sending and receiving are fundamentally different operations. SMTP (Simple Mail Transfer Protocol) is the transport layer — it moves messages from one server to another and from your mail client to your provider's outgoing server. IMAP (Internet Message Access Protocol) and POP3 (Post Office Protocol 3) are retrieval protocols — they let your mail client download and read messages from a mailbox stored on a server. The split exists because sending a message (pushing it to its destination) requires a different kind of connection than reading a mailbox (pulling from a stored copy), and the two operations have different security and synchronisation needs.

Think of SMTP as the postal carrier that moves the envelope, and IMAP or POP3 as the post-office-box system you use to pick up your mail. The carrier and the mailbox are separate systems that work together. When you use a web-based client like Gmail in a browser, all three protocols are running in the background on Google's servers, hidden from you completely. When you use a desktop app like Apple Mail or Outlook pointed at any mail provider, the app uses IMAP or POP3 to read your inbox and SMTP to send outgoing messages.

How SMTP Works Step by Step

When you click send, your mail client connects to your mail provider's SMTP server (typically on port 587 with STARTTLS encryption, or port 465 with implicit TLS) and authenticates with your username and password. It then hands the message to the server in a simple protocol conversation: the client announces who the message is from (MAIL FROM), who it is to (RCPT TO), and then sends the message content. The server accepts the message and takes responsibility for delivering it.

The outgoing server now needs to find where to deliver the message. It performs a DNS lookup for the recipient domain — not an A record (which maps a domain to an IP address for websites) but an MX record, which stands for Mail Exchanger. MX records tell the internet which servers accept incoming mail for a domain. Gmail publishes MX records pointing to Google's mail servers; your company publishes MX records pointing to its mail servers; TempMailKit publishes MX records pointing to the Cloudflare Email Routing infrastructure that routes messages into its system. This DNS lookup is the moment the sending server figures out where to hand the message next.

Once it has the destination IP from the MX record, the outgoing server opens a new SMTP connection to the recipient's mail server and delivers the message in the same handshake format: MAIL FROM, RCPT TO, message content. The recipient's server accepts it, runs spam and authentication checks (SPF, DKIM, DMARC — the trio we cover in reading email headers), and places the message in the recipient's mailbox if everything passes. The whole process takes seconds and involves at least two SMTP connections, sometimes more if the email passes through intermediate relay servers.

Port Numbers and Encryption

Port numbers matter because email has multiple transport paths with different security properties. Port 25 is the original SMTP port used for server-to-server relay, and it still handles most of the internet's email traffic between providers. Consumer mail providers block outbound port 25 from residential connections to prevent spam bots from turning home computers into mail relays. Port 587 (submission port) is what mail clients use to submit outgoing messages to their provider's server, with mandatory authentication. Port 465 is an older SSL-wrapped SMTP port that many services still support. For IMAP, port 993 is the encrypted version (IMAPS) and the standard for modern clients. For POP3, port 995 is the encrypted version. The bottom line for users: your mail client should be configured to use port 587 (or 465) for sending and port 993 for IMAP, with TLS or SSL enabled — any other configuration is either a legacy setup or a misconfiguration.

IMAP vs POP3: Which to Use and Why

Both IMAP and POP3 let a mail client retrieve messages from a server, but they handle the mailbox very differently. POP3, the older protocol, was designed for an era when people accessed email from a single computer. It downloads messages to the local machine and, by default, deletes them from the server. This made sense when server storage was expensive and you always read email from the same desk. Today it is mostly a problem: if you download your inbox to a desktop app with POP3, your phone and your browser will not see those messages because they have been removed from the server.

IMAP keeps messages on the server and synchronises them. Every device sees the same inbox, sent folder, and read/unread state, because they all connect to the same authoritative mailbox on the server rather than each maintaining a local copy. This is why every modern mail setup uses IMAP (or its equivalent in cloud providers) rather than POP3. If you use Gmail on your phone, your laptop, and your browser simultaneously, that works because IMAP keeps a single source of truth on Google's servers and propagates state changes to every connected client in near real-time.

POP3 still has a niche: if you need to archive messages locally and cannot rely on server storage (or need to guarantee that messages are removed from the server for compliance reasons), POP3 with "delete from server after download" achieves that cleanly. For virtually every other use case, IMAP is the right choice.

How DNS MX Records Route the World's Email

The MX record system is what makes email routing work at internet scale without any central directory. Every domain that wants to receive email publishes one or more MX records in DNS. Each record has a priority number (lower number = higher priority) and a hostname pointing to a mail server. When a sending server looks up MX records for gmail.com, it gets back a list of Google's mail servers with their priorities, and it tries the highest-priority one first, falling back to lower-priority servers if the first is unreachable. This redundancy means that even if one mail server is down, email delivery continues through backup servers. When your company uses Microsoft 365 for email, its MX record points to Microsoft's servers; when it uses Google Workspace, the MX points to Google. Changing email providers means changing MX records — which is a simple DNS change but often takes up to 48 hours to propagate globally, during which messages may flow to either the old or new provider.

TempMailKit works the same way: the tempmailkit.com domain publishes MX records pointing to Cloudflare's Email Routing infrastructure. Cloudflare accepts all incoming messages for the domain via a catch-all rule and forwards them to TempMailKit's backend, where they are stored in a Redis database and surfaced through the web interface. This is the same architecture described in catch-all email and unlimited disposable aliases.

Why Emails Bounce, Get Blocked, or Land in Spam

With the delivery chain in mind, the common failure modes become easy to understand. A hard bounce (550 error) means the recipient address does not exist: the destination server looked up the mailbox and found nothing, and the sending server notifies the original sender that delivery is permanently impossible. A soft bounce (4xx error) is temporary: the destination server is busy, over quota, or has a transient problem, and the sending server will retry delivery for a configured period (typically hours to days) before giving up and sending a permanent failure notification.

Spam filtering happens after a message is technically delivered to the server but before it reaches the inbox. The receiving server runs the message through filters that check IP reputation (is this sending IP on a known spam blacklist?), authentication results (did SPF, DKIM, and DMARC pass?), content patterns (does the message match known spam signatures?), and engagement signals (do other users of this provider mark messages from this sender as spam?). A message that fails enough of these checks goes to the spam folder or is rejected outright. Understanding this is the foundation of email deliverability: senders who want their messages to reach inboxes need to authenticate their domain properly, maintain a clean sending IP, and generate content that recipients engage with rather than flag. We cover this topic in detail in email deliverability explained.

How Temp Mail Fits Into the Same Infrastructure

A temporary email service is not a separate system running outside the internet's email infrastructure — it is fully part of it. The temp mail domain publishes real MX records, runs a real SMTP receiving server, and accepts messages according to the same protocol that all mail servers use. The difference is what happens after delivery: instead of routing messages into a personal account tied to a registered user, the service routes them into a shared inbox pool keyed by address prefix, visible through a web interface to whoever happens to have loaded the page for that address, and discarded after a configured lifetime.

This means any message that a sending server can deliver to a real inbox can also be delivered to a temp mail address — confirmation links, OTP codes, newsletter sign-up confirmations, whatever the sender is transmitting arrives at the same speed and reliability as it would at a Gmail address. The only delivery difference is that some sending services check whether the receiving domain appears on a disposable-email blocklist and refuse to accept the address at registration, a topic covered fully in why websites block disposable email. The infrastructure itself makes no such distinction — SMTP does not know or care whether a mailbox is permanent or ephemeral.

The Short Version

SMTP is the protocol that moves email between servers, using DNS MX records to find the right destination; IMAP and POP3 are the protocols your mail client uses to retrieve messages from the server, with IMAP keeping everything synchronised across devices while POP3 downloads and removes. Sending an email involves your client handing the message to your provider's SMTP server, which looks up the recipient domain's MX record in DNS, opens a new SMTP connection to the destination server, and delivers the message; the destination server then runs authentication checks before placing it in the mailbox. Bounces, spam filtering, and delivery failures all happen at specific points in this chain and have distinct error codes that indicate exactly what went wrong. Temporary email services sit entirely within this same infrastructure, accepting messages over standard SMTP, and the only meaningful difference from a permanent inbox is what happens to messages after they arrive.

Frequently Asked Questions

What does SMTP stand for and what does it do?

SMTP stands for Simple Mail Transfer Protocol. It is the protocol used to send email between servers and from your mail client to your provider's outgoing server. When you click send, your client uses SMTP to hand the message to your provider, which then uses SMTP again to deliver it to the recipient's mail server. SMTP handles only the sending side; reading mail uses a separate protocol (IMAP or POP3).

What is the difference between IMAP and POP3?

IMAP keeps your messages on the server and synchronises them across all your devices so that your phone, laptop, and browser all see the same inbox. POP3 downloads messages to a single device and typically removes them from the server, which means only that device has them. For almost all modern use cases, IMAP is the right choice because it supports multi-device access and keeps the server as the authoritative source of truth for your mail.

What is an MX record?

An MX (Mail Exchanger) record is a type of DNS record that tells other mail servers which servers accept incoming email for a domain. When a sending server wants to deliver mail to you@example.com, it looks up the MX records for example.com in DNS and connects to the server listed there. Domains that want to receive email must publish at least one MX record pointing to their mail server. Without one, email delivery to that domain is impossible.

Why do emails sometimes land in spam even from legitimate senders?

Spam filters weigh multiple signals: whether SPF, DKIM, and DMARC authentication passed, whether the sending IP's reputation is clean, whether the message content matches patterns associated with spam, and whether other users of the same mail provider have reported similar messages as spam. A legitimate sender can fail these checks due to DNS misconfiguration, a shared sending IP with a bad reputation, or content patterns that happen to resemble spam. The fix is usually to properly configure email authentication and to review whether the sending IP is on any blocklists.

What ports does email use?

Server-to-server SMTP relay uses port 25. Mail clients use port 587 (with STARTTLS) or port 465 (with SSL) to submit outgoing messages to their provider's server. IMAP clients connect on port 993 (encrypted). POP3 clients connect on port 995 (encrypted). If you are setting up a mail client, use 587 or 465 for outgoing and 993 for incoming IMAP, with encryption enabled; plain-text versions of these ports (25 for SMTP from a client, 143 for IMAP, 110 for POP3) should be avoided on modern systems.