What this code means
The system refused the current attempt because the sender was not authorized to send to the destination. The decision may result from per-host or per-recipient filtering. The leading digit 4 denotes a temporary failure, so delivery may be retried in a controlled way.
Technical meaning
The X.7.1 pattern means that the sender is not authorized to send to the destination, so the message was refused; per-host or per-recipient filtering may produce this result. The RFC 3463 description calls this detail useful only as a permanent error, but the current IANA registry associates X.7.1 with basic replies in both the 4xx and 5xx classes. In the concrete 4.7.1 code, the leading digit assigns the result to the transient class.
Delivery status
The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the condition may clear. The code identifies an authorization or filtering outcome, but by itself it does not identify the specific rule, the system that applied it, or the condition's duration, and it does not establish that the recipient address is invalid.
- Class
- Temporary failure
- Retry
- Controlled retry
- Suppression
- Check the full context
Retry decision
Operational recommendation: check suppression state before every attempt, then retry with backoff, jitter, idempotency, and a time or attempt limit. Stop after success, a permanent result, a suppression-state change that makes the recipient ineligible, or exhaustion of the limit; refer repeated 4.7.1 results for diagnosis instead of retrying indefinitely.
Suppression decision
Operational recommendation: do not add the address to a suppression list based on temporary code 4.7.1 alone. Inspect the full response, authorization and filtering context available for the attempt, bounded-retry history, and other delivery events; suppress only after an independent permanent signal or when the applicable policy requires it.
Common causes
- During the current attempt, the reporting system determined that the sender was not authorized to send the message to the destination.
- Per-host or per-recipient filtering may have returned the refusal decision.
Diagnostic steps
- Inspect the raw SMTP response or delivery report and confirm that the enhanced code is exactly 4.7.1 and that the basic reply is in the 4xx class; retain the complete response text.
- Correlate the response with the intended message, attempt time, transaction stage, sender host and identity used, destination, and system that returned the code.
- Inspect available authorization and filtering logs to determine whether the decision was applied per host or per recipient and identify the specific rule; do not infer its contents or owner from code 4.7.1 alone.
- Check suppression before the next attempt, compare bounded-retry outcomes, and stop after success, a permanent result, a recipient-eligibility change, or exhaustion of the configured limit.
Actions by owner
Sender
- Confirm that the send was intended and that the sender and destination are correct; give the sender administrator the attempt time and complete response without repeatedly retrying it manually.
- Correct only a confirmed error in the sender, destination, or required sending path, then report the outcome of a new, controlled attempt.
Sender administrator
- Retain the raw response, time, transaction stage, sender host and identity used, and system that returned the code; check suppression and route the message through a bounded retry mechanism with backoff and idempotency.
- Group repeated 4.7.1 results by destination system, host or recipient, and time; verify the sending configuration, and after the limit is exhausted give the collected context to the recipient administrator or provider without suppressing the address based on this code alone.
Recipient administrator
- If the code came from a recipient system you manage, inspect authorization decisions and host- or recipient-level filters for the specified attempt to identify the rule that refused delivery.
- If the confirmed condition is temporary or the rule does not match the intended policy, clear the problem within your control and verify the result of a new, controlled attempt.
Provider
- If you operate a system involved in the attempt, inspect managed-service logs and the rules applied at the specified time; determine whether the decision was per host or per recipient without assigning a particular cause from the code alone.
- Clear the confirmed temporary condition in the managed layer and preserve the exact 4xx class, code 4.7.1, and safe context needed by the sender to control retries.
Sources and verification
The canonical T0 meaning of X.7.1 and its class assignment were verified against the IANA registry and RFC 2034, RFC 3463, and RFC 5248 as of July 17, 2026. RFC 3463 describes this detail as useful only for a permanent error, while the current IANA basic-status associations also confirm class 4; in code 4.7.1, the leading digit controls temporary handling. Retry, suppression, diagnostic, and owner-action guidance is presented separately as operational advice; this record contains no provider-specific practice.
- iana-smtp-enhanced-status-codesT0 source
Enumerated Status Codes / X.7.1
- rfc5248T0 source
Section 2.1: registry fields and non-exclusive Associated Basic Status Code
- rfc2034T0 source
Section 4: enhanced status class agrees with SMTP reply class
- rfc3463T0 source
IANA registry reference for X.7.1
Last verified:
