5.4.6Recipient or domain quota exceeded on a hosted mailbox platform (Titan)

Three exact Titan responses below carry digits 5.4.6 while describing a recipient's or a hosting domain's send/receive quota being exceeded, not a routing loop or a forwarding loop; the concrete code published here therefore rests entirely on that corpus-collected production evidence. Code 5.4.6 places registry pattern X.4.6 in class 5. RFC 3463 supplies X.4.6 with the sample text "Routing loop detected" and frames it as useful only as a persistent transient error, yet the IANA registry records "Not given" for this pattern's Associated Basic Status Code. Neither class 4 nor class 5 has a mechanically confirmed basic code here, so this catalog's IANA registry mirror marks X.4.6 unresolved for that reason.

Because the IANA registry's Associated Basic Status Code field for X.4.6 reads "Not given", this catalog's registry mirror leaves the pattern's class applicability unresolved for both class 4 and class 5. Under RFC 3463, the X.4.6 pattern means a routing loop: a message forwarded too many times because of incorrect routing tables or a user-forwarding loop, and it is described as useful only as a persistent transient failure. Unlike patterns such as X.2.2 or X.4.1 in this catalog, where at least one class carries a mechanically confirmed basic code, X.4.6 confirms none. The concrete code 5.4.6 is published here on exact corpus evidence alone: three Titan Email responses that carry the digits 5.4.6 while describing a recipient mailbox's or a hosting domain's storage or rate quota being exceeded, a condition unrelated to the routing-loop scenario the RFC's own example describes.

The leading digit 5 denotes a permanent failure for this message in the current context: do not repeat the exact same send unchanged. In the evidence collected here, the underlying condition is a quota — a personal mailbox allocation or a domain-wide hourly/daily incoming-mail limit — that can and does change over time, so "permanent" describes this specific attempt, not a durable statement about the address or the domain. Do not read the class-5 digit as a signal that the recipient address itself is invalid, and do not conflate this code with an actual routing loop, since neither the IANA registry nor RFC 3463's own worked example is confirmed for this class here.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Operational recommendation: stop identical, tightly-spaced automated retries of the same message. If the response is the single-mailbox "Recipient Quota Exceeded" wording, treat it like 5.4.1 or another destination-side refusal — wait for an external signal that something changed (the recipient or their administrator confirms space was freed) rather than retrying on a fixed clock. If the response is one of the two domain-wide "Hourly/Daily Quota Exceeded" wordings, a single bounded retry after the corresponding window has rolled over (the next hour, or the next day) is reasonable, since the underlying condition is a rate limit tied to a known reset cadence rather than an address problem; do not exceed a small, explicit attempt limit.

Do not add the address to a suppression list based on code 5.4.6 alone, and do not let the phrase "Mailbox Does Not Exist" inside the domain-quota wording drive a suppression decision by itself — in every accepted example here that phrase accompanies a rate-limit condition, not a confirmed invalid address. Suppress only once an independent, unambiguous permanent signal (such as an actual 5.1.1 or 5.2.1 response) appears, or when the applicable list policy otherwise justifies it.

• A specific recipient mailbox on this Titan-hosted domain has used up its allotted storage or send/receive quota (the "Recipient Quota Exceeded" wording), and no messages will be accepted for that address until the owner or the domain administrator frees or raises it.
• The receiving domain, as a whole, has hit Titan's own hourly or daily incoming-message quota for that hosting plan (the two "Domains ... Quota Exceeded" wordings) — a rate limit tied to the domain's plan tier, not a property of any single mailbox.
• In both domain-quota wordings, Titan's own message text bundles the unrelated phrase "Mailbox Does Not Exist" together with the quota description, even though the domain and mailbox are not in fact missing — a documented quirk of this specific provider's wording, not a general definition of the code.

1. Inspect the raw SMTP response and confirm the enhanced code is exactly 5.4.6, the basic reply is 550, and read the trailing free-text description in full, since it is the only place this provider distinguishes a single mailbox's quota from a domain-wide quota.
2. Do not let an automated bounce classifier treat the phrase "Mailbox Does Not Exist" inside the domain-quota wording as evidence of an invalid or missing address by itself; correlate it with the surrounding "Hourly/Daily Quota Exceeded" text before drawing that conclusion.
3. Correlate the rejection with the recipient count and send volume to that domain over the preceding hour and day; a burst pattern immediately before the rejection points to the domain-wide throttle rather than one mailbox's own storage limit.
4. If the pattern recurs, consult Titan's own support documentation on sending/receiving limits (linked below), or ask the domain administrator to check the account's plan tier and current usage before the next attempt.