SMTP Error 531

Is "SMTP Error 531" a real SMTP error?

No. There is no reply code 531 in the SMTP standard. RFC 5321 §4.2.3 enumerates the valid three-digit reply codes, and 531 is not among them — the curated list of SMTP return codes jumps from 530 to 534/535/538 to 550 with no 531. So if you see "531" in a log, monitoring dashboard, or a third-party article, it is almost always a relabeling of something else.

The "531" name gets attached to two unrelated real things, which is why you'll find blogs that confidently call it a "mailbox full" error and others that call it an "authentication required" error. Both are guessing. Don't act on the label "531" — act on the actual code your server returned.

What "531" usually maps to

There are two real, RFC-defined things people mislabel as 531:

1. Enhanced status code 4.3.1 — "Mail system full." Defined in RFC 3463 §3.4: "Mail system storage has been exceeded... This is useful only as a persistent transient error." RFC 3463 restricts X.3.1 to the persistent-transient class only — there is no RFC-sanctioned permanent (5.3.1) form. A bounce showing "5.3.1" is itself non-standard relative to RFC 3463; the code the RFC actually defines is 4.3.1 (try again later). Its matching basic reply code is 552 — RFC 5321 defines 552 Requested mail action aborted: exceeded storage allocation.

2. An authentication failure. Some tools tie "531" to "the server requires authentication." The real codes here are 530 5.7.0 Authentication required and 535 5.7.8 Authentication credentials invalid, both from RFC 4954 — not 531.

How do I fix it?

Step 1 — Read the full bounce/log line. Find the actual three-digit reply code and, if present, the X.Y.Z enhanced status code. That string ("552 4.3.1 ...", "530 5.7.0 ...", "535 5.7.8 ...") tells you which problem you actually have. In Courier, open the message in the Logs and inspect the provider response verbatim rather than trusting a normalized "531" label.

Step 2 — If it's storage (552 / 4.3.1 / 4.2.2): the recipient mailbox is over quota. This is the destination's problem, not yours. The recipient must free space or raise their quota; you can retry later. If you control the receiving server, increase the mailbox/storage limit. (4.2.2 "Mailbox full" (RFC 3463) is a related per-mailbox variant — also documented only as a persistent-transient code, not a permanent 5.x.x failure.)

Step 3 — If it's authentication (530 / 535): fix the SMTP credentials on the sending side. Use a valid username/password or API key, AUTH after STARTTLS on port 587 or implicit TLS on 465 (both valid per RFC 8314). For Gmail/Google Workspace, use an App Password (with 2-Step Verification) or OAuth2 — Google removed "Less Secure Apps" access in 2022, so that toggle is gone.

Step 4 — Stop normalizing to fake codes. If your own code or alerting emits "531," update it to log the raw reply code and enhanced status code so the next person can act on a real RFC code.

Why the old "mailbox full, contact their server" advice is only half right

That advice describes 4.3.1/552 and is fine for that case — but only after you've confirmed the bounce is actually a storage failure. Applied blindly to anything labeled "531," it sends you chasing the recipient's admin when your real problem might be a missing SMTP password.