SMTP response received
454 4.7.1 Relay Access Denied: Causes, Solutions, and How to Fix ItYou received this code because your outbound SMTP server refused to forward the message. This is a sender-side infrastructure problem, not a recipient issue. Almost always caused by missing SMTP AUTH, the wrong outbound server, an IP not on the relay allowlist, or a domain not in Accepted Domains (Exchange). Fixable in minutes once you identify which.
๐ In this guide
๐ค Who sees this code
- Developer configuring transactional email in an application
- Sysadmin setting up Postfix, Exim, or Exchange relay
- Team migrating to a new outbound SMTP provider
๐ง What this guide fixes
- Distinguish sender-side relay-denied from receiver-side rejection
- Correct SMTP AUTH, port, TLS, or Accepted Domains configuration
- Provider-specific fixes for Postfix, Exchange, Sendmail, and modern ESPs
๐ The 4.7.x transient security family
421 4.7.0Transient policy ยท often greylisting
421 4.7.1Delivery not authorized ยท retry-able
421 4.7.28IP rate limited ยท transient
550 5.7.1Permanent version ยท 5.7.1
โก Do these 3 things first (before diving deeper)
Confirm SMTP AUTH is enabled and credentials are valid
Most relay refusals happen because the client is not authenticating before RCPT TO. Confirm SMTP AUTH is turned on in your library config, the username matches an active account, and the password is current. Test manually with openssl s_client or swaks. If AUTH fails at handshake, relaying will always be denied regardless of other config.
Verify the outbound SMTP server hostname is correct
Your app might be pointing at an MX server (used for receiving) or an old provider hostname that has since changed. Confirm the outbound hostname matches what your CURRENT provider documents. Public MX records do not accept outbound relay from applications. Providers occasionally deprecate old outbound hostnames without loud warning.
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 compatibility. Port 25 is server-to-server relay only and typically refuses AUTH. If your app is on port 25 and getting 454 4.7.1, switch to 587 with STARTTLS.
Common causes of 454 4.7.1
- SMTP authentication not enabled in the sending application. The single most common cause. Your application 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. Enable SMTP AUTH in your library configuration and provide valid credentials.
- Connecting to the wrong outbound SMTP server. Some setups mistakenly point outbound SMTP at an MX server or a public relay that is not authorized for your traffic. Confirm you are connecting to the outbound submission server documented by your current email provider (smtp.gmail.com, smtp.office365.com, smtp.sendgrid.net, etc.). Using an MX server as an outbound relay is a persistent misconfiguration.
- 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 equivalent trusted-host configurations. If your application server sends unauthenticated from a new IP that was never allowlisted, the relay rejects with 454 4.7.1. This surfaces after infrastructure moves or firewall changes.
- Expired or rotated SMTP credentials. Passwords rotate. API keys expire. Service accounts get disabled during quarterly access reviews. Your application keeps sending with stale credentials, gets 454 4.7.1 as the relay refuses the AUTH handshake, and you spend an hour debugging routing before checking credentials. Verify credentials first: it takes seconds and eliminates the most common trivial cause.
- Sending domain not in Accepted Domains (Exchange). For self-hosted Exchange or hybrid Microsoft 365, mail can only be relayed for domains explicitly listed in Accepted Domains. If your organization added a new subdomain or acquired a domain without updating Exchange, sends from that domain hit 454 4.7.1 or 550 5.7.54. Add the domain via Exchange Admin Center or PowerShell.
How to fix 454 4.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 flag: pass a username and password to the constructor and set secure to true for TLS. For custom code, implement the AUTH LOGIN exchange after EHLO. Add SMTP debug logging temporarily to confirm AUTH commands appear before MAIL FROM in the wire trace.
- 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. Port 465 with implicit TLS is a legacy alternative some providers still support. Port 25 is for server-to-server relay and most modern ISPs block outbound port 25 entirely.
- Verify credentials directly against the relay before touching app code. Prove credentials work by connecting manually with openssl s_client -starttls smtp -connect smtp.example.com:587 or swaks. Run the AUTH LOGIN handshake with your username and password. If manual fails, the credentials are the problem: reset password or regenerate the API key. If manual works but 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. For Exim, update hosts_allow_relay. For self-hosted Exchange, add the IP to the receive connector Remote Network Settings. Only allowlist IPs you fully control and trust: allowlisting shared or dynamic IPs turns your server into an open relay.
- Update the outbound hostname if you migrated providers. Configurations drift after ESP or domain migrations. Confirm the outbound hostname matches your current provider documentation, not tribal knowledge from years ago. Providers deprecate old hostnames without prominent warning. If your app has been sending for years unchanged, the hostname might have been quietly retired.
- Consider switching to a dedicated SMTP relay service. Managed services (SendGrid, Mailgun, Amazon SES, Postmark) handle relay configuration, authentication, ports, and TLS entirely. You call the API or SMTP endpoint with a key, they handle everything downstream. This eliminates the whole class of 454 4.7.1 errors caused by self-hosted misconfiguration, typically at costs below the developer time to maintain 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.
- Rotate SMTP credentials on a schedule you control, not on emergency. Sudden rotation across dozens of apps causes 454 4.7.1 storms because updates lag deployments.
- Prefer authenticated ESP submissions over self-hosted relay wherever operationally viable. Managed services handle the entire class of relay-configuration complexity that produces 454 4.7.1.
- Test outbound sends immediately after any infrastructure change. A new container image, a firewall rule, or a security patch can shift outbound behavior in ways that only surface as 454 4.7.1 the next time your app tries to send.
- Monitor authentication failure rates on your relay server. A spike in AUTH failures precedes 454 4.7.1 storms by minutes to hours, giving you time to fix credentials or config before customers notice missing emails.
Frequently asked questions about 454 4.7.1
Is this relay-denied 454 4.7.1 the same as the 454 4.7.1 from Gmail or Outlook?
Why do I need SMTP AUTH now when my app worked without it before?
Should I use port 25, 465, or 587?
Can I fix relaying denied without changing my code?
What is the difference between "relaying denied" and "recipient address rejected"?
Should I switch to a dedicated SMTP service?
Stop 454 4.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.7.1Relaying deniedSender-side SMTP AUTH failure โ fix your outbound config
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
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.
