ProbeKit
Sign inSign up

SMTP 553: mailbox name not allowed

553Requested action not taken: mailbox name not allowedPermanent: retrying will not help

Typical wording
553 5.7.1 <user@example.com>: Sender address rejected: not owned by user

What it means

RFC 5321 defines 553 as "Requested action not taken: mailbox name not allowed (e.g., mailbox syntax incorrect)". It can answer MAIL FROM or RCPT TO and says the address cannot be used here, either because it is malformed or because policy forbids it.

Common variants: 553 5.1.3 for a destination address with bad syntax, 553 5.1.8 for a sender domain the receiver will not accept, and 553 5.7.1 when a submission server refuses a MAIL FROM that the logged in user is not allowed to send as. Zoho returns 553 "Relaying disallowed" when a client sends through it without the right account. RFC 6531 also uses 553 for a non ASCII address sent without the SMTPUTF8 option.

It is permanent. Compare with 550, which is about the mailbox being unavailable, and 501, which reports syntax errors in command arguments more generally.

Likely causes

  • The application sets a From or envelope sender that the authenticated account does not own.
  • The address has invalid characters, a missing domain, or a trailing dot.
  • The client tries to relay mail through a server that does not accept relaying for it.
  • The address uses non ASCII characters and the client did not request SMTPUTF8, or the server lacks it.

How to fix it

  1. Check which command the 553 answered. On MAIL FROM, look at the sender; on RCPT TO, look at the recipient.
  2. Make the envelope sender match the account you log in with, or add the address as an allowed alias or send as permission.
  3. Correct address typos and remove spaces, quotes, or display names from the envelope addresses.
  4. If the text mentions relaying, authenticate on the submission port, or send through your own domain’s server instead.

Checks that apply

  • SMTP Diagnostics Shows whether the server advertises SMTPUTF8 and AUTH, two features behind many 553 refusals.
  • SPF Check Checks whether your domain’s SPF record authorises the server you send through, which some receivers enforce at MAIL FROM.
  • MX Lookup Confirms your sender domain has MX records, since some servers refuse sender domains that cannot receive replies.
See the example diagnosed

The classification runs without network lookups and we never store your paste.

FAQ

Why does my website’s mail get 553 from my host?
Usually the script sends with a From address the hosting account does not own; use an address on your own domain that you authenticate as.
Is 553 caused by the recipient?
Only when it answers RCPT TO with a syntax problem in their address. On MAIL FROM it is the sender’s setup.

All 191 bounce codes