TL;DR: An SMTP error (553 5.7.1) occurred because the receiving server refused the address supplied in the MAIL FROM or RCPT TO command. This means the message will not be retried and will stay undelivered until the issue is resolved and the message is sent again. One code covers five different bounce messages, and the words after the number indicate which one you have. Possible reasons for the error include a relay attempt without authentication, a From address that the logged-in account does not own, a sender domain that fails to resolve in DNS, a mailbox for which you lack Send As rights, or a client that never authenticated at all.
SMTP error 553 5.7.1 is a permanent rejection. The receiving server refused the address you supplied in MAIL FROM or RCPT TO, either because the address is malformed or because you are not authorized to send from it. Read the text after the code, fix the cause it names, then send again.
That last step matters. Because 553 is a 5xx reply, nothing retries it for you. A temporary failure sits in a queue and clears itself; a 553 does not. Every message that hits this code is a contact your sequence never reaches until someone fixes the configuration and resends by hand.
What does SMTP error 553 5.7.1 mean?
RFC 5321 defines 553 as “Requested action not taken: mailbox name not allowed.” Your server returns it in response to the MAIL FROM or RCPT TO command, so the rejection lands during the SMTP conversation, before the message body is transmitted. Each digit carries meaning.
| Digit | Value | What it tells you |
|---|---|---|
| First | 5 Permanent negative | The command failed for good. Resending it unchanged produces the same reply. |
| Second | 5 Mail system | The problem is the mail system, not the connection or the session syntax. |
| Third | 3 Specific condition | Narrows it to the mailbox name in the envelope. |
The three-part number that follows, 5.7.1, is an enhanced status code from RFC 3463, where the 7 marks a security and policy failure. That is the whole diagnosis: the address is usually fine, and the permission is not. If SMTP itself is unfamiliar territory, the guide to what SMTP is and how an SMTP server works covers the conversation these codes belong to.
The five “sender address rejected” messages and what each one means
One code, five very different problems. The wording after 553 5.7.1 is the real diagnostic, so find your exact string before changing a single setting.
| Bounce message | What the server means | Where to fix it |
|---|---|---|
| 553 5.7.1 we don’t relay mails | You asked the server to deliver to a domain it does not handle, without authenticating. | Your client, by turning on SMTP authentication |
| 553 5.7.1 Sender address rejected: not owned by user | You authenticated as one account and sent as a different address. | Your client, by matching the From address to the login |
| 553 5.7.1 Sender address rejected: domain not found | The domain in your envelope sender does not resolve in DNS. | Your DNS records |
| 553 5.7.1 Sender address rejected: access denied | Authenticated, but the mailbox policy will not let you send as that address. | The mail server or tenant permissions |
| 553 5.7.1 Sender address rejected: not logged in | The server offered authentication; your client never completed it. | Your client credentials |
553 5.7.1 we don’t relay mails
Relaying means asking a mail server to forward a message to a domain it does not host. Servers do that only for senders they trust, and the way to earn that trust is to log in. A client that submits without authenticating gives the server no reason to carry its mail, so it refuses.
Three causes account for nearly all of it: the client points at port 25 instead of the submission port, authentication is off in the outgoing server settings, or the client submits before the login completes. Other servers word it as 553 Relaying disallowed, and Microsoft covers the behavior in its guidance on 550, 553, and relay-prohibited errors. Warmy’s walkthrough of the related 550 error asking you to turn on SMTP authentication shows the setting from the client side.
Sender address rejected: Not owned by user
This is the most common version, and it has a precise cause. On Postfix, the restriction reject_sender_login_mismatch rejects a message when the client is logged in through SASL but the login name does not own the MAIL FROM address according to the smtpd_sender_login_maps lookup table. In plain terms: you signed in as one person and tried to send as another.
A Postfix log entry looks like this, where the address at the end is the login the server expected:
553 5.7.1 <sales@example.com>: Sender address rejected: not owned by user marketing@example.com
Check three things: whether the From address matches the account you authenticated with, whether the alias is actually mapped to that login on the server, and whether your client sends a username where the server expects a full email address.
Sender address rejected: Domain not found
Here the permission is fine and the DNS is not. The server took the domain from your envelope sender, looked for a resolvable A or MX record, and found nothing. New domains hit this during propagation, older ones after a record is edited or moved. Confirm the domain resolves before changing anything else. The Gmail variant, 553 5.1.2 We weren’t able to find the recipient domain, is the same problem on the recipient side.
Sender address rejected: Access denied
You authenticated successfully and the server still refused the sender address. On Exchange and Microsoft 365 this means the account lacks Send As permission for the mailbox, which happens whenever someone is added to a shared mailbox or distribution list without send rights. You cannot fix it from the client, so send your administrator the full bounce text.
Sender address rejected: Not logged in
The server advertised authentication, your client skipped it, and the server refused anonymous mail. Check the outgoing server settings rather than the incoming ones, because clients often authenticate correctly for receiving and not for sending.
Not sure whether the problem is authentication or reputation? Warmy’s free email deliverability test checks your SPF, DKIM, and DMARC records, scans your domain and IP against major blocklists, and shows where your messages land across Gmail, Outlook, and Yahoo.
How to fix 553 5.7.1 in Gmail, Outlook, and Yahoo
SMTP settings overview
Every provider needs the same four values: a server address, a port, an encryption method, and a credential. Set the port and encryption together, because they are paired.
- Port 587 opens as plain text and upgrades with STARTTLS before authentication. This is the modern default for submission.
- Port 465 encrypts from the first byte, called implicit TLS. It is not a deprecated legacy option: RFC 8314 restored it as a standard for submission.
- Port 25 is for server-to-server transfer. Pointing a mail client at it reliably produces a relay rejection.
Gmail and Google Workspace
This is the part that changed. Older guides tell you to enable “less secure apps” in your Google account. That setting no longer exists. Per Google’s own documentation on the transition from less secure apps to OAuth, access was turned off for all Google Accounts on March 14, 2025, and SMTP, IMAP, and POP stopped working with a plain account password that day. Any guide pointing you at that switch cannot solve your problem.
- Set the server and port. Use smtp.gmail.com on port 587 with STARTTLS, or port 465 with implicit TLS.
- Choose the right credential. OAuth 2.0 over SASL XOAUTH2 is what Google intends you to use. For clients that cannot support it, generate a 16-character app password, which requires 2-Step Verification first. Google’s page on signing in with app passwords calls these an exception path rather than the recommended one.
- Use the full address as the username, not the local part and not a display name.
- Match the From address to the account. To send as an alias, add and verify it in Gmail first.
Outlook.com and Microsoft 365
Two different services, two different endpoints. Mixing them up produces rejections that look like credential errors.
| Account type | SMTP server | Notes |
|---|---|---|
| Personal Outlook.com, Hotmail, Live | smtp-mail.outlook.com, port 587, STARTTLS | Microsoft has moved third-party clients on personal accounts away from plain username and password sign-in. Connect with a client that supports modern authentication. |
| Microsoft 365, Exchange Online | smtp.office365.com, port 587, STARTTLS | Basic authentication for client submission is being retired in favor of OAuth. Once disabled on a tenant, clients receive 550 5.7.30 rather than 553. |
Microsoft has revised the retirement timeline for basic authentication on SMTP AUTH client submission more than once, so check the current dates in its Exchange Online announcement rather than trusting a date in any third-party article, including this one. Either way, if your device or script authenticates with a stored password, plan the move to OAuth now.
Inside the client, confirm that the outgoing server requires authentication. In Outlook that sits under Account Settings, then More Settings, then the Outgoing Server tab, separate from the credentials you entered when you added the account.
Yahoo Mail
Yahoo publishes its settings in the Yahoo Mail server settings documentation: the outgoing server is smtp.mail.yahoo.com on port 465 or 587, with SSL and authentication both required. The credential is the piece people get wrong: Yahoo expects a generated app password, so a login that works in the web interface still fails in a mail client.
General troubleshooting checklist
Work these in order, because settings and credentials are yours to fix in minutes while reputation problems survive a clean configuration.
- Read the bounce text, not just the number. The words after 553 5.7.1 identify which of the five cases you are in.
- Confirm the From address matches the authenticated account. This single check resolves most cases.
- Verify the sender domain resolves. Check the A and MX records for the domain in your envelope sender.
- Check your IP against blocklists. A listing produces rejections that no credential fix will clear.
- Re-type the address by hand. Addresses pasted from a spreadsheet or CRM field can carry a zero-width or non-breaking space, which is enough to make a valid address unparseable.
- Pass the bare address in the envelope. A display name belongs in the To header. Sending “Jane Doe” <jane@example.com> where the protocol expects jane@example.com can trigger the error.
553 vs 550 vs 554: Which rejection are you actually seeing?
These three codes get used interchangeably in bug reports and almost never mean the same thing. All are permanent, and the correct fix differs for each.
| Code | What it means | Typical cause and where to read more |
|---|---|---|
| 553 | Mailbox name not allowed | The address in the envelope was refused, usually because you are not authorized to send from it. |
| 550 5.7.1 | Policy or reputation block | The recipient server accepted the address and rejected the message. See the 550 5.7.1 guide. |
| 554 5.7.1 | Transaction failed | The most generic permanent rejection, usually relay or content. See the 554 5.7.1 guide. |
| 553 (other variants) | Same code, different suffix | Suffixes like 5.1.2 and 5.3.0 point at the address, not the policy. The general 553 troubleshooting article covers the wider family. |
When teams bring a 553 5.7.1 that survives every settings change, the cause is almost always an alias. Someone adds sales@ or hello@ to a client and assumes the mail server knows about it because the address exists in the company directory. The server does not care about the directory.
It checks whether the authenticated login is mapped to that sender, and if the mapping was never created, the rejection repeats no matter how often you re-enter the password. Ask your administrator to confirm the alias is mapped, not just that it exists.
How to stop 553 5.7.1 from happening again
Correct settings stop the rejection. They do not get the message into an inbox, and the two problems are easy to confuse because both end with mail that never arrives. Once authentication is clean, placement comes down to how much the receiving server trusts your domain.
Warmy is an AI-driven email warm-up platform that builds that trust before you send at volume. Adeline AI, Warmy’s proprietary engine, creates a personalized schedule for each mailbox and raises volume gradually while generating real engagement signals across a network of live mailboxes: opens, replies, clicks, and messages pulled back out of spam.
- Authenticate the domain. Build a correctly structured record with the SPF record generator, which keeps you under the ten-lookup limit, then set your policy with the DMARC record generator.
- Check content before it goes out. The template checker scans your subject line and body for spam triggers and returns a score with specific fixes.
- Monitor placement over time. Deliverability degrades gradually, so deliverability insights give you the trend rather than one snapshot.
See how automated email warm-up behaves on your own domain. Book a demo and see how Warmy keeps your sender reputation strong enough that authentication problems stay the only thing standing between your emails and the inbox.
