TL;DR
Outlook.com's inbound queue for the receiving domain is temporarily over its rate quota: transient, not permanent, and unrelated to your authentication or content. Retry with backoff and a reduced pace to this domain; do not suppress the recipient address on a single 4.7.3. Registry pattern X.7.3 officially names an unrelated failure — a security conversion problem — and Outlook's real usage here has nothing to do with that meaning; treat the response text, not the registry label, as authoritative.
What this code means
Stamping registry pattern X.7.3 with a transient class does not make code 4.7.3 share that pattern's meaning here. RFC 3463 defines X.7.3 as "Security conversion required but not possible" (a failed secure-messaging-protocol conversion) and states that this detail is useful only as a permanent error, with Associated Basic Status Code "Not given"; this catalog's registry mirror still carries X.7.3 as fully unresolved, with no confirmed class 4 or class 5. Production text observed from Outlook.com ("Organization queue quota exceeded") names an entirely different condition: the receiving domain's incoming queue has exceeded its rate allowance on this attempt. That is a provider reuse of the numeric code point for an unrelated operational condition, not a documented instance of the meaning recorded in the RFC, and both the code's presence and its sense in this catalog rest solely on exact corpus-collected production evidence.
Technical meaning
Outlook.com's own reuse of the numeric pattern produces the concrete code 4.7.3 recorded here: a receiving-domain queue-capacity condition in which the destination domain's mail infrastructure is currently accepting mail more slowly than the rate at which it arrives, and the 450 4.7.3 response tells senders to slow down and retry rather than reporting any security, encryption, or protocol-conversion failure. By contrast, RFC 3463 Section 3.8 defines X.7.3 for the case in which a message required conversion between secure messaging protocols and that conversion could not be performed; the RFC marks the detail useful only as a permanent error and gives no Associated Basic Status Code. RFC 5248 establishes the IANA registration process for X.7 detail codes and treats the Associated Basic Status Code list as illustrative rather than exhaustive, yet neither that RFC nor this catalog's registry mirror grants X.7.3 a confirmed class-4 or class-5 status.
Delivery status
The leading digit 4 denotes a persistent transient failure: at the moment of this attempt, the receiving domain's queue is over its rate allowance, but the condition is expected to clear as inbound volume subsides, independent of anything the sender did wrong. Note that RFC 3463 itself states X.7.3 is useful only as a permanent error — Outlook.com's live use of this exact pattern as a class-4, retryable condition diverges from that guidance, which is one more reason this record rests on corpus evidence rather than the registry's stated meaning for this code.
- Class
- Temporary failure
- Retry
- Controlled retry
- Suppression
- Check the full context
Retry decision
Retry with backoff, jitter, and a reduced sending rate to this receiving domain; do not keep sending at the pace that triggered the deferral. Stop retrying after success or once an attempt or time limit is reached; a single 4.7.3 is not grounds to treat the address, domain, or your own authentication as broken.
Suppression decision
Do not suppress or remove any recipient address based on 4.7.3 alone: the condition is attached to the receiving domain's inbound queue capacity, not to any individual mailbox's validity or engagement. Suppression decisions should follow independent, per-recipient signals (hard bounces, permanent codes) rather than this shared, domain-level rate condition.
Common causes
- The receiving domain's Outlook.com-hosted mail infrastructure is currently accepting inbound mail more slowly than the rate at which messages are arriving for it, whether from one large sender, several senders at once, or a backlog working through the queue.
- The condition is a receiving-side, domain-wide capacity signal rather than anything about this sender's authentication, reputation, or message content — despite registry pattern X.7.3 officially naming an unrelated secure-messaging-protocol failure, Outlook.com's use of this response has nothing to do with that meaning.
- In the accepted example the response carries no support link and names only the receiving domain in brackets ("[outlook.com]"), consistent with a generic infrastructure queue-capacity message rather than a policy action aimed at this particular sender or message.
Diagnostic steps
- Inspect the raw SMTP response and confirm the enhanced code is exactly 4.7.3 and the basic reply is in the 4xx class (450 in the accepted example); note the receiving domain named in brackets.
- Do not interpret this response as a security, encryption, or authentication problem: RFC 3463 defines X.7.3 for a failed secure-messaging-protocol conversion, but that meaning is absent from Outlook.com's production text here, which names only a queue-quota condition.
- Reduce the sending rate to the named receiving domain and retry in a bounded, backed-off way; a queue-quota condition tied to inbound volume typically clears once the backlog or burst passes.
- If 4.7.3 recurs repeatedly for one receiving domain across separate sends, treat it as a signal to pace outbound volume to that domain specifically, rather than as a per-recipient or per-message defect.
Actions by owner
Sender
- Retry with backoff and a reduced pace to this receiving domain; do not treat a single 4.7.3 as an authentication, security, or address-validity problem.
- If the code persists past a reasonable retry window, give your sending administrator the receiving domain, attempt time, and full response text before escalating.
Sender administrator
- Check sending logs and volume to the named receiving domain; throttle or spread sends across a longer window rather than retrying at the same pace that triggered the deferral.
- Group repeated 4.7.3 results by receiving domain and time; once retries at a lower pace succeed, ramp volume back up gradually rather than reverting immediately to the prior rate.
Recipient administrator
- If your organization's inbound mail is routed through this Outlook.com-hosted domain, review inbound volume and any Microsoft-side queue or throughput settings with your mail administrator or Microsoft support.
- Where policy permits, share the exact response text and timing with the sender's administrator so they can correlate it with their own sending logs.
Provider
- If you operate sending infrastructure (ESP, MTA), monitor for repeated 4.7.3 by receiving domain and apply your own outbound pacing ahead of the receiving domain's queue limit.
- Escalate to Microsoft's postmaster or support channels only once the condition persists well past a reasonable window despite confirmed pacing changes on your side.
Provider examples
smtp;450 4.7.3 Organization queue quota exceeded. [outlook.com]450 4.7.3 Organization queue quota exceeded. [outlook.com]Sources
These sources define what this enhanced status code means, mainly through the IANA registry and related RFCs. When provider examples appear on the page, they come from that provider's published documentation. Follow the links to read the original wording in context.
- RFC 3463 — Enhanced Mail System Status Codes — Defines the class/subject/detail model for enhanced status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- SMTP Field Manual (community corpus) — Community-maintained reference of provider SMTP responses, pinned locally as evidence.
- smtp-codes (community corpus) — Community-maintained reference of provider SMTP responses, pinned locally as evidence.
Last verified:
