TL;DR
Outlook.com 4.7.3 signals a temporary receiving-domain queue quota condition. Reduce pace to that domain and retry with backoff; do not suppress the recipient from one shared queue deferral.
What this code means
The accepted Outlook.com response uses 450 4.7.3 for "Organization queue quota exceeded." Its operational meaning is a receiving-domain queue-capacity condition. RFC 3463 assigns the X.7.3 registry pattern an unrelated secure-message conversion meaning and says that pattern is useful only as a permanent error, so the provider response text—not the registry label—controls this record's concrete diagnosis.
Provider examples
smtp;450 4.7.3 Organization queue quota exceeded. [outlook.com]450 4.7.3 Organization queue quota exceeded. [outlook.com]Technical meaning
The concrete Outlook.com use recorded here is a temporary rate or queue-capacity signal for a receiving domain. It is based on exact corpus captures, not an IANA class confirmation. It must not be diagnosed as the RFC's unrelated secure-message conversion condition.
Delivery status
The reply's leading 4 and basic 450 show a temporary deferral in the accepted examples. Queue capacity can clear as traffic subsides, but a retry should be paced to the receiving domain rather than repeated unchanged.
- Class
- Temporary failure
- Retry
- Controlled retry
- Suppression
- Check the full context
Retry decision
Reduce the send rate to the named receiving domain, use backoff, jitter, idempotency, and a bounded attempt limit, then increase volume gradually only after deliveries recover. Do not infer a sender-authentication defect from this queue response.
Suppression decision
Do not suppress recipients because of 4.7.3 alone. The accepted condition is shared receiving-domain queue capacity, not a mailbox-validity or engagement signal.
Common causes
- Inbound demand for the receiving domain exceeds its current queue allowance.
- A burst from one or several senders creates a receiving-side backlog.
- A sender continues to retry at the same rate instead of honoring the queue's backpressure.
Diagnostic steps
- Confirm exact 4.7.3, the 450 class, full response text, and named receiving domain.
- Group outcomes by destination domain and time to distinguish a shared queue condition from recipient-level failures.
- Reduce pace for that destination and make bounded backed-off retries.
- Escalate only if the condition persists beyond a reasonable paced retry window.
Actions by owner
Sender
- Stop manual resend bursts and provide the response and receiving domain to the administrator.
Sender administrator
- Apply destination-specific pacing and inspect traffic volume to the named domain.
Recipient administrator
- If your inbound service uses the named platform, review queue or throughput context with the relevant administrator or provider.
Provider
- Monitor repeated destination-specific deferrals and impose pacing before the receiver's queue quota is exceeded.
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:
