Fix a Postfix Relay access denied error safely

Relay access denied means the receiving Postfix instance has not authorized the requested delivery route. It often protects the server from forwarding mail from an untrusted client to an external domain. It can also reveal a missing destination-domain configuration or a client using the wrong submission service.

Start with the log entry: identify the rejecting host, client address, recipient domain, port, and authentication result. If your outbound log quotes a remote server's refusal, changing your local inbound relay rules will not fix that remote policy.

Check the effective configuration

postconf mynetworks mydestination virtual_alias_domains virtual_mailbox_domains
postconf relay_domains smtpd_relay_restrictions smtpd_recipient_restrictions

Unlike postconf -n, these explicit queries show the effective values even when they are defaults. Also inspect service-specific overrides in master.cf, especially for submission on port 587.

For Postfix 2.10 and later, the documented default relay restrictions are:

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

Older versions combined relay and recipient restrictions. Preserve an explicit unauthorized-destination safeguard appropriate to your deployed version and policy.

Match the fix to the server's role

A trusted application needs to send mail. Add only its required address or tightly controlled network to the existing mynetworks configuration. For example, a deliberately limited list might be:

mynetworks = 127.0.0.0/8, [::1]/128, 192.168.1.25/32

Do not replace an existing list without reviewing its clients. Addresses trusted by permit_mynetworks can relay, so shared or untrusted networks are inappropriate. Confirm the source address Postfix actually sees after proxies or NAT.

An external user needs submission. Configure SMTP AUTH with a working SASL backend and require encrypted submission. These parameters express only part of the setup:

smtpd_sasl_auth_enable = yes
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

They do not create a Dovecot/Cyrus authentication service or configure TLS by themselves. Scope authentication and TLS policy to the intended submission listener. Do not require every remote MTA delivering to public port 25 to authenticate.

The server is a gateway for another domain. Put only the domains you genuinely relay for in relay_domains, and configure routing plus valid-recipient checks such as relay_recipient_maps. Adding a domain permits that destination; it does not authorize its senders to relay everywhere.

The destination is hosted locally. Add it to the correct address class: mydestination, virtual_alias_domains, or virtual_mailbox_domains, with the required recipient and delivery configuration. Do not list the same hosted domain indiscriminately in all three.

Validate both permitted and denied paths

sudo postfix check
sudo postfix reload

Test a legitimate local destination, an authorized submission, and an unauthenticated external-to-external delivery attempt that must remain denied. Never fix the symptom by trusting 0.0.0.0/0, ::/0, or placing an unconditional permit before the relay safeguard.

For authentication failures, inspect the configured backend. testsaslauthd is relevant to Cyrus saslauthd, not a universal Dovecot test. For loopback clients, check both IPv4 and IPv6 and the actual listener overrides. The exact SMTP status and log context matter more than the phrase alone.

References

• Postfix SMTP access control
• Postfix SASL configuration