How email moves

Follow one email across the Internet

Trace a message from a mail app through submission, DNS routing, relays, delivery, and mailbox access.

8 minute lesson

~~~

You press Send. Your mail app submits the message to your provider, normally over an authenticated TLS connection.

The provider looks up the recipient domain’s MX records in DNS. It opens an SMTP connection to a selected mail server, transfers the message, and queues a retry if that server reports a temporary failure.

The receiving system filters and delivers the message to a mailbox. The recipient reads that mailbox with IMAP, POP3, JMAP, a provider API, or the provider’s web interface.

If the DNS step is unfamiliar, complete the DNS Course first. It explains MX records and mail-related TXT records in context.

The handoffs are store-and-forward:

mail app --submission--> sender MSA/MTA --relay--> receiver MTA --delivery--> mailbox

Suppose the receiving MTA replies 451 4.3.0 Temporary system problem. The sending MTA keeps the message in its queue and retries later. If it replies 550 5.1.1 Mailbox unavailable, that recipient normally fails permanently.

One message can have several recipients and several outcomes. The sending MTA might deliver to one domain, defer another, and reject a third. Delivery state belongs to each envelope recipient, not only to the message as a whole.

The Received fields in the delivered message show successful SMTP hops. Read them from the bottom upward because each new server prepends its own field. A missing hop is not automatically malicious; internal systems may summarize or hide topology, and provider APIs may expose different trace data.

Draw three recipients on two domains. Give one recipient a 250, one a 451, and one a 550. Record what the sender must do next for each address.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →