Postfix's 554 5.7.1 <user@domain>: Relay access denied means the server refused to accept a message for onward delivery because the connecting client isn't authorized to relay through it. There are exactly four root causes, client on the wrong port, SASL auth missing, recipient domain not configured, or DNS pointing mail at the wrong box, and the fix is different for each, so identify your scenario first.
First question: who is being denied?
| Scenario | Symptom | Root cause family |
|---|---|---|
| Your users/app can't send outbound through your server | Mail client or script gets the error on send | Port or SASL problem (causes 1-2) |
| External servers can't deliver TO your domain | Outsiders bounce when emailing you | Domain config or DNS problem (causes 3-4) |
Everything below sorts into one of these two. Check your logs to confirm which client is being refused:
grep "Relay access denied" /var/log/mail.log | tail -5
# look at the client= hostname/IP in the matching smtpd lines
Cause 1: Client connecting on port 25 instead of 587
Port 25 is for unauthenticated server-to-server delivery. Postfix correctly refuses relay there. End users and applications must use the submission port (587) with authentication, see port 587 and the other SMTP ports for which to use when.
Check that submission is enabled in /etc/postfix/master.cf:
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
Then point your client/app at port 587 with STARTTLS and a username/password. Verify from outside:
swaks --to [email protected] --from [email protected] \
--server mail.yourdomain.com --port 587 --tls \
--auth-user [email protected]
Cause 2: SASL authentication not enabled or not used
If the client is on 587 but still denied, authentication isn't happening, the relay decision hinges on whether SMTP AUTH / SASL authentication succeeded. Two sub-cases:
Server side, SASL is off. In /etc/postfix/main.cf:
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
permit_sasl_authenticated missing from smtpd_relay_restrictions is the single most common cause of this whole error. Confirm what's live:
postconf smtpd_relay_restrictions smtpd_sasl_auth_enable
Client side, the app never sends credentials. Many libraries silently skip AUTH if TLS fails; check that the client trusts your certificate and actually has SMTP auth configured.
For a trusted app server on your LAN, the alternative is mynetworks:
mynetworks = 127.0.0.0/8 10.0.5.12/32
Add single IPs only. A broad range here is an open relay, and an open relay is a blacklisting within hours.
Cause 3: Postfix doesn't know it owns the recipient domain (inbound)
When outsiders bounce with relay access denied while emailing your domain, Postfix doesn't consider itself the final destination. It must be told, in exactly one of these:
# Local Unix mailboxes
mydestination = yourdomain.com, mail.yourdomain.com, localhost
# OR virtual mailboxes (Dovecot/db-backed) - never list a domain in both
virtual_mailbox_domains = yourdomain.com
Listing the domain in both mydestination and virtual_mailbox_domains causes its own warnings and misrouting; pick the one matching your mailbox setup. If this server forwards for the domain instead of hosting it, use relay_domains plus a transport_maps entry.
Apply and verify:
postfix reload
swaks --to [email protected] --server mail.yourdomain.com --port 25
Cause 4: MX points at a server that doesn't host the domain
Same symptom as cause 3, different layer: your MX record sends the world's mail to a box that was never configured for the domain, a web host, an old server, a proxy. Check where mail actually goes:
dig MX yourdomain.com +short
dig A mail.yourdomain.com +short
If that IP isn't your mail server, fix DNS. Classic versions: MX left pointing at a previous provider after migration, or MX resolving through a CDN/proxy that doesn't pass port 25.
A 5-minute diagnostic sequence
When you don't want to theorize, run these in order, each one eliminates a cause:
# 1. What restrictions are actually live? (not what you think you configured)
postconf -n | grep -E "relay_restrictions|recipient_restrictions|sasl|mynetworks|mydestination|virtual"
# 2. Is the submission service even listening?
ss -lntp | grep -E ":587|:25"
# 3. Does the server advertise AUTH on 587?
swaks --server mail.yourdomain.com --port 587 --tls --quit-after EHLO
# look for "250-AUTH PLAIN LOGIN" in the output
# 4. Reproduce both directions
swaks --to [email protected] --from [email protected] --server mail.yourdomain.com --port 587 --tls --auth # outbound
swaks --to [email protected] --from [email protected] --server mail.yourdomain.com --port 25 # inbound
If step 3 shows no AUTH line, TLS or SASL plumbing is broken (cause 2). If outbound works but inbound is denied, it's cause 3 or 4. If both fail, start at cause 1. Watching /var/log/mail.log in a second terminal while running step 4 shows you exactly which restriction fired. Postfix logs the rejecting rule.
What NOT to do
| Tempting "fix" | Why it's wrong |
|---|---|
mynetworks = 0.0.0.0/0 | Open relay; blacklisted same day |
Removing reject_unauth_destination | Same thing, different spelling |
| Allowing relay on port 25 for your app | Works until the IP changes; use 587 + SASL |
If you're building a sending server from scratch and want the restrictions, SASL, TLS, and DNS done in the right order, our SMTP server setup guide for bulk email covers the full sequence, and authentication records come next in the SPF/DKIM/DMARC guide.
How BulkEmailSetup helps
We deliver dedicated SMTP servers with submission, SASL, TLS, and relay restrictions configured correctly from day one, locked down enough to never be an open relay, open enough that your apps just send. See pricing.
Frequently asked questions
What does 'Relay access denied' mean in Postfix?
Postfix refused to accept a message for onward delivery because the client isn't authorized to relay: it isn't authenticated, isn't in mynetworks, and the recipient domain isn't one Postfix accepts mail for. It's an authorization failure, not a bug.
Why do I get relay access denied when sending from my own mail client?
Almost always because the client connects on port 25 instead of the submission port 587, or SASL authentication isn't enabled/used. Port 25 is for server-to-server mail; clients must authenticate on 587.
Why do external servers get relay access denied when sending TO my domain?
Postfix doesn't know it's responsible for your domain. The domain is missing from mydestination (or virtual_mailbox_domains), so Postfix treats inbound mail as a relay attempt and refuses it.
Should I just add the sender's IP to mynetworks to fix it?
Only for trusted local machines like your app server. Adding broad ranges to mynetworks creates an open relay, which gets your IP blacklisted within hours, spammers scan for open relays constantly.
Is relay access denied related to my SPF or DKIM setup?
No. It happens at the SMTP RCPT stage, before any content or authentication-header checks. It's purely about whether Postfix is willing to accept the recipient.
