
Your email bounced back with “554 5.7.1: Relay access denied.”
This permanent rejection happens when the mail server refuses to send (relay) your email — usually because you haven’t authenticated with SMTP or your host isn’t authorized to relay through that server.
The error occurs during the SMTP transaction at two points:
- When your outgoing server blocks the relay attempt
- When the recipient’s gateway (such as Proofpoint) enforces closed-relay policies
Step 1: Enable SMTP authentication in your email client
Most relay access errors happen because SMTP authentication is disabled in your email application.
Check these settings in Outlook, Thunderbird, or your email client:
- Open account settings and find the Outgoing Server (SMTP) section
- Enable “My outgoing server (SMTP) requires authentication”
- Verify your username and password are typed correctly
- Confirm that the SMTP server address matches your provider’s settings.
It should be smtp.gmail.com for Gmail, smtp.office365.com for Outlook, and smtp.mail.yahoo.com for Yahoo.
Set the correct port and encryption:
| Port | Encryption | Use for |
| 587 | TLS or STARTTLS | Gmail, Outlook (recommended) |
| 465 | SSL | Gmail, Yahoo, older setups |
Test your settings after making changes. Re-enabling authentication resolves the issue immediately when it has been disabled.
Step 2: Check your DNS records
If client settings are correct but emails still bounce, your domain’s DNS might be misconfigured (although relay errors are primarily related to authorization, not DNS).
Do email deliverability testing to check your SPF record, DKIM, and DMARC setup. Authentication failures typically produce different bounce messages, but verifying these records eliminates one variable.
Fix your MX record if it points to a server that isn’t configured to accept mail for your domain.
When your MX directs to a non-authoritative server (one that doesn’t handle your domain), you’ll see “relay access denied.” Ensure your MX points to your actual email provider’s servers.
Step 3: Check if you’re blacklisted
Blacklisting causes bounces, though “relay access denied” text usually points to authorization issues rather than reputation blocks.
Check your status as a secondary diagnostic step:
- Visit mxtoolbox.com/blacklists.aspx
- Enter your domain or IP address
- Review any Real-time Blackhole List (RBL) listings
If you’re blacklisted, identify the cause (spam complaints, high bounce rates, compromised account) before requesting removal. Your email deliverability expert can help diagnose reputation damage and create a recovery plan.
Running an email warm-up helps with broader deliverability and reputation building (separate from fixing relay permission issues). Warmup gradually increases sending volume and generates positive engagement signals.
Step 4: Server admin fixes
If you manage your own mail server, check these configurations:
- Verify SMTP authentication is enabled on the server (not just the client)
- Whitelist trusted IP addresses that need relay access without authentication
- Review recent software updates that might have changed configurations
For Plesk servers experiencing sudden relay failures, confirm mail relay settings and consider running plesk repair mail per Plesk guidance if authentication settings appear corrupted.
For closed relay systems (Proofpoint, Spambrella), ensure the sending email address is listed as an authorized user or functional account. Changes take 30-60 minutes to propagate.
Still getting relay access denied?
Configuration errors can be tricky to diagnose without checking logs and testing multiple scenarios.
Schedule a free consultation with our email deliverability experts.
We’ll review your setup, identify the issue blocking your emails, and resolve the relay problem for you.
Frequently asked questions about 554 5.7.1 error
Here are some commonly asked questions about the “relay access denied” error:
The 554 is permanent (the server won’t retry), while 454 is temporary (the server will retry delivery later).
No. Wrong recipients generate 550 5.1.1 (user unknown). “Relay access denied” specifically indicates relay authorization failed, not an invalid address.
Absolutely. POP before SMTP is legacy, IP-based authentication that fails when your IP changes (switching WiFi networks on mobile). SMTP authentication stays stable regardless of IP changes.
DNS changes take anywhere from minutes to 24-48 hours, depending on TTL settings and your provider’s propagation speed.