$ guides / postfix / postfix-relay-access-denied ▌

Operations Guides

Postfix Relay access denied: 554 5.7.1 and blocked senders

The mail log shows a pattern like this:

NOQUEUE: reject: RCPT from unknown[10.0.2.15]: 554 5.7.1 <user@external.example>: Relay access denied; from=<app@internal.corp> to=<user@external.example> proto=ESMTP helo=<app01.internal.corp>

A client connected to Postfix, sent MAIL FROM and RCPT TO for a recipient on an external domain, and Postfix rejected the message before queuing it. The recipient domain is not one Postfix considers local or a configured relay destination, and the client failed every authorization check. This is Postfix enforcing relay control exactly as designed.

The problem is usually not that Postfix is broken. It is that a legitimate client is not properly authorized. A new application sends from a subnet not in $mynetworks. A submission client authenticates on port 587 but permit_sasl_authenticated is missing from smtpd_relay_restrictions. A package upgrade advanced compatibility_level and changed a default. Occasionally the denials are background noise from open relay probes, which requires no fix.

This guide covers how to distinguish a real authorization problem from probe traffic, identify which restriction list is blocking the client, and fix the configuration without opening the server to unauthorized relay.

What this means

Postfix controls relay authorization through restriction lists evaluated in order. For Postfix 2.10 and later, relay control uses smtpd_relay_restrictions, evaluated separately from smtpd_recipient_restrictions. The default for new installations is:

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

Each restriction is evaluated in sequence. permit_mynetworks permits if the client IP matches an entry in $mynetworks. permit_sasl_authenticated permits if the client presented valid SASL credentials. defer_unauth_destination defers (4xx) delivery to any destination Postfix does not own.

The 554 5.7.1 permanent rejection in the symptom comes from reject_unauth_destination rather than the default defer_unauth_destination. Many production configurations explicitly use reject_unauth_destination in smtpd_relay_restrictions to give permanent failures instead of temporary deferrals. The Postfix SMTPD_ACCESS_README recommends this pattern:

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

When reject_unauth_destination is reached and the recipient domain is not in $mydestination, $relay_domains, $virtual_alias_domains, $virtual_mailbox_domains, $inet_interfaces, or $proxy_interfaces, Postfix rejects with 554 5.7.1 <recipient>: Relay access denied.

flowchart TD
    A["Client sends RCPT TO"] --> B{"In mynetworks?"}
    B -->|Yes| C["Permit relay"]
    B -->|No| D{"SASL authenticated?"}
    D -->|Yes| E["Permit relay"]
    D -->|No| F{"Recipient domain local?"}
    F -->|Yes| G["Accept for local delivery"]
    F -->|No| H["Reject: 554 5.7.1 Relay access denied"]

Restriction order matters. Postfix evaluates each restriction in the order listed and acts on the first definitive answer. If reject_unauth_destination appears before permit_sasl_authenticated, even authenticated clients are rejected for external destinations. Always verify the order, not just the presence of each restriction.

Postfix 3.6 introduced smtpd_relay_before_recipient_restrictions (default yes for compatibility_level >= 3.6). Before this change, smtpd_relay_restrictions was evaluated after smtpd_recipient_restrictions, which contradicted the documented separation. If compatibility_level is set below 3.6, the old order is preserved and relay control may depend on smtpd_recipient_restrictions behavior.

Common causes

Cause	What it looks like	First thing to check
Client IP not in mynetworks	App on a new subnet or container bridge network	`postconf -h mynetworks`, compare with logged client IP
SASL auth missing from relay restrictions	AUTH succeeds on 587 but relay still denied	`postconf -h smtpd_relay_restrictions` for `permit_sasl_authenticated`
Duplicate restriction definitions in main.cf	Config edited multiple times; last instance wins	`grep -c '^smtpd_relay_restrictions' /etc/postfix/main.cf`
Postfix upgrade changed defaults	Denials started after package update	`postconf -h compatibility_level` and `mynetworks_style`
NAT or container IP mismatch	Expected IP differs from what Postfix logs	Trust the client IP in the log line, not the expected one
IPv6 address not in mynetworks	Works over IPv4, denied over IPv6	Check mynetworks for IPv6 CIDR ranges
Open relay probe traffic	Sporadic denials from unfamiliar IPs, no user complaints	No action needed; restrictions are working

Quick checks

All commands below are read-only and safe to run on a production server. The log path may be /var/log/maillog on RHEL-family systems instead of /var/log/mail.log.

# Show effective relay and recipient restrictions
postconf -h smtpd_relay_restrictions
postconf -h smtpd_recipient_restrictions

# Show trusted networks and style
postconf -h mynetworks
postconf -h mynetworks_style

# Show compatibility level
postconf -h compatibility_level

# Show restriction evaluation order (Postfix 3.6+)
postconf -h smtpd_relay_before_recipient_restrictions

# Count relay denials in recent logs
grep 'relay access denied' /var/log/mail.log | wc -l

# Top client IPs hitting relay denials (IPv4 only)
grep 'relay access denied' /var/log/mail.log | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | sort | uniq -c | sort -rn | head

# Check whether any denied clients were SASL-authenticated
grep 'relay access denied' /var/log/mail.log | grep -c 'sasl_method='

# Check for duplicate restriction definitions (each should be 1)
grep -c '^smtpd_relay_restrictions' /etc/postfix/main.cf
grep -c '^smtpd_recipient_restrictions' /etc/postfix/main.cf

# Check relay_domains setting
postconf -h relay_domains

# Show submission service definition and any master.cf overrides
postconf -M submission/inet

How to diagnose it

Extract the client IP from the log line. The reject entry shows the actual IP Postfix sees in the RCPT from <hostname>[<ip>] field. In containerized or NAT environments, this may differ from the IP you expect. Trust the logged value.
Verify the client IP against mynetworks. Run postconf -h mynetworks and check whether the logged client IP falls within any listed CIDR range. If mynetworks is not set explicitly, Postfix derives it from mynetworks_style. The default is subnet when compatibility_level is below 2; at level 2 or higher the default is host, which trusts only the server’s own IP address.
Check whether the client authenticated. If the client connected to port 587 (submission) and authenticated via SASL, the surrounding log entries should show sasl_method=. If AUTH succeeded but relay was still denied, permit_sasl_authenticated is likely missing from smtpd_relay_restrictions, or it appears after reject_unauth_destination in the list.
Check for duplicate definitions. If smtpd_recipient_restrictions or smtpd_relay_restrictions appears more than once in main.cf, the last definition wins. An earlier definition that includes permit_sasl_authenticated is silently overridden by a later one that does not. The grep -c '^parameter' checks above catch this.
Check master.cf for submission overrides. The submission service on port 587 may have its own -o overrides in master.cf that replace the main.cf values. Run postconf -M submission/inet to see the service definition. If the override sets smtpd_recipient_restrictions without permit_sasl_authenticated, authenticated clients on 587 will be rejected.
Consider upgrade-related default changes. If denials began after a Postfix package upgrade, check compatibility_level. Advancing compatibility_level can change defaults for relay_domains and smtpd_relay_restrictions. Per the COMPATIBILITY_README: the modern smtpd_relay_restrictions default applies from compatibility_level 1 (below that the backwards-compatible default is empty), while the modern defaults for mynetworks_style (host) and relay_domains (empty) apply from level 2 (below that: subnet and $mydestination). On Postfix 3.9.0 and later, the removed restrictions check_relay_domains, permit_naked_ip_address, and reject_maps_rbl log a warning that support has been removed and no longer have any effect. Replace check_relay_domains with reject_unauth_destination.
Distinguish probe traffic from real failures. Sporadic denials from unfamiliar IPs with no user complaints are likely open relay probes. No action is needed. Correlate the denial rate with user reports: if no users are complaining about mail not going through, the denials are probe noise.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
Relay denial rate	Spikes indicate probe activity or a new misconfigured client	Sudden increase from unfamiliar IPs
Relay denial by client IP	Identifies specific clients hitting restrictions	Same IP denied repeatedly with increasing frequency
SASL authentication failure rate	Distinguishes auth failures from restriction issues	High failures on port 587 preceding relay denials
Authenticated clients still denied	Indicates `permit_sasl_authenticated` missing from relay restrictions	`sasl_method=` present in denied log lines
Successful unauthenticated relay to external domains	Security incident: open relay or bypass	Any occurrence is critical
Compatibility level	Default changes activated by advancing level	Changed after package upgrade without config review

Fixes

The commands below modify main.cf or master.cf and apply changes with postfix reload. Test on a staging server first if possible. Back up the current config before proceeding:

cp /etc/postfix/main.cf /etc/postfix/main.cf.bak.$(date +%Y%m%d%H%M)

Add the client IP to mynetworks

If the client is a legitimate internal application or relay peer, add its IP or subnet to mynetworks. This replaces the entire value, so include all existing entries:

# Add a subnet to mynetworks (preserve existing entries)
postconf -e 'mynetworks = 127.0.0.0/8, 10.0.2.0/24'
postfix reload

Use CIDR notation. Include IPv6 ranges if the client may connect over IPv6. Never use 0.0.0.0/0 or ::/0, which creates an open relay.

Add permit_sasl_authenticated to smtpd_relay_restrictions

If clients authenticate on port 587 but are still denied relay, ensure permit_sasl_authenticated appears in smtpd_relay_restrictions before reject_unauth_destination:

postconf -e 'smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination'
postfix reload

Also verify permit_sasl_authenticated in smtpd_recipient_restrictions if that list contains restrictive rules that could reject before relay restrictions are evaluated. This is relevant when smtpd_relay_before_recipient_restrictions = no, which is the case when compatibility_level is below 3.6.

Fix duplicate definitions

If smtpd_recipient_restrictions or smtpd_relay_restrictions appears twice in main.cf, remove the duplicate and consolidate into a single definition. The last occurrence silently overrides all previous ones.

Handle compatibility_level after upgrades

After a Postfix upgrade, review compatibility_level against the COMPATIBILITY_README for your version. If the upgrade advanced the level, defaults for relay_domains and smtpd_relay_restrictions may have changed. Explicitly set the values you need rather than relying on defaults.

Fix master.cf submission overrides

If the submission service has -o overrides in master.cf that set smtpd_recipient_restrictions, verify those overrides include permit_sasl_authenticated. A common pattern for submission-only services is:

-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

This is correct for port 587 where all clients must authenticate. Verify with postconf -M submission/inet after any change.

Handle IPv6 addresses

If mynetworks is set explicitly and the server communicates over IPv6, include IPv6 ranges or relay will be denied for IPv6 clients:

postconf -e 'mynetworks = 127.0.0.0/8, [::1]/128, 2001:db8::/32'
postfix reload

Replace deprecated restrictions (Postfix 3.9+)

If your config uses check_relay_domains, replace it with reject_unauth_destination. If it uses permit_mx_backup, replace it with explicit relay_domains configuration. On Postfix 3.9, check_relay_domains is removed (warning logged) and permit_mx_backup is deprecated with removal planned (warning logged); reject_unauth_destination and explicit relay_domains are the replacements.

Prevention

Document expected client networks and authentication methods. When a new application or relay peer comes online, add its IP to mynetworks or configure SASL credentials as part of deployment, not as a post-incident fix.
Test relay behavior after every config change. Send a test message from a client that should be authorized and one that should not.
Keep compatibility_level explicit. Set it deliberately in main.cf rather than letting package upgrades advance it silently. Review the COMPATIBILITY_README when upgrading.
Monitor the relay denial rate. A sudden spike may indicate a new misconfigured client or an application deployed with wrong credentials. A baseline of low-level probe traffic is normal.
Never use permissive shortcuts. Do not add 0.0.0.0/0 to mynetworks, do not remove reject_unauth_destination, and do not place permit rules before authorization checks. An open relay will get your IP blocklisted within hours.
Verify both restriction lists and master.cf overrides together. After any change, check smtpd_relay_restrictions, smtpd_recipient_restrictions, and submission service overrides as a set.

How Netdata helps

Relay denial rate. Netdata parses Postfix logs and surfaces rejection rates by type, including relay access denials. Use this to distinguish baseline probe noise from a spike that indicates a new misconfigured client.
SASL authentication failure correlation. Correlating authentication failures on port 587 with relay denials on port 25 determines whether the root cause is credentials or restriction list configuration.
Mail flow velocity. Tracking injected versus delivered message rates reveals whether relay denials are causing a real delivery gap or are harmless background noise.
Queue depth. If relay denials are preventing legitimate mail from flowing, the deferred or incoming queue shows secondary effects that confirm user impact.
Process and connection metrics. SMTPD process counts and connection rates help identify whether relay probe traffic is consuming resources.