Your inbox works fine. You can read every message that arrives. But the moment you try to reply from your home Wi-Fi, the message bounces back with SMTP error 550 and the words “relay not permitted.” It feels personal, but it is not — the server is simply refusing to carry mail it cannot verify is yours.
This error is one of the most common sending problems in home setups, and it usually has a simple cause: your email app is trying to send without properly logging in to the outgoing server. Here is how to find the real cause and fix it.
Quick Answer
Error 550 “relay not permitted” means the outgoing server refused to forward your message because it does not recognise you as an authorised sender. In your email app, turn on “My outgoing server requires authentication,” use your full email address and password, and send on port 587 with STARTTLS (or 465 with SSL/TLS). Also make sure the outgoing server name belongs to the same provider as your email address.
What “Relay Not Permitted” Actually Means
Relaying is the act of passing a message onward. When you send an email, your provider’s SMTP server receives it from your app and relays it to the recipient’s provider. Years ago, many servers relayed mail for anyone who asked. Spammers abused that openness so heavily that open relays are now considered a serious fault.
Today, a server will only relay your message if at least one of these is true:
- You logged in with the username and password for an account on that server.
- You are sending from a network the server trusts, such as the network of the internet provider that also runs the server.
Error 550 appears when neither is true. Your app connected, handed over a message for an outside address, and the server replied: you are not allowed to relay through me.
The Classic Home Wi-Fi Scenario
The most famous version of this problem goes like this. Your email account is with one company, but your home broadband is with another. Your email app is still set to send through your internet provider’s SMTP server — a setup that may have worked years ago when you were a customer, or that was configured by a setup wizard guessing values. From home, that server no longer accepts you, because you are not logged in and possibly not even its customer anymore.
A second version appears after changing broadband providers. Receiving still works because the incoming server is your email provider’s, but sending fails because the outgoing settings point at the old provider. A third version happens after a password change: incoming mail may keep working from a saved login while outgoing authentication silently fails.
Step-by-Step Fix
- Open your outgoing server settings. In Outlook this is File, Account Settings, Server Settings, Outgoing mail. In Apple Mail it is Settings, Accounts, then Server Settings. In Thunderbird it is Account Settings, Outgoing Server (SMTP).
- Check the server name. It should be your email provider’s SMTP server — for example, the server your provider lists for your domain — not your broadband company’s server unless your email address is also with that company.
- Turn on authentication. Enable the option that says the outgoing server requires authentication, and choose to use the same settings as the incoming server, or enter your full email address and password directly.
- Set the port and encryption as a matched pair: port 587 with STARTTLS, or port 465 with SSL/TLS.
- Confirm your username is your full email address. A partial username, such as just the part before the @ sign, is a frequent hidden cause of relay refusals.
- Save and send a test message to an address at a different provider, not just to yourself, because sending to your own domain may succeed even when relaying is still broken.
Microsoft’s guidance on the “relay not permitted” error in Outlook gives the same core advice: verify that you are sending through your own provider’s server with authentication enabled.
Check That You Are Not Using Port 25
If your outgoing port is set to 25, change it. Port 25 is meant for communication between servers. Home internet providers commonly block it or route it through filters, and receiving servers treat unauthenticated port 25 submissions with suspicion. Many 550 relay errors disappear the moment the app is moved to port 587 with authentication switched on. For background on choosing between the sending ports, see our comparison of SMTP ports 465 and 587 and IMAP ports 993 and 143.
Other Causes Worth Checking
Wrong “From” Address
If you are sending from an alias or a different domain than the account you logged in with, some servers refuse to relay. Make sure the From address matches the account whose password you used to authenticate, or use a provider that explicitly supports sending from your extra addresses.
Sending Through Your Web Host
Small business owners often send mail through their website hosting server. If the hosting account’s password changed, or the mailbox was deleted and recreated, outgoing authentication breaks. Log in to webmail for the domain to confirm the mailbox password works, then use that exact password in your app.
VPN and Public Networks
A VPN makes your connection appear to come from a different network and sometimes a different country. A small number of providers restrict relaying from unfamiliar locations. If the error only appears with the VPN on, test with it disconnected, then ask the provider about their policy.
Common Mistakes to Avoid
- Using your broadband provider’s SMTP server for another provider’s email address. This is the number one cause of this error.
- Assuming receiving settings prove sending should work. Incoming and outgoing authentication are separate; both must be correct.
- Testing by emailing yourself. Local delivery may succeed without relaying. Always test to an outside address.
- Re-typing the password from memory. Verify it first by signing in to webmail.
- Searching for a way to relay without logging in. Legitimate servers will not allow it; that restriction is what keeps your own address from being abused.
Conclusion
SMTP error 550 “relay not permitted” is a trust problem, not a mystery failure. The server wants proof that the message is really yours before it forwards it. Point your app at your own email provider’s outgoing server, switch on SMTP authentication with your full email address and current password, and use port 587 with STARTTLS or 465 with SSL/TLS. In the great majority of home Wi-Fi cases, those changes end the error immediately.
Frequently Asked Questions
Why can I receive email but not send it?
Receiving and sending use different servers with separate settings. Your incoming login can be perfectly fine while outgoing authentication is missing or pointed at the wrong server, which is exactly what produces a relay error.
Why did this error start when I changed internet providers?
Your old provider’s SMTP server may have accepted you because you were on its network. On the new provider’s network you are a stranger, so the old server refuses to relay. Switching to your email provider’s own SMTP server with authentication fixes it permanently.
Does error 550 mean my message was treated as spam?
Not usually. A 550 relay refusal happens before content is even considered — the server rejected the sending arrangement itself. Spam-related rejections normally mention policy, content, or blocklists in the message text.
Can this error affect only some recipients?
It can appear that way. Messages to addresses on your own provider’s system may be accepted as local delivery, while all outside addresses are refused. That pattern is a strong sign that relaying, not the recipients, is the problem.
What if I still get error 550 after fixing authentication?
Double-check the server name and that your mailbox still exists and is active. If everything matches your provider’s published settings, contact the provider — account-level sending blocks and full mailboxes on the server side can also produce 550 responses.


Leave a Reply