Is 5.2.0 caused by my message?

Rarely. It points at the recipient’s mailbox or store, so their admin usually has to look at it.

Why does the bounce not say what went wrong?

The delivery agent hit an error it had no specific code for, so it used the generic mailbox status. The real reason is in the recipient server’s logs.

5.2.0 bounce: other or undefined mailbox status

5.2.0Other or undefined mailbox statusPermanent: retrying will not help

Typical wording

550 5.2.0 <user@example.com>: Mailbox unavailable

What it means

RFC 3463 defines X.2.0 as "Other or undefined mailbox status". The subject digit 2 means the address was valid and the server found the mailbox, but something about that mailbox prevented delivery. The detail digit 0 says the server did not specify whether it was full, disabled, or something else.

Delivery agents produce it more than SMTP gateways: Dovecot LDA or LMTP, Cyrus, procmail, and Exchange mailbox transport all report 5.2.0 when writing to the mailbox store fails in a way they do not classify. Exchange also uses 5.2.0 in some store and permission errors. It differs from 5.2.1 (mailbox disabled), 5.2.2 (mailbox full), and 5.1.1 (no mailbox at all).

The temporary 4.2.0 is more common than 5.2.0, because store problems such as a locked mailbox or a busy database usually clear on their own. A 4.2.0 keeps the message in the sender’s queue; a 5.2.0 sends it back.

Likely causes

The recipient’s mail store hit a file permission, lock, or corruption problem while writing the message.
A Sieve script or mailbox rule on the recipient side failed or rejected the message.
The mailbox is in the middle of a migration or restore and is temporarily read-only.
A delivery agent crashed or returned an unexpected exit status that the MTA mapped to 5.2.0.

How to fix it

As the sender, wait a little and resend once. If it fails again, contact the recipient through another channel and include the bounce text.
As the recipient’s admin, find the queue ID or message ID from the bounce in the MTA log and follow it to the delivery agent’s log entry.
Check file system permissions, disk space, and lock files on the mailbox path, and repair the mailbox index if the store reports corruption.
Review per-user filters and Sieve scripts that may reject or redirect the message.
Once fixed, send a test message from outside to confirm the mailbox accepts mail again.

Checks that apply

Your domain or sending IP (fills in the checks below)

MailFlow Monitor Sends a monitored test after the repair, so the admin can see delivery work end to end.
SMTP Diagnostics Confirms the front-end mail server is answering normally, which points the search at the mailbox store behind it.

FAQ

Is 5.2.0 caused by my message?: Rarely. It points at the recipient’s mailbox or store, so their admin usually has to look at it.
Why does the bounce not say what went wrong?: The delivery agent hit an error it had no specific code for, so it used the generic mailbox status. The real reason is in the recipient server’s logs.

All 191 bounce codes