Before touching any MTA configuration, it helps to have a clear mental model of how internet email actually moves. Every mail system (Postfix, Exim, Sendmail, Exchange, Gmail) implements the same basic architecture defined by the SMTP family of RFCs. These were originally RFC 821/822 and are now RFC 5321 (the SMTP protocol) and RFC 5322 (the message format).

The roles¶

Mail systems are described in terms of roles, not products. A single piece of software often plays several roles at once.

A typical round trip:

1. You compose a message in your MUA.
2. The MUA submits it to an MSA, usually your provider's or your own server's port 587 or 465, with authentication.
3. The MTA looks up the destination domain's MX record in DNS to find which host accepts mail for that domain, and relays the message there over SMTP on port 25.
4. The receiving MTA delivers the message to a mailbox via its MDA, relays it onward again, or rejects or bounces it.
5. The recipient's MUA retrieves the message from the mailbox with IMAP (or POP3, or JMAP on some modern servers).

Steps 2–3 and step 5 use completely different protocols and ports. SMTP is a one-way, push-based, store-and-forward protocol for transporting mail. IMAP and POP3 are pull-based protocols for retrieving it. Postfix, like every MTA, only ever speaks SMTP (and LMTP). It knows nothing about IMAP or POP3. That's Dovecot's job.

 MUA ──587/465 (submission, AUTH)──► MSA/MTA ──25 (SMTP)──► MTA ──LMTP──► MDA ──► mailbox
  ▲                                                                            │
  └────────────────────────── 993 IMAPS / 995 POP3S ◄──── IMAP/POP server ◄────┘

Store-and-forward and queueing¶

SMTP is a store-and-forward protocol. At each hop, the receiving MTA accepts full responsibility for the message by writing it to its queue on disk before answering 250 OK, and only then tries to deliver or relay it further. That's why a mail server can survive the recipient's server being unreachable for hours or days: it simply retries from its queue (by default Postfix keeps trying for five days, maximal_queue_lifetime).

This queueing is central to how Postfix is built internally (see Postfix Overview and Architecture). It also explains most of what looks confusing in a mail log. Accepted, queued, deferred, retried, delivered and bounced are all separate events that can be minutes or days apart, tied together by a queue ID.

Envelope vs headers: the most important distinction in email¶

Every message carries two separate sets of addressing information. Confusing them causes most email misunderstandings.

• The envelope is exchanged in the SMTP conversation itself (MAIL FROM: and RCPT TO:). It controls delivery and routing. It isn't part of the message content, and the recipient's MUA doesn't normally show it (the receiving MTA records the envelope sender as a Return-Path: header on final delivery).
• The headers are part of the message content (From:, To:, Cc:, Subject:…), sent inside the DATA section. They're what your mail client displays, but they have no effect on where the message is delivered. A message can say From: [email protected] while the envelope sender is something else entirely. That's normal for mailing lists and bounce handling, and it's also exactly what phishing abuses.

Examples of the difference in practice:

This matters directly for configuration. Postfix's smtpd_sender_restrictions and smtpd_recipient_restrictions act on the envelope. header_checks acts on the headers. SPF checks the envelope sender's domain. DMARC checks the header From: domain.

Ports you'll actually see¶

When you see relayhost = [smtp.gmail.com]:587 or :465 in a Postfix config, that's Postfix acting as a submission client, authenticating to a smart host exactly the way a mail client would.