SMTP error 531
Not a real code — usually mail-system-full (4.3.1 / 552) or an auth failure.
Updated Jul 1, 2026
SMTP 531 is not a standard SMTP reply code. RFC 5321 section 4.2.3 defines no 531. The label usually conflates two real things: enhanced status 4.3.1 "mail system full" (RFC 3463, persistent-transient only) and basic reply code 552 "exceeded storage allocation" (RFC 5321). To fix it, read the full bounce, confirm the actual 3-digit code and X.Y.Z status, and act on that.
Read the raw code: free space or retry for storage, or fix credentials for auth.
What it means
There is no 531 reply code in SMTP. RFC 5321 section 4.2.3 enumerates the valid three-digit codes, and 531 is not among them: the curated list jumps from 530 to 534, 535, 538, then 550, with no 531. So a "531" in a log, dashboard, or third-party article is almost always a relabeling of something else. The name gets attached to two unrelated real things, which is why some blogs call it "mailbox full" and others call it "authentication required". Both are guessing. Do not act on the label. Act on the actual code your server returned.
Common causes
Defined in RFC 3463 section 3.4 as mail system storage exceeded, useful only as a persistent transient error. The RFC restricts X.3.1 to the persistent-transient class, so there is no RFC-sanctioned permanent 5.3.1 form; a bounce showing 5.3.1 is itself non-standard. Its matching basic reply code is 552, which RFC 5321 defines as "requested mail action aborted: exceeded storage allocation".
Some tools tie "531" to "the server requires authentication". The real codes there are 530 5.7.0 (authentication required) and 535 5.7.8 (authentication credentials invalid), both from RFC 4954, not 531.
How to fix it
- Read the full bounce or log line
Find the actual three-digit reply code and, if present, the X.Y.Z enhanced status. A string like "552 4.3.1 ...", "530 5.7.0 ...", or "535 5.7.8 ..." tells you which problem you have. In Courier, open the message in Logs and inspect the provider response verbatim rather than trusting a normalized "531" label.
- If it is storage (552, 4.3.1, or 4.2.2)
The recipient mailbox is over quota, which is the destination side, not yours. The recipient must free space or raise the quota, and you can retry later. If you control the receiving server, increase the mailbox or storage limit. 4.2.2 ("mailbox full") is a related per-mailbox variant, also documented only as persistent-transient.
- If it is authentication (530 or 535)
Fix the SMTP credentials on the sending side. Use a valid username and password or API key, run AUTH after STARTTLS on port 587 or implicit TLS on 465 (both valid per RFC 8314). For Gmail or Google Workspace, use an App Password with 2-Step Verification or OAuth2, since Google removed Less Secure Apps in 2022.
- Stop normalizing to fake codes
If your own code or alerting emits "531", update it to log the raw reply code and enhanced status so the next person can act on a real RFC code.
Common questions
Is SMTP error 531 a real SMTP reply code?
No. RFC 5321 section 4.2.3 lists the valid three-digit codes and 531 is not one of them. It is typically a mislabeling of enhanced status 4.3.1 "mail system full" (RFC 3463; sometimes written non-standardly as 5.3.1), whose matching basic reply code is 552, or occasionally of an authentication failure (530 or 535, RFC 4954).
Does 531 mean the recipient mailbox is full?
Only if the real code behind it is a storage failure such as 552 with 4.3.1 or 4.2.2. Confirm that from the bounce text before treating it as a quota problem, since "531" is also used to mislabel authentication failures.
What should I do when I see "531" in my mail logs?
Ignore the label and read the raw three-digit code and enhanced status. Storage failures are the recipient side to resolve; authentication failures (530 or 535) need fixed credentials on your side.