How an Email Actually Travels From Sender to Inbox

An email travels from sender to inbox in a series of hops: your mail client hands the message to an outgoing SMTP server, which looks up the recipient domain's MX records, connects to the receiving server, and passes the message through spam and virus filters before it lands in a mailbox that IMAP or a web interface can read. Most of this happens in seconds, which is why a disposable inbox can show a verification code almost instantly after you request it.

The cast of characters: clients, servers and protocols

Before tracing the path, it helps to know who does what. An email journey involves four main players:

• Mail user agent (MUA) — the app or web page you use to read and write email. Examples include Outlook, Apple Mail, Thunderbird, Gmail's web interface, or a temporary inbox page.
• Mail submission agent (MSA) — the server your client authenticates to when you press Send. It usually runs on port 587 and accepts mail only from authenticated users.
• Mail transfer agent (MTA) — the server that relays mail between domains. MTAs speak SMTP to each other and decide where to send a message based on DNS records.
• Mail delivery agent (MDA) — the final server-side program that writes the message into the recipient's mailbox, often applying filters or sorting rules as it does so.

Two protocols tie these together: SMTP (Simple Mail Transfer Protocol) for sending and relaying, and IMAP or POP3 for retrieving. Webmail hides both behind a browser, but the same machinery runs underneath.

How does an email actually get from sender to inbox?

Here is the sequence in the order it happens. Each step is a place where delays or failures can creep in.

1. Composition and submission. You write a message and press Send. Your client connects to the MSA over SMTP, usually with TLS encryption, and authenticates. The MSA checks that you are allowed to send from that address and may apply rate limits or content policies.
2. DNS lookup for the recipient domain. The MSA extracts the domain from the recipient address (the part after the @) and queries DNS for its MX records (Mail Exchanger records). These records list the hostnames of servers willing to accept mail for that domain, in priority order. If no MX records exist, the sender may fall back to the domain's A or AAAA record, but that is a legacy behaviour and many servers now refuse it.
3. Connection to the receiving MTA. The sending server opens an SMTP connection to the highest-priority MX host. It introduces itself with EHLO, negotiates TLS, and announces the sender and recipient addresses. The receiving server can reject the message at this stage — for example, if the recipient does not exist or the sender's IP is on a blocklist.
4. Relaying between MTAs. Large providers often have several internal relays. A message from a small sender to a big mailbox provider might pass through two or three MTAs before reaching the final destination. Each one adds a Received: header, which is why email headers can be read like a flight log.
5. Filtering and policy checks. The receiving organisation runs spam filters, virus scanners, authentication checks (SPF, DKIM and DMARC) and possibly content rules. A message can be accepted, quarantined, tagged as spam, or rejected outright.
6. Delivery to the mailbox. The MDA writes the message into the recipient's mail store. For a temporary inbox, this store is typically a database row or a short-lived queue with an expiry timestamp attached.
7. Retrieval. The recipient's client fetches the message via IMAP, POP3 or a web API. In a webmail or temp-mail interface, the page polls or uses a push channel to show new mail.

Where do delays, bounces and filtering happen?

Most email arrives quickly, but the path has several natural bottlenecks. Knowing them helps you diagnose a missing verification code instead of guessing.

Delays

• Greylisting. Some receiving servers temporarily reject mail from unfamiliar senders with a 4xx code, expecting the sending server to retry later. This can add minutes.
• Queueing at the sender. If the sending MSA is busy or rate-limited, your message waits in a local queue before the first delivery attempt.
• DNS timeouts. A slow or misconfigured DNS resolver can stall the MX lookup.
• Large attachments or content scanning. Virus scanners and content filters take longer on big or complex messages.
• Recipient-side greylisting or throttling. Some providers deliberately slow down delivery to new senders to reduce spam.

Bounces

A bounce is a delivery failure report. It can be immediate (a synchronous SMTP rejection) or asynchronous (a non-delivery report generated later). Common causes include a non-existent recipient, a full mailbox, a policy rejection, or a sending IP with a poor reputation. The SMTP status code in the bounce — 5xx for permanent failure, 4xx for temporary — tells you whether retrying is worthwhile. If you are debugging a signup flow, our guide to verification email not arriving walks through the checks in order.

Filtering

Filtering can happen at several points: on the sending side (outbound spam checks), on the receiving MTA (connection-level blocklists, SPF/DKIM/DMARC evaluation), and in the mailbox (user rules, spam folder sorting). Authentication results are recorded in the Authentication-Results header, which is one reason reading email headers is useful when a message goes missing.

Why does a temp inbox receive mail in seconds?

A disposable email service is, from the network's point of view, just another mail domain. It publishes MX records, runs an SMTP server, and accepts messages for addresses in its domain. The difference is what happens after acceptance: instead of storing mail in a long-lived personal mailbox, it writes the message to a short-lived store keyed by the random address and makes it visible through a web interface or API.

Because the receiving server is purpose-built for this, there is often no greylisting, no complex user-level filtering, and no IMAP round trip. The message is accepted and displayed almost immediately. That is why one-time codes usually appear within seconds — the delay you see is more likely to be at the sender's end (their queue or their own verification pipeline) than in the temp-mail service itself. If a code does not appear, our article on temp mail not receiving emails covers the usual causes.

MailboxTemp follows this model: an inbox lives for 60 minutes by default, can be extended in 10-minute steps, and Pro inboxes last 24 hours. Addresses are random and receive-only, and one-time codes are detected automatically. The service exposes a public JSON API at /docs/ for developers who want to automate checks.

What does each protocol actually do?

It is easy to blur SMTP, IMAP and POP3 together. Here is a quick reference.

Webmail and temporary inboxes often skip IMAP entirely and use an HTTP API to fetch messages. The underlying SMTP path is the same; only the retrieval step differs.

How can I trace a message myself?

If you need to know where a message went, the headers are the place to look. Every server that handles the message prepends a Received: header. Reading them from bottom to top gives you the path the message took, with timestamps and server names. Our guide to reading email headers explains the fields in detail. For developers testing signup flows, the same technique helps confirm whether a message left your application and where it stopped.

Two related topics are worth knowing. First, authentication records — SPF, DKIM and DMARC — are checked during the SMTP conversation and influence filtering; our plain-English explainer on SPF, DKIM and DMARC covers them. Second, the difference between a temporary address and an alias matters when you are choosing where mail should land; see email aliases vs disposable email.

Sources

• RFC 5321, Simple Mail Transfer Protocol — https://www.rfc-editor.org/rfc/rfc5321.html
• RFC 5322, Internet Message Format — https://www.rfc-editor.org/rfc/rfc5322.html
• RFC 7208, Sender Policy Framework (SPF) — https://www.rfc-editor.org/rfc/rfc7208.html
• RFC 9051, Internet Message Access Protocol (IMAP) version 4rev2 — https://www.rfc-editor.org/rfc/rfc9051.html
• RFC 1035, Domain Names — Implementation and Specification (defines MX records) — https://www.rfc-editor.org/rfc/rfc1035.html
• Microsoft Learn, SMTP protocol overview and mail flow documentation — https://learn.microsoft.com/en-us/exchange/mail-flow

In short

An email's journey is a chain of SMTP handoffs guided by MX records, with filtering and policy checks at each hop. Delays usually come from greylisting, queues or DNS; bounces carry status codes that tell you whether to retry; filtering happens on both sides of the connection. A temporary inbox receives mail quickly because it is a purpose-built receiving server with a short-lived store — the SMTP path is the same, but the retrieval step is simpler. If you want to see the whole thing in action, open a temporary address and watch a verification code arrive.