TL;DR
Permanent refusal: the message exceeds the size limit for its priority level. Reduce size, raise priority, or confirm server limits before retrying. A policy constraint, not a hard address bounce. Do not retry unchanged.
What this code means
A message larger than the receiving server's size limit for the stated priority maps to registry pattern X.7.16 as code 5.7.16, a permanent security-policy outcome. In the enhanced status register, class 5 treats this attempt as permanently failed, even when the standard describes the size cap as part of a mode that may later accept larger traffic at higher priority. The code reports a size-versus-priority constraint, not evidence that the recipient address is invalid. It does not include the message size, priority value, or enforced limit from the response alone.
Technical meaning
Message size beyond what the specified priority allows is the X.7.16 meaning. The standard says the condition may be temporary, for example when the server is operating in a mode that accepts only higher-priority messages below a defined size limit. Code 5.7.16 still places the result in the permanent class via its leading digit.
Delivery status
The leading digit 5 denotes a permanent failure of the current attempt. Regardless of a possible later change in server mode, handle 5.7.16 as permanent and do not retry the attempt unchanged. The code alone gives neither the message size, the priority value, nor the applied limit.
- Class
- Permanent failure
- Retry
- Do not retry unchanged
- Suppression
- Check the full context
Retry decision
Operational recommendation: stop automatic and manual retries of the same unchanged message. Consider a new, controlled attempt only after a justified reduction in message size, a valid priority change, or a confirmed change to the server limit; check suppression again first.
Suppression decision
Operational recommendation: do not automatically add an address or domain to a suppression list based on 5.7.16 alone. Inspect the full response, message size and priority, server constraints, and other delivery events, then make the suppression decision according to the confirmed cause and applicable policy.
Common causes
- The message size exceeds the limit applied by the server to the specified priority.
- The server is operating in a mode that accepts only higher-priority messages below a defined size limit.
Diagnostic steps
- Inspect the raw SMTP response or delivery report and confirm the exact code 5.7.16 and a basic reply in the 5xx class; retain the complete response text.
- Correlate the response with the intended message, attempt time and stage, server that returned the code, message size, and specified priority; do not infer missing values from the code alone.
- Use available server logs and policy to check the size limit for that priority and the active operating mode. Stop unchanged attempts, check suppression, and make a new controlled attempt only after a confirmed change.
Actions by owner
Sender
- Do not resend the same message manually; confirm that its content, attachments, and priority are intended, and give the sender administrator the full response.
- Reduce the message or change its priority only when justified by the content and confirmed by an administrator; report the result of the new, controlled attempt.
Sender administrator
- Retain the full response, message size, priority, time, and server that returned the code, stop unchanged retries, and check suppression.
- Use logs and policy to establish the applicable limit and server mode, coordinate a confirmed correction with the recipient administrator or provider, and only then make one controlled attempt.
Recipient administrator
- If you manage the server that returned the code, inspect its logs, active operating mode, and size limits for the specified priority at the attempt time.
- Correct the confirmed configuration problem within your control, or give the sender a safe, precise description of the applicable constraints, and verify the new attempt.
Provider
- If you operate a system involved in the attempt, inspect managed-service logs and the size and priority limits applied at the specified time.
- Correct the confirmed problem in the managed layer, or give the appropriate administrators the precise context needed to resolve it; do not trigger suppression based on the code alone.
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.
- SMTP Enhanced Status Codes — IANA registry of enhanced mail system status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- RFC 2034 — SMTP Service Extension for Returning Enhanced Error Codes — Defines how SMTP returns enhanced status codes to clients.
- RFC 6710 — SMTP Extension for Message Transfer Priorities — Defines message transfer priorities and related status codes.
Last verified:
