TL;DR
4.7.15 is a temporary priority-level condition. Preserve the response, verify the relevant receiver policy, and retry only after an approved change or wait; it is not a recipient hard bounce.
What this code means
X.7.15 identifies a message whose priority level is too low. The leading 4 states that the current outcome is transient, while the status alone does not define a provider's queue model, priority header, or acceptable remediation.
Technical meaning
RFC 6710 registers X.7.15 as priority level is too low in the security or policy subject class. The status describes a priority-policy outcome; it does not establish a generic security defect or a universal mail-priority implementation.
Delivery status
Class 4 permits a controlled later attempt if the relevant condition changes. It does not mean that priority can safely be raised without policy approval, nor that the mailbox is unavailable.
- Class
- Temporary failure
- Retry
- Controlled retry
- Suppression
- Check the full context
Retry decision
Keep the complete response and verify the policy scope. Do not repeatedly resend at the same settings; use an approved priority treatment or wait, then retry with backoff, idempotency, and an attempt limit.
Suppression decision
Do not suppress a recipient from 4.7.15 alone. This is a message or policy condition, not an independent permanent signal about recipient validity.
Common causes
- The message priority is below a receiver policy threshold.
- A queue or service policy temporarily requires a different priority treatment.
- The exact receiver implementation adds constraints not expressed by the generic code.
Diagnostic steps
- Confirm the exact code, basic response class, transaction stage, and complete diagnostic.
- Identify the policy owner and whether the condition is message-scoped or service-scoped.
- Check message priority treatment only through approved configuration and policy sources.
- Retry in a bounded way after a justified change or wait.
Actions by owner
Sender
- Avoid repeated manual resends and give the sender administrator the full response and message context.
Sender administrator
- Verify permitted priority handling and destination policy before changing queue or message settings.
Recipient administrator
- If you operate the receiver, confirm the applicable priority policy and expose safe diagnostics where possible.
Provider
- Correlate priority-related deferrals and document supported remediation without assuming all receivers use the same policy.
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:
