SMTP error 553, what it means and what to do
RFC 5321 defines 553 as "Requested action not taken: mailbox name not allowed", and its two living uses are easy to separate by the accompanying text. The first is literal: the address itself is malformed or contains characters the server will not accept as a mailbox name (enhanced code 5.1.3, bad destination mailbox address syntax). The second is policy wearing this number: the server refuses the sender's address or domain, often worded as relaying or sender verification failures. One is fixed in the address book; the other in the sending configuration or DNS.
The fix, in order
- Inspect the recipient address character by character. Look for spaces, doubled dots, a missing @, illegal characters from a copy-paste (smart quotes and non-breaking spaces sneak in from documents), and a trailing period. Most 5.1.3 errors are one wrong character in an otherwise familiar address.
- Re-type rather than reuse. Delete the address from the To field and type it fresh instead of choosing the autocomplete entry. Mail clients cache broken addresses in their suggestion lists and faithfully re-offer the same bad string for months.
- Check whether the refusal names the sender instead. Texts such as "553 sorry, that domain isn't in my list of allowed rcpthosts" or sender verification failures are about the From side: the sending server is not authorized to submit for that domain. That is a relay and configuration matter, fixed by sending through the provider's authenticated submission service on port 587.
- If sending as a different identity (Send As, aliases, scripts): the server may refuse a From address it does not recognize as the account's own. Configure the alias properly in the provider's settings, or send from the address the account actually owns; servers reject invented From domains with 553 as an anti-spoofing measure.
- If you run the server: confirm the refused domain's status in your relay and local-domain tables. A domain removed from the local list during a migration makes its own users' mail fail with 553, which matches the classic rcpthosts wording exactly.
- Validate list data before big sends. Imported contact lists carry the malformed addresses that produce 553 in bulk. A validation pass on the list finds the syntax failures before the mail server has to.
If it still happens
553 is permanent for the message as addressed or as configured; nothing about waiting changes it. Its ownership is clean once the text is read: syntax problems belong to whoever maintains the address, sender-authorization problems belong to whoever configures the sending account or server.
Common questions
Is 553 the same as 550 user unknown? No. 550 5.1.1 means the address is well-formed but no mailbox exists there. 553 5.1.3 means the address itself is not acceptable as written, before existence is even checked. One is a wrong name for a real place; the other is not a valid name at all.
Why does 553 mention relaying on some servers? Some long-lived mail servers (qmail historically, and systems copying its wording) use 553 for refusing mail from domains they will not relay for. The text mentions rcpthosts or relaying in those cases, which is the signal that it is the sender-authorization variant.
Related errors