Before touching Postfix configuration, it helps to have a clear mental model of how internet email actually moves. Every mail system — Postfix, Exim, Sendmail, Exchange, Gmail — is an implementation of the same basic architecture defined by the SMTP family of RFCs (originally RFC 821/822, now RFC 5321/5322).

The four 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. Your MUA hands it to an MTA — either your local Postfix (submission) or your provider's SMTP server — using SMTP, usually over port 587 (submission) with authentication.
3. The MTA looks up the destination domain's MX record in DNS to find out which host accepts mail for that domain, and relays the message there over SMTP on port 25.
4. The receiving MTA either delivers the message locally to a mailbox (via its MDA), routes it onward again (relaying), or rejects/bounces it.
5. Your recipient's MUA retrieves the message from the mailbox using IMAP or POP3.

Note that 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/POP3 are pull-based protocols for retrieving it. Postfix (and MTAs in general) only ever speaks SMTP. It has no idea what IMAP or POP3 are — that's Dovecot's (or similar) job.

Store-and-forward and queueing¶

SMTP is fundamentally a store-and-forward protocol: at each hop, the receiving MTA accepts full responsibility for the message (queuing it to local disk) before it ever attempts to move it further, and only then does it try to deliver or relay onward. This is why a mail server can survive being disconnected from the recipient's server temporarily — it just retries from its queue.

This queuing behavior is central to how Postfix is built internally (see the Postfix overview doc) and explains most of what looks confusing in a mail log: messages accepted, queued, deferred, retried, and eventually delivered or bounced, are all separate events that can be minutes or days apart.

Envelope vs. headers — the most important distinction in email¶

Every message has two separate sets of "addressing" information, and confusing them is the source of most email misunderstandings:

• The envelope — exchanged during the SMTP conversation itself (MAIL FROM: and RCPT TO: commands). This is what actually controls delivery and routing. It is not part of the message content and the recipient's MUA never shows it to you directly.
• The headers — part of the message content itself (From:, To:, Cc:, Subject:, etc.), written into the message body before the DATA section. These are what your mail client displays, but they have no effect on where the message is actually delivered — a message can say From: [email protected] in its headers while the envelope sender (MAIL FROM) is something completely different. This mismatch is normal for mailing lists and bounce handling, and is also exactly what spam/phishing abuses.

This distinction matters directly for Postfix: things like smtpd_sender_restrictions and smtpd_recipient_restrictions act on the envelope, while header_checks acts on the headers/body.

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.