Postfix Routing, Relay Domains and Transport Decisions
Anil Jalela · Published · 8 min read
Postfix must distinguish domains it owns, domains it relays for, and ordinary remote destinations before choosing a delivery transport. This lesson treats Postfix relay and transport routing as one decision point in a longer message path. The configuration is useful only when an operator can show which message entered it, which identity and rule matched, what the next daemon returned, and how a failure is retried or contained.
Prerequisites and inherited lab checkpoint
Lesson 5 must return correct positive and negative virtual-recipient and alias lookups before routing is added.
For the Postfix relay and transport routing lab, use reserved domain example.test, documentation addresses and disposable messages. Preserve postconf -n, postconf -M, package versions, DNS answers and a queue baseline before changing the lab. Keep console access and do not copy credentials, private keys or customer messages into the evidence record.
Install and prepare the required components
sudo dnf info postfix cyrus-sasl-plain
sudo dnf install -y postfix cyrus-sasl-plain
sudo cp -a /etc/postfix /etc/postfix.before-nitwings
rpm -q postfix cyrus-sasl-plain
Confirm package availability and ownership in the enabled RHEL repositories before adding a third-party source. Record the repository, signing key fingerprint, version and support lifecycle.
A package install creates files and service identities; it does not establish safe relay, authentication, delivery or filtering behavior.
Back up only the files this lesson changes and record modes, owners and SELinux labels so rollback restores more than text.
Use systemctl cat, package file lists and local manual pages to identify paths on the installed build instead of assuming a path from another distribution.
Build the Postfix relay and transport routing configuration and understand every boundary
Route one explicitly relayed domain through a private next hop and validate its recipients at RCPT time.
Square brackets suppress MX lookup for the relay hostname. The recipient map prevents acceptance of every address in the relayed domain and the backscatter that would follow downstream rejection.
Replace sample hostnames, addresses and queue IDs only after resolving them from the lab. Do not paste production identities into a public command transcript.
postconf -n shows non-default global parameters; postconf -M and postconf -P expose master service and field overrides.
A successful lookup proves only that input. Test present, absent, disabled and dependency-unavailable results separately.
Use the queue ID as the correlation key. Message subjects and recipient addresses are not unique and may contain sensitive information.
Evidence and acceptance criteria
Evidence
Healthy result
Failure meaning
Syntax
All component validators succeed before activation
The running service would parse an unreviewed or invalid state
Positive path
The listed recipient is accepted and delivered once through the bracketed relay.
The intended message cannot complete this decision point
Negative path
An unknown branch recipient and unrelated unauthenticated relay destination are rejected during RCPT.
The configuration may relay, authenticate, route or deliver too broadly
Dependency failure
Stopping the relay creates a deferred record with a future retry and no message loss.
Messages may be lost, permanently rejected or silently bypass controls
Persistence
Effective state and tests agree after restart and reboot
Only transient state was changed
A catch-all relay domain creates backscatter
A migration edge lists a customer domain in relay_domains but has no recipient truth. It accepts typos, then the internal server rejects them after DATA, producing nondelivery reports toward forged senders. A maintained relay-recipient map moves the rejection to the original RCPT transaction.
Troubleshooting by symptom
Symptom
Inspect first
Defensible next action
Mail loops
Received chain, transport result and address class on both hosts
Choose one final destination and correct the returning route
Transport ignored
Effective map order and exact postmap key
Correct the lookup key and rebuild the indexed map
All recipients accepted
relay_recipient_maps output
Return a value only for provisioned recipients
Smart-host login fails
TLS port, SASL map and file permissions
Fix outbound authentication without weakening inbound relay policy
Unsafe operations and recovery boundaries
Unsafe: a broad relay domain without recipient validation accepts mail that cannot be delivered.
Unsafe: world-readable relay credentials expose the smart-host account.
Unsafe: flushing the entire queue destroys legitimate mail and incident evidence.
Rewritten knowledge checks
Do transport maps authorize relaying?
No. They select delivery after address-class and relay authorization decisions.
What do brackets around a next hop mean?
Use that host directly without MX lookup.
What proves a loop is gone?
One queue ID reaches a final destination once and does not return to an earlier hop.
Why test an absent value?
It proves the configuration denies or returns not-found instead of matching a broad default.
Why retain a queue ID?
It joins SMTP, policy, routing, filtering and delivery evidence without relying on non-unique subject text.
What must be captured before this change?
The effective configuration, package versions, owned sockets, a UTC test result and the exact files or database rows that rollback will restore.
Why is a service restart not an acceptance test?
A running process does not prove the intended message path, denial path, dependency failure behavior or persistence.
What makes a placeholder safe to replace?
Its source, format, owner and scope are explained and the substituted value is verified before activation.
When should rollout stop?
Stop when identity is ambiguous, syntax fails, the negative test becomes permissive, a dependency failure produces permanent loss or rollback cannot be executed.
What evidence belongs in handover?
The reviewed configuration, syntax output, positive and negative transcripts, logs, monitoring threshold, backup location and tested rollback result.
Cumulative lab checkpoint
Capture the inherited checkpoint and state the exact sender, recipient, client address and expected SMTP result.
Install the required package from a recorded source and save the package/file/service inventory.
Apply the complete lab configuration, including permissions, socket paths, map generation and service ownership.
Run syntax and lookup validation, then activate without closing the recovery session.
Complete positive, negative and dependency-outage tests while retaining queue IDs and UTC logs.
Restart the participating services, repeat the accepted path and confirm no unexplained deferred mail remains.
Execute rollback once, prove the previous behavior, then reapply the reviewed state as the checkpoint for the next lesson.
