Postfix relay policy is an ordered trust decision
An SMTP relay accepts a message and forwards it to another domain. The feature is useful for application alerts, internal mail routing, and authenticated submission. The same feature becomes an open relay when the server cannot distinguish an authorized sender from an untrusted client. Postfix separates relay control from general recipient checks for a reason: the relay decision should be readable and testable on its own.
Read the restriction list from left to right
Postfix evaluates smtpd_relay_restrictions in the context of RCPT TO. The default list uses permit_mynetworks, permit_sasl_authenticated, and defer_unauth_destination. The first matching restriction decides the outcome. If permit_mynetworks matches before a destination restriction, that client is allowed to relay. The order is part of the policy, not an implementation detail.
The Postfix compatibility guide explains that the relay restriction feature was introduced as a safety mechanism for legacy recipient-restriction configurations. It also documents the risk of putting permit_mynetworks or permit_sasl_authenticated into smtpd_recipient_restrictions and then adding a restriction that can reject every destination. A separate relay list makes the intended default easier to audit.
Inventory what mynetworks really means
mynetworks is a trust list, not a synonym for "internal." On a host with multiple interfaces, a container bridge, or a NAT address, the default derivation may be broader than the operator expects. Set the list explicitly when the trust boundary is known. Review proxy and load-balancer paths because a connection from a trusted relay can hide the original client identity.
Allow SASL-authenticated submission only on the ports and services that are designed for it. Require TLS for credentials on untrusted networks. Rate-limit authenticated senders and watch for a single account sending to many domains. Authentication proves which account submitted a message; it does not prove that the account should be allowed to send every kind of mail.
Test with an external recipient
From a network that is not in mynetworks, connect to the SMTP service and attempt to relay to an external domain. Confirm the server rejects the attempt before accepting message content. Repeat with a valid SASL account and confirm the intended path succeeds. Test a sender address that looks internal but comes from an untrusted client, because spoofed envelope data is not a network identity.
Review the postconf -n output and the effective restriction lists on every instance. A container image, a configuration management default, and a manual rescue edit can produce three different answers. Include the queue manager and local submission path in the test plan; the public SMTP listener may be correct while a local helper still creates surprising relay paths.
Observe relay behavior
Log the client address, authenticated identity if present, recipient domain, restriction result, and queue outcome. Alert on a sudden increase in outbound volume or on a source that produces many rejected relays. Keep the logs long enough to investigate a campaign, but avoid storing message bodies unless the retention policy permits it.
The safest configuration is the one an operator can explain in a single line: which clients may relay, how they prove that authority, and what happens to everyone else. Document that line and test it from both sides.
Top comments (0)