The 554 5.7.1 relay access denied error is a permanent SMTP rejection that occurs when your mail server refuses to forward your email.
“Relay” means passing a message through an intermediate server, and “access denied” means that the server rejected the request because it doesn’t recognize you as an authorized sender.
This is a 5xx error, which signals permanent failure. Your email won’t retry automatically — it sits in the outbox until you fix the underlying problem (usually a matter of minutes once you know where to look).
The rejection triggers at two points:
- Your outgoing mail server blocks the relay attempt
- The recipient’s gateway (Proofpoint, Barracuda, Spambrella) enforces a closed-relay policy
Most cases trace back to one issue — SMTP authentication is either disabled or misconfigured in your email client settings.
Step 1: Enable SMTP authentication
SMTP authentication is the most common fix because most relay errors happen when this setting is turned off.
Your mail server needs to verify your identity before it agrees to forward messages on your behalf — without authentication, it treats you as an unauthorized sender and blocks the relay.
The fix takes about 30 seconds once you find the right settings panel.
Outlook
Open your account settings and find the Outgoing Server (SMTP) section. You’ll need to change four things:
- Enable “My outgoing server (SMTP) requires authentication”
- Select “Use same settings as my incoming mail server” or enter credentials manually
- Verify username and password match your email provider’s requirements
- Confirm the SMTP server address is correct
Gmail
Gmail requires app passwords if you have two-factor authentication enabled. Your regular password won’t work for SMTP connections from third-party apps because Google blocks them for security reasons.
To generate an app password:
- Go to Google Account → Security → App passwords
- Select “Mail” and your device type
- Copy the 16-character password
- Use this password (not your regular one) in your email client
For Google Workspace accounts, check that “Less secure app access” is enabled in the admin console if you’re using older applications. App passwords remain the better long-term solution.
Provider settings
Different providers require different SMTP configurations. A port or encryption mismatch causes authentication to fail silently — which looks exactly like a relay error.
| Provider | SMTP Server | Port | Encryption |
| Gmail | smtp.gmail.com | 587 | TLS/STARTTLS |
| Outlook/Hotmail | smtp.office365.com | 587 | STARTTLS |
| Yahoo | smtp.mail.yahoo.com | 465 | SSL |
| Office 365 | smtp.office365.com | 587 | STARTTLS |
| iCloud | smtp.mail.me.com | 587 | TLS |
Double-check both port and encryption settings against this table. Mismatches are responsible for a surprising number of relay errors.
Are your DNS records configured correctly?
DNS misconfigurations can produce symptoms similar to relay errors, even though relay issues are primarily about authorization. If your client settings are correct but emails still bounce, your domain’s DNS might be the culprit.
MX records
Your MX record tells other servers where to deliver mail for your domain. If the MX points to a server that isn’t configured to handle your domain, you’ll see relay denied errors.
Check that your MX record points to your actual email provider:
- Gmail/Google Workspace: ASPMX.L.GOOGLE.COM (and alternates)
- Microsoft 365: *.mail.protection.outlook.com
- Custom server: your mail server’s hostname
MXToolbox can verify your MX records resolve correctly.
Authentication records
While authentication failures typically produce different bounce messages (like 550 5.7.1), verifying your setup eliminates one variable.
Run a quick check on your SPF lookup, DKIM lookup, and DMARC lookup to confirm everything passes.
Authentication issues and relay issues sometimes overlap — especially when enterprise gateways inspect both before accepting mail.
Could blacklisting be the problem?
Blacklisting causes delivery failures, but the 554 5.7.1 text usually points to authorization issues rather than reputation blocks. That said, checking your blacklist status takes 30 seconds and rules out one more variable.
Visit MXToolbox Blacklists and enter your domain or sending IP address. Review any listings on Real-time Blackhole Lists (RBLs).
If you’re listed, identify the cause before requesting removal:
- Spam complaints from recipients
- Inherited reputation from a shared IP
- Compromised account sending spam
- High bounce rates from bad list hygiene
Our guide on blacklist removal covers the delisting process in detail.
What if you manage your own server?
Self-hosted mail servers and enterprise security gateways have additional configuration points that can trigger relay errors. The fix depends on whether you’re running your own email infrastructure or sending through a corporate security gateway.
Self-hosted
Check these three configurations on your server (not just your client):
- SMTP authentication must be enabled server-side, not just client-side
- Recent software updates sometimes reset mail configurations without warning
- Trusted IP addresses need to be whitelisted if they require relay access without authentication
For Plesk servers experiencing sudden relay failures, run plesk repair mail to fix corrupted authentication settings. Plesk’s mail service occasionally breaks after updates.
For Postfix, verify smtpd_relay_restrictions in your main.cf allows authenticated users:
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destinationEnterprise gateways
Proofpoint, Mimecast, Barracuda, and Spambrella require the sending address to be registered as an authorized user or functional account. If you’re sending through one of these gateways, the fix usually involves adding your sender to the authorized list.
Common fixes:
- Verify the sending domain is listed in the relay policy
- Check that outbound mail routing includes your sending IP
- Add the sender email to the gateway’s authorized senders list
Changes to gateway policies take 30-60 minutes to propagate. Don’t assume the fix failed if emails bounce immediately — give it time.
What if the error persists?
If you’ve worked through these steps and still see relay denied errors, something deeper is misconfigured. Configuration troubleshooting gets tricky without access to server logs, but a few additional tests can help isolate the problem.
Try these:
- Test from a different network to rule out firewall or ISP blocking
- Send a test email to a different recipient domain to rule out recipient-side blocking
- Check if antivirus software intercepts SMTP traffic
Once you’ve fixed the relay issue, your emails will start sending — but landing in the inbox is a separate challenge. Running an email warmup helps rebuild sender reputation and generates positive engagement signals that improve deliverability over time.
Need help diagnosing the issue? Schedule a free consultation with our deliverability consultants. We’ll review your setup and identify what’s blocking your emails.
Frequently asked questions
Here are some commonly asked questions on this topic:
The first digit tells you everything. 554 (5xx) is a permanent rejection — the server won’t retry. 454 (4xx) is a temporary failure — the server will automatically retry delivery later. Permanent errors require you to fix something; temporary errors often resolve themselves.
No. Invalid recipients generate 550 errors (user unknown) or 553 5.1.3 (invalid address format). The 554 5.7.1 specifically indicates relay authorization failed — nothing to do with the recipient’s address.
Yes. POP before SMTP is a legacy authentication method that ties authorization to your IP address. When your IP changes (switching WiFi networks, using mobile data), POP-based relay breaks. SMTP authentication uses credentials instead, so it works regardless of where you’re connecting from.
Anywhere from a few minutes to 48 hours, depending on your DNS provider’s TTL settings and propagation speed. Most changes take effect within 1-4 hours. Flush your local DNS cache if you’re impatient.
“Nothing changed” usually means something changed without you realizing — your IP address shifted (common on home networks), your email provider updated security requirements, two-factor authentication was enabled and invalidated your old password, a software update reset your SMTP settings, or your mail server’s SSL certificate expired.
