The issue stems from the incorrect order of parameters in your Postfix main configuration file, specifically within the
smtpd_relay_restrictions directive. When
permit_mynetworks is placed after
reject_unauth_destination, Postfix rejects valid local sender connections before checking if they are authorized, effectively blocking external emails and outgoing mail despite correct network settings.
Understanding the Relay Restriction Logic
Postfix uses a specific logic flow to determine whether an email should be accepted or relayed. The
smtpd_relay_restrictions parameter defines this sequence. It is critical to understand that these restrictions are evaluated in the exact order they appear in the configuration file. If a rule matches, processing stops for that check.
The most common mistake occurs when administrators place the
reject_unauth_destination restriction before
permit_mynetworks. This causes Postfix to reject any email not destined for a local domain immediately, even if the client connecting is from a trusted local IP address. This results in the symptom where you cannot send emails externally, nor can you receive them from outside sources if the connection originates from a local interface.
To fix this, you must ensure that trusted networks are permitted first. This allows authenticated users or local services to bypass strict destination checks. Only after confirming the sender is authorized should Postfix verify if the recipient is valid for relaying.
Correcting the Configuration Order
You need to edit the main Postfix configuration file. On Debian systems, this file is typically located at
/etc/postfix/main.cf. Open this file using your preferred text editor with root privileges. For example, you might use:
sudo nano /etc/postfix/main.cf
Locate the line defining
smtpd_relay_restrictions. It may look something like this in its broken state:
smtpd_relay_restrictions = reject_unauth_destination, permit_mynetworks, permit_sasl_authenticated
This order is incorrect because
reject_unauth_destination will trigger first for non-local recipients, causing the rejection before
permit_mynetworks has a chance to allow the connection. You must reorder these parameters so that
permit_mynetworks comes first. The corrected line should read:
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
This ensures that any connection from an IP listed in
mynetworks is permitted to relay, regardless of the destination. Next, it checks for SASL authentication. Finally, it rejects any remaining requests that do not meet these criteria.
If you also have
smtpd_recipient_restrictions defined separately, ensure it follows a similar logical pattern, though often
smtpd_relay_restrictions handles the primary relay logic in modern Postfix versions. Always keep
reject_unauth_destination as the final catch-all to prevent open relay vulnerabilities.
After saving the changes, restart the Postfix service to apply the new configuration. Use the following command:
sudo systemctl restart postfix
Verify the change by sending a test email to an external address. If the issue persists, check the mail log at
/var/log/mail.log for any immediate error messages related to relay access.
For more detailed troubleshooting on related Postfix delivery issues, you might find
Troubleshooting Postfix: Local Delivery despite External Agent Configuration helpful if you suspect local delivery agents are interfering. Additionally, understanding how to manage sender addresses can prevent header mismatches, as discussed in
Change Postfix Sender Envelope MAIL FROM Address To Match Return Path Header Email For Multiple Domains.
Verifying MyNetworks Settings
Ensure that your
mynetworks variable includes the IP addresses of your server itself and any trusted subnets. Check the
/etc/postfix/main.cf file for the
mynetworks directive. It should include
127.0.0.0/8 and possibly
[::1]/128 for IPv6 localhost. If you are hosting multiple domains or services on the same machine, ensure their IPs are included.
An incorrect
mynetworks setting can cause the fix above to fail. If
permit_mynetworks is first but your IP is not in the list, the next rule will still reject you. You can test your effective mynetworks by running:
postconf mynetworks
Compare the output with your actual server IP addresses. Adjust as necessary and restart Postfix again.
Checking SpamAssassin Integration
Since your setup includes SpamAssassin, ensure it is correctly integrated via
content_filter in Postfix. Misconfiguration here can sometimes mimic relay issues by silently dropping or quarantining messages. However, the primary symptom of "external emails not accepted" combined with "outside addresses not sent" strongly points to the relay restriction order rather than content filtering.
If you suspect SpamAssassin is involved, check the logs for entries containing "spam" or "SA" during the transmission attempt. If no such entries appear, the message was likely rejected at the SMTP handshake level due to the relay restrictions, confirming the configuration order was the root cause.
Final Verification Steps
After applying the fix, perform comprehensive testing. Send an email from an external account to your server, then send one from your server to an external account. Both should succeed without errors. Monitor the logs during these tests to confirm that the
permit_mynetworks rule is being hit successfully.
If you continue to face challenges with email acceptance, consider reviewing other common pitfalls. For instance, some administrators encounter issues where emails are auto-deleted due to quota or storage misconfigurations, which is a different problem entirely but worth noting if your symptoms evolve. See
Automatically Deleted Postfix Emails for guidance on storage-related deletions.
Frequently Asked Questions
Why does order matter in smtpd_relay_restrictions?
Postfix evaluates restrictions sequentially and stops at the first match. If
reject_unauth_destination appears first, it blocks all non-local destinations immediately, ignoring subsequent
permit rules. Placing permits first ensures authorized clients are allowed through before strict destination checks occur.
What happens if I leave reject_unauth_destination out entirely?
Removing
reject_unauth_destination turns your server into an open relay, allowing anyone to send emails through your server. This is a severe security risk that will lead to your IP being blacklisted by major providers. Always keep this restriction as the final fallback.
How do I check if my network is in mynetworks?
Run
postconf mynetworks in the terminal. The output will list the IP ranges Postfix considers local. Ensure your server's public IP and any internal subnets used by mail clients are included in this list.
Can Dovecot affect these relay restrictions?
Dovecot handles IMAP/POP3 access and local delivery but does not directly control Postfix's SMTP relay logic. However, if Dovecot is configured to submit mail via Postfix (using port 587), it relies on the same
permit_sasl_authenticated rules. Ensure SASL authentication is working correctly between Dovecot and Postfix.
What log file shows relay rejection errors?
Check
/var/log/mail.log or
/var/log/mail.err on Debian systems. Look for lines containing "NOQUEUE: reject:" or "relay=none". These entries will specify the reason for rejection, such as "Client host rejected: Access denied," which indicates a restriction mismatch.