Follow one email across the Internet

You press Send. Your app opens an authenticated TLS connection to your provider and hands over the message. That’s submission.

Your provider now has to find Sara’s mail server. It asks DNS for the MX records of studiorossi.it, the hostnames that accept mail for that domain. You can run the same lookup yourself:

dig MX studiorossi.it +short

10 mx.studiorossi.it.

The provider opens an SMTP connection to mx.studiorossi.it, transfers the message, and waits for the reply. If that server says “try later”, the message goes into a queue and the provider retries.

Sara’s server filters the message and drops it into her mailbox. She reads it with IMAP, POP3, JMAP, a provider API, or webmail.

If the DNS step is new to you, do the DNS Course first. It covers MX records and the TXT records that email depends on.

Store and forward

Every handoff works the same way: receive the whole message, store it, then pass it on.

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

No server keeps a live connection open all the way to Sara’s phone. Each one accepts responsibility, then works independently.

What the replies mean

Suppose Sara’s server answers 451 4.3.0 Temporary system problem. My provider keeps the message in its queue and tries again in a few minutes. Sara’s server was just busy.

Now suppose it answers 550 5.1.1 Mailbox unavailable. That’s permanent. Retrying won’t help. My provider gives up on that recipient and sends me a bounce.

The first digit tells you which case you’re in. 4 means wait. 5 means stop. We’ll go deeper into reply codes in the SMTP module.

One message, many outcomes

A message to three people can end three different ways. The sender delivers to one, defers another, and gets rejected by a third. Delivery state belongs to each recipient, not to the message.

That’s why “was my email delivered?” is often the wrong question. Ask “was it delivered to Sara?”.

Reading the trace afterwards

Open the delivered message’s raw source. Each Received header is one successful SMTP hop. Read them bottom to top, because every server adds its own line above the previous ones.

A missing hop isn’t automatically suspicious. Internal servers often collapse several steps into one line, and provider APIs may expose different trace data.

Try this on paper: three recipients across two domains. Give one a 250, one a 451, one a 550. Write what the sender must do next for each address.