TL;DR
4.7.1 is a temporary delivery-authorization refusal. Preserve the reply, identify the sender or policy scope, then retry with backoff; do not treat it as proof that the recipient address is invalid.
What this code means
X.7.1 means delivery is not authorized and the message was refused. With leading digit 4, the refusal is transient: the stated condition may change, but the code alone does not identify the policy, identity, or recipient-specific cause.
Provider examples
smtp;450 cuda_nsu 4.7.1 <email@example.com>: Recipient address rejected: Policy Rejection- Abuse. Go away.smtp;451 4.7.1 <email@example.com>: Recipient address rejected: Greylisted for 5 minutessmtp;451 4.7.1 Try again later421 4.7.1 Messages to example@icloud.com deferred due to excessive volume. Try again later - https://support.apple.com/en-us/HT204137451 4.7.1 Service unavailable - try again laterTechnical meaning
RFC 3463 places X.7.1 in the Security or Policy Status subject class as delivery not authorized, message refused. The class digit distinguishes this temporary result from a permanent refusal with the same subject detail.
Delivery status
A 4.7.1 result can clear after the applicable authorization, reputation, or policy state is corrected or expires. It does not itself prove bad credentials, a permanent denial, or a bad recipient address.
- Class
- Temporary failure
- Retry
- Controlled retry
- Suppression
- Check the full context
Retry decision
Do not resend unchanged at volume. Retain the complete response, identify the affected sending identity and receiver policy scope, then retry with backoff, jitter, idempotency, and a bounded limit after an actionable change or a reasonable wait.
Suppression decision
Do not suppress an address from 4.7.1 alone. This code can be scoped to a sender, domain, route, or policy; use independent recipient-level permanent evidence for suppression.
Common causes
- A sending identity, route, or policy is temporarily not authorized for this delivery attempt.
- A receiving service applies a transient policy, reputation, or access-control condition.
- The exact response text contains necessary scope that the generic status code does not expose.
Diagnostic steps
- Verify the exact code, reply class, text, and SMTP stage.
- Correlate the response with sending domain, IP, authentication results, recipient domain, and time.
- Identify the specific policy or authorization signal from logs or the receiver's diagnostics.
- Make only the justified change, then perform a bounded retry.
Actions by owner
Sender
- Stop repeated manual resend attempts and provide the complete reply and send context to the administrator.
Sender administrator
- Check the sending identity, authentication, policy, and destination-specific traffic before retrying.
Recipient administrator
- If you control the refusal, verify the relevant authorization policy and return a safe diagnostic where possible.
Provider
- Correlate recurring results by sending identity and destination, and apply controlled pacing or escalation rather than blind retry.
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 3463 — Enhanced Mail System Status Codes — Defines the class/subject/detail model for enhanced status codes.
- 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:
