SMTP Error 533

Is "SMTP Error 533" a real SMTP code?

No. The SMTP reply-code grammar in RFC 5321 §4.2.3 does not define a 533 reply, and 533 is not a registered SMTP reply code. The permanent (5xx) codes listed in RFC 5321 §4.2.3 are 500, 501, 502, 503, 504, 550, 551, 552, 553, 554, and 555. (Two more 5xx codes, 521 and 556, were added later by RFC 7504; that RFC explicitly notes they were not previously part of standard SMTP.) None of those is 533. So if a tool reports "SMTP Error 533," it is almost always one of two things:

1. A misread of an enhanced status code 5.3.3 (the dotted three-part code from RFC 3463), accidentally written without the dots.
2. A vendor- or app-specific label that does not correspond to anything the receiving mail server actually sent.

Note that earlier versions of this page (and several third-party sites) claimed 533 means "the recipient server is out of disk space." That is not accurate — there is no standard 533 code, and disk/storage problems are reported by other codes (see below).

What does enhanced status code 5.3.3 mean?

If your bounce or log actually contains 5.3.3, RFC 3463 §3.4 defines it precisely:

X.3.3 System not capable of selected features — "Selected features specified for the message are not supported by the destination system. This can occur in gateways when features from one domain cannot be mapped onto the supported feature in another."

In plain terms: the receiving system rejected the message because it asked for an SMTP extension or feature (for example an 8BITMIME, SMTPUTF8, DSN, SIZE, or BINARYMIME capability, or a gateway-specific feature) that the destination cannot honor. The leading 5 means it is a permanent failure — resending the message unchanged will not help.

How do I fix a 5.3.3 / "533" rejection?

1. Capture the full server reply. Don't act on the bare number — read the entire line your client logged. It contains both the 3-digit reply code and often the dotted enhanced code plus human-readable text (e.g. 550 5.3.3 Feature not supported). That text is what tells you the real cause.
2. If it's truly 5.3.3: Stop requesting the unsupported extension. Check the EHLO response from the destination to see which extensions it advertises, then disable the offending option in your client/library (for example, turn off SMTPUTF8/8BITMIME, or send 7-bit/quoted-printable content) and retry.
3. If the text mentions storage or "mailbox full": This is a different code. A temporary shortage is 452 ("Requested action not taken: insufficient system storage", per RFC 5321) — retry later. A permanent over-quota mailbox is 552 ("Requested mail action aborted: exceeded storage allocation"). Neither is "533."
4. If the text mentions the recipient address, relaying, or policy: Look for 550 (no such user), 553 (mailbox name not allowed), or 554 (transaction failed / policy) — verify and correct the recipient address rather than treating it as a feature error.
5. If you can't find any matching code, the "533" label came from your sending application, not the receiving server. Check that integration's documentation for its own numbering.