5.2.1Recipient mailbox exists but is disabled

Under code 5.2.1 the status names a disabled-account condition: it applies registry pattern X.2.1 ("Mailbox disabled, not accepting messages"), so the mailbox exists, yet the receiving system refuses messages for it because the account has been disabled. This catalog's mechanical IANA confirmation leaves X.2.1 fully unresolved; neither class 4 nor class 5 carries a confirmed class, so this concrete permanent code is published solely on exact, corpus-collected production evidence (the Gmail 550 5.2.1 response below), not on a registry confirmation. It does not signal a nonexistent address or a temporary rate limit.

Concrete code 5.2.1 (class 5) applies the X.2.1 pattern as a permanent failure of the current attempt and is published here on exact corpus evidence, not on an IANA registry confirmation. That pattern means the destination mailbox exists but will not accept messages because it has been disabled. RFC 3463 notes that this condition may be permanent (the mailbox will never be re-enabled) or transient (temporarily disabled), without settling which class belongs to any concrete code; in this catalog, the IANA registry does not mechanically confirm any class for X.2.1.

The leading digit 5 denotes a permanent failure of this attempt: the account is disabled, and the send should not be retried unchanged. This does not certify that the account can never be re-enabled — only that, absent a confirmed change, retrying now will fail the same way. Do not conflate this with 5.1.1, where the address itself does not exist.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Stop automatic and manual retries of the unchanged send. Consider a new attempt only after independent confirmation — from the recipient through another channel, or from their administrator — that the account has been re-enabled.

Treat a confirmed 5.2.1 as a strong suppression candidate, but inspect the full response and recent delivery history first: a disabled account can later be reactivated by its owner or administrator, so record the date of the disable signal and consider re-validating the address rather than deleting it outright, especially in a business (Workspace) context where the account may return after a temporary leave or an offboarding process.

• The recipient closed their own account, or it was suspended by the mailbox provider (for example, for a Terms of Service violation), and the account is not accepting any mail while in that state.
• A domain administrator (Google Workspace) has suspended or deactivated the user's account — for example, during offboarding — while the mailbox address itself has not been deleted or reassigned.
• In the accepted Gmail example, the response links directly to Google's support page for a disabled account (DisabledUser) — documented behavior of this specific provider, not a general definition of code 5.2.1 across all providers.
• A third accepted Gmail example carries the same 5.2.1 digits but describes a different condition: the recipient is receiving mail at a rate the system permanently will not accept for this address (ReceivingRatePerm). Google's own guidance ties this pattern to mailbox "bombing" — flooding an address with mail to disable it or mask other malicious activity; treat a sudden ReceivingRatePerm response as a signal to verify the recipient was not added to your list by an automated script or a compromised source, not simply as a stale or closed account.

1. Inspect the raw SMTP response or delivery report and confirm that the enhanced code is exactly 5.2.1 (not 5.1.1 or 5.2.2), and that the basic reply is in the 5xx class (550 in the accepted example).
2. Correlate the response with the specific message, attempt time, and recipient address; retain the full response text, including any provider link (such as a disabled-account support page).
3. Ask the recipient, ideally through another channel, whether the account was intentionally closed, suspended, or is under administrator review; in a business setting, ask the domain administrator directly.
4. Check delivery history for this address: a sudden 5.2.1 after a long run of successful deliveries points to a recent suspension or offboarding event rather than a long-stale address.