How email is delivered: MX, SMTP and every hop

The path, in five steps#

1. Submission. Your mail client hands the message to your provider’s server.
2. Lookup. That server asks DNS where mail for the recipient’s domain goes.
3. Transfer. It connects to that server and hands the message over with SMTP.
4. Checks. The receiving server decides whether to accept it, and where to file it.
5. Delivery. The message lands in a mailbox, where the recipient’s client reads it.

Submission#

Your client does not deliver mail itself. It signs in to your provider’s submission server, conventionally on port 587, and hands the message over (RFC 6409). Signing in matters: it is how your provider knows the message is yours to send, before it vouches for it to the rest of the internet.

Finding the receiving server#

The sending server takes the domain after the @ and looks up its MX records. Each names a mail server and a preference number; lower numbers are tried first.

example.org.  MX  10 mx1.mail.example.net.
example.org.  MX  20 mx2.mail.example.net.

Two details most explanations skip. If a domain publishes no MX records, SMTP falls back to treating the domain’s own address record as an implicit MX (RFC 5321, section 5.1). And a domain that receives no mail at all can say so explicitly with a null MX, a single MX pointing at ., so senders stop trying (RFC 7505).

The handover#

Server-to-server delivery uses SMTP on port 25. It is a conversation in plain commands: the sender introduces itself, gives the envelope sender and recipients, then sends the message and waits for a reply code.

S: 220 mx1.mail.example.net ESMTP
C: EHLO mail.example.com
S: 250-STARTTLS
C: STARTTLS
   (the connection is now encrypted)
C: MAIL FROM:<[email protected]>
C: RCPT TO:<[email protected]>
C: DATA
   (headers, blank line, body)
S: 250 OK: queued

The encryption step, STARTTLS, is optional by design (RFC 3207). The receiving server offers it and the sender takes it if it can. That makes it easy to deploy and easy to defeat: an attacker in the path can remove the offer, and the RFC says so. The two servers then carry on in the clear and neither complains.

MTA-STS closes that gap (RFC 8461). A receiving domain publishes a policy, over HTTPS, saying it always offers TLS with a valid certificate for its named MX hosts. A sending server that has seen the policy refuses to deliver without it.

What the receiving server checks#

Accepting a message is a decision, and three checks feed it. Each looks at a different part of the message:

1. SPF asks whether the connecting server’s address is one the MAIL FROM domain authorises (RFC 7208).
2. DKIM verifies any signatures in the headers against public keys published in DNS (RFC 6376).
3. DMARC asks whether either of those passed for a domain that matches the visible From, and reads the From domain’s policy for what to do if not (RFC 9989).

Then come the receiver’s own judgements: reputation, content, the recipient’s past behaviour. Authentication does not guarantee the inbox. Failing it makes the inbox much less likely, and for bulk senders to Gmail, Yahoo and Outlook.com it is now a requirement.

Every hop leaves a trace#

Each server that accepts the message adds a Received header at the top, recording who handed it over, from which address, and when (RFC 5321, section 4.4). Read from the bottom up, they are the route the message took.

Received: from mail.example.com (mail.example.com [198.51.100.25])
        by mx1.mail.example.net with ESMTPS id 4Xyz;
        Mon, 5 Oct 2026 09:14:03 +0000
Received: from [10.0.0.12] (laptop.example.com [10.0.0.12])
        by mail.example.com with ESMTPSA id 9Abc;
        Mon, 5 Oct 2026 09:14:02 +0000

Only the top header was written by a server you trust: your own provider’s. Every line below it was written by whoever handled the message before.

That is why a careful receiver reads only the header its own server added, and why our message check does the same. To see your domain’s MX hosts, MTA-STS policy and authentication records in one view, scan the domain.