SMTP response received
550 5.7.1 <user@domain>: Relay access deniedYou received this code because your outbound SMTP server refused to forward the message. This is sender-side โ a problem with your own relay configuration, not with the recipient. Almost always caused by missing SMTP AUTH, the wrong outbound server, or an IP not on the relay allowlist. Fixable in minutes once identified.
๐ In this guide
๐ค Who sees this code
- Developer configuring transactional email in an app
- Sysadmin setting up Postfix or Exchange relay
- Team migrating to a new outbound SMTP provider
๐ง What this guide fixes
- Distinguish sender-side relay-denied from receiver-side 5.7.1
- Correct SMTP AUTH, port, and TLS configuration
- Provider-specific fixes for Postfix, Exchange, Sendmail
๐ The 5.7.x security and policy family
550 5.7.1READINGDelivery not authorized ยท policy or auth failure
550 5.7.9Message content not supported by policy
550 5.7.26Multiple authentication failures
421 4.7.0Transient policy ยท often greylisting
โก Do these 3 things first (before diving deeper)
Confirm SMTP AUTH is enabled and credentials are valid
Most 550 5.7.1 relaying denied errors happen because the client is not authenticating before RCPT TO. Open your mail library or application configuration and confirm SMTP AUTH is turned on, that the username matches an active account on the relay server, and that the password is current. Test with a smtplib.SMTP call in Python, telnet AUTH LOGIN, or your ESP outbound test tool. If authentication fails at handshake, relaying will always be denied and no amount of subsequent config changes will fix the underlying credential problem.
Verify you are connecting to the correct SMTP relay server
550 5.7.1 also appears when your app is trying to send through an SMTP server that is not authorized to relay for your domain. This happens after DNS migrations, provider changes, or accidental use of a public MX server as an outbound relay. Confirm the SMTP host in your config matches the outbound submission server documented by your provider (smtp.gmail.com, smtp.office365.com, smtp.sendgrid.net, etc.). Using a receiving-only MX server as an outbound relay is one of the most common misconfigurations.
Check the port and TLS mode you are connecting on
Modern SMTP relays require port 587 with STARTTLS for authenticated submission, or port 465 with implicit TLS for legacy configurations. Port 25 is reserved for server-to-server relay and typically does not accept AUTH from client applications. Many relays reject AUTH attempts on port 25 with 550 5.7.1 relaying denied. If your app is connecting on port 25 to send authenticated mail, switch it to 587 with STARTTLS and retry.
Common causes of 550 5.7.1
- SMTP authentication not enabled in your application. The single most common cause. Your mail client, transactional service, or custom code is trying to relay through an authenticated SMTP server without providing AUTH credentials. Modern relays never allow unauthenticated relay by default because open relays get instantly abused for spam. This affects everything from misconfigured smtplib scripts to legacy applications ported from environments that historically allowed open relay. The fix is always to enable SMTP AUTH and provide valid credentials in the connection.
- Connecting to the wrong outbound SMTP server. Some setups mistakenly point their outbound SMTP at a MX server (used for receiving mail) or at a generic public relay. These servers reject relay attempts with 550 5.7.1 because they are not configured to accept your outbound traffic. Confirm you are connecting to the outbound submission server documented by your email provider. Public MX records are for INCOMING mail: they do not accept outbound relay from client applications even with valid credentials.
- Sending IP not in the relay allowlist. For self-hosted Postfix, Exim, or Sendmail, unauthenticated relay is permitted only for IPs listed in mynetworks (Postfix) or the equivalent trusted-host configuration. If your application server is sending unauthenticated from a new IP that was never added to the trusted list, the relay rejects with 550 5.7.1. This surfaces after infrastructure moves, container restarts on new IPs, or firewall changes that shift outbound routing to a different source address.
- Expired or rotated SMTP credentials. Passwords rotate on schedules. API keys expire. Service accounts get disabled during quarterly access reviews. Your application keeps sending with credentials it was configured with, gets 550 5.7.1 as the relay refuses the AUTH handshake, and your team spends an hour debugging routing before checking the credentials themselves. Always verify credentials before deeper investigation: a fresh authentication test takes seconds and eliminates the most common trivial cause.
- Sending domain not in Accepted Domains (Exchange). For self-hosted Exchange or hybrid Microsoft 365 setups, mail can only be relayed for domains explicitly listed in Accepted Domains. If your organization added a new subdomain or acquired a new company domain without updating Exchange configuration, sends from that domain hit 550 5.7.1 or the closely related 550 5.7.54 (unable to relay in non-accepted domain). The fix is to add the domain to Accepted Domains via Exchange Admin Center or PowerShell before retrying.
How to fix 550 5.7.1, step by step
- Enable SMTP authentication in your sending application. In most mail libraries (nodemailer, smtplib, PHPMailer, Mail::Sender), SMTP AUTH is a simple config flag: pass a username and password to the constructor and set secure to true for TLS. For custom code using raw sockets, implement the AUTH LOGIN or AUTH PLAIN exchange after EHLO. If you are unsure whether AUTH is happening, add SMTP debug logging temporarily and observe the wire: you should see AUTH commands before MAIL FROM. Missing AUTH commands are the smoking gun.
- Use port 587 with STARTTLS as your submission port. Port 587 is the RFC 6409 designated submission port for authenticated SMTP. Configure your app to connect on 587, negotiate STARTTLS, then authenticate, then send. Port 465 with implicit TLS is a legacy alternative that some providers still support (Gmail Workspace, for instance). Port 25 is for server-to-server relay only and should never be used for authenticated submission from applications. Most modern ISPs also block outbound port 25 for residential and non-mail-server networks.
- Verify your credentials against the relay server directly. Before touching your app code, prove the credentials work by connecting manually. Using openssl s_client -starttls smtp -connect smtp.example.com:587, or a tool like swaks, run the AUTH LOGIN handshake with your username and password. If the manual test also fails, the credentials are the problem: reset the password, generate a new API key, or check that the account is not disabled. If manual works but the app fails, your app config or library is misconfigured.
- Add your sending IP to the relay allowlist (self-hosted only). For Postfix, add the IP to mynetworks in main.cf and reload postfix. For Exim, update hosts_allow_relay. For self-hosted Exchange, add the IP to the receive connector Remote Network Settings. After the change, reload the mail service and retry the send. Only allowlist IPs you fully control and trust: allowlisting shared or dynamic IPs turns your server into an open relay that will be abused for spam within hours of discovery.
- Update the outbound server hostname if you migrated providers. Common configurations drift out of alignment after ESP changes or domain migrations. Confirm the outbound hostname in your app matches what your CURRENT provider documents, not tribal knowledge or an outdated wiki page. Providers occasionally deprecate old outbound hostnames without prominent warning. If your app has been sending for years without change, the hostname it uses might have been quietly retired and you are hitting a legacy endpoint that no longer accepts your credentials.
- Consider switching to a dedicated SMTP relay service. For applications that need reliable outbound delivery without infrastructure management, dedicated services (SendGrid, Mailgun, Amazon SES, Postmark) handle relay configuration, authentication, port setup, and TLS entirely. You call their API or SMTP endpoint with an API key, they handle everything downstream. This eliminates the whole category of 550 5.7.1 relaying-denied errors caused by self-hosted misconfiguration, and typically costs less than the developer time spent maintaining your own relay.
๐ How each provider sends this exact code
โ How this code differs from adjacent ones
554 5.7.1454 4.7.1550 5.7.54Prevention going forward
Once relaying-denied is fixed, keep it fixed with configuration discipline that catches drift before it produces outbound outages.
- Document your outbound SMTP configuration in one authoritative place. When credentials rotate or provider settings change, apps break silently unless a single source of truth tells every service what to use. A wiki page, a config manager entry, or a secret store with clear naming beats tribal knowledge.
- Rotate SMTP credentials on a schedule you control, not on emergency. Sudden rotation across dozens of apps causes 550 5.7.1 storms because updates lag deployments. Predictable rotation windows with staged rollouts eliminate the panic-fix pattern.
- Prefer authenticated ESP submissions over self-hosted relay wherever operationally viable. Managed services handle the entire class of relay-configuration complexity that produces 550 5.7.1, at costs that typically undercut the labor to maintain your own relay.
- Test outbound sends immediately after any infrastructure change. A new container image, a firewall rule update, or a security patch can shift outbound behavior in ways that only surface as 550 5.7.1 when the app next tries to send, often hours later.
- Monitor authentication failure rates on your relay server. A spike in AUTH failures precedes 550 5.7.1 storms by minutes to hours, and gives you time to fix credentials or config before customers notice missing emails.
Frequently asked questions about 550 5.7.1
Is 550 5.7.1 relaying denied the same as the 550 5.7.1 I see from Gmail or Outlook?
Why do I need SMTP AUTH? My app sent fine last week without it.
Should I use port 25, 465, or 587?
Can I fix relaying denied without changing my sending code?
What is the difference between "relaying denied" and "recipient address rejected"?
Should I switch to a dedicated SMTP service like SendGrid or Postmark?
Stop 550 5.7.1 bounces before they happen.
SMTPing catches invalid addresses, disposables, catch-all traps, role accounts and dead mailboxes before you send. Fewer bounces means less firefighting and a healthier sender reputation. 13 validation types, 25 free daily, no card required.
๐ Deep dive on related codes
550 5.4.1Office 365 tenant policyRecipient address rejected at Microsoft โ auth or reputation cause
550 5.1.1User unknownRecipient address does not exist โ suppress immediately
550 5.7.1Blocked by SpamhausSpamhaus SBL/PBL/CSS/XBL delisting playbook
550 5.2.1Gmail inactive account2-year inactivity policy and suppression strategy
About the Author

Alaa ยท LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. Iโve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.

