5.7.1Delivery not authorized, message refused

The system permanently refused the message because the sender was not authorized to send to the destination. Per-host or per-recipient filtering may produce this decision. Do not retry the same unchanged attempt.

The standard 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 registry description says this detail is useful only as a permanent error, and code 5.7.1 applies it in class 5.

The leading digit 5 denotes a permanent failure of the current attempt. The code alone does not identify the specific rule or system that applied it, and it does not establish that the recipient address is invalid.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new send only after a verified change to the sender identity or authorization, the applicable rule, or the sending path; check suppression again before the attempt.

Operational guidance: do not automatically add an address or domain to a suppression list based on 5.7.1 alone. Inspect the complete response, authorization and filtering context, event history, and applicable policy, then make the suppression decision in that context.

• The reporting system determined that the sender was not authorized to send to the destination, for example because of per-host or per-recipient filtering.
• In the accepted Gmail example, the message violated a custom-domain email policy.
• In the accepted Exchange Online example, delivery from an external sender to a mail-enabled public folder required authentication.

1. Inspect the raw SMTP response or nondelivery report and confirm that the enhanced code is exactly 5.7.1 and that the basic reply is in the 5xx class; retain the complete response text.
2. Correlate the event with the intended message, attempt time, sender identity and host, destination, transaction stage, and system that returned the code; identify the specific rule from available logs instead of inferring it from the code alone.
3. If the response contains Gmail marker “gcdp”, inspect the applicable custom-domain policy; if it contains “RESOLVER.RST.AuthRequired”, inspect the authentication requirement for the specified Exchange Online public-folder delivery.
4. Stop unchanged retries; before a controlled new send, verify a material correction and reassess suppression.

Verified provider examples for 5.7.1 appear below, from Gmail / Google Workspace, Microsoft 365 / Exchange Online and Interia Poczta. They show real provider practice for this response and do not redefine the standard 5.7.1 meaning or cover every occurrence.

550 5.7.1 This message violates example.com email policy. - gcdp <sessionid> - gsmtp

550 5.7.1 RESOLVER.RST.AuthRequired; authentication required [Stage: CreateMessage]

530 5.7.1 Client was not authenticated

550 5.7.1 Recipient doesn't want your mail

Compare 4.7.1, which applies the same detail in the temporary class; 4.7.0 for another or undefined temporary security status; 4.7.12 for a required authentication-mechanism transition; and 2.7.0 as a general security status in the success class.

• 2.7.0Other or undefined security status (success)
• 4.7.0Other or undefined temporary security status
• 4.7.1Delivery not authorized, message temporarily refused
• 4.7.12Authentication mechanism transition required

The standard X.7.1 meaning and the permanent class-5 application of code 5.7.1 were verified against the IANA registry and RFC 2034, RFC 3463, and RFC 5248 as of July 17, 2026. The exact Gmail and Microsoft examples come from accepted evidence gmail-ph01-122 and p03-b06-microsoft-x-7-1-001, respectively. Diagnostic, remediation, retry, and suppression recommendations are separate operational guidance.

• 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

• gmail-ph01-122T1 source

  Introductory identifier example immediately before the SMTP error messages table

• p03-b06-microsoft-x-7-1-001T1 source

  Problem section: exact NDR error contains the contiguous complete inner SMTP response for an external sender

• ext-src-microsoft-5-7-1-01T1 source

  How to interpret an Exchange NDR > example diagnostic block and following paragraph

• ext-src-interia-5-7-1-02T1 source

  Article body, delivery-failure error list, entry heading "550 5.7.1 Recipient doesn't want your mail"

Last verified: 17 July 2026