TL;DR
Permanent AUTH refusal: the selected mechanism is allowed only over an encrypted SMTP connection. Establish sufficient TLS before retrying AUTH. A transport configuration issue that can block submission and indirectly hurt deliverability. Do not retry unchanged.
What this code means
Historically, AUTH could answer with X.7.11; code 5.7.11 keeps that registry meaning under class 5. The chosen mechanism may run only while the underlying SMTP session already carries a sufficiently strong encryption layer. Modern practice should not advertise such a mechanism unless that protection is active. Permanent refusal here signals an encryption requirement for the mechanism, not wrong credentials, an invalid mailbox, or the precise cipher policy the server enforces.
Provider examples
501 5.7.11 Syntax error (no parameters allowed). For more information, go to About SMTP error messages and review RFC 3207 specifications. - gsmtpTechnical meaning
As a historical AUTH response, X.7.11 states that the selected authentication mechanism may be used only when the underlying SMTP connection is protected by an encryption layer of sufficient strength. A modern implementation should not advertise such a mechanism without an active, sufficient encryption layer. Code 5.7.11 applies this detail in class 5.
Delivery status
The leading digit 5 denotes a permanent failure of the current attempt. Repeating AUTH with the connection in the same state does not remove the stated obstacle; the code alone does not specify the required encryption configuration or establish that the credentials or recipient address are invalid.
- Class
- Permanent failure
- Retry
- Do not retry unchanged
- Suppression
- Check the full context
Retry decision
Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after confirming sufficient connection encryption or selecting a mechanism permitted in the current state; check suppression again before the attempt.
Suppression decision
Operational guidance: do not automatically add an address or domain to a suppression list based on 5.7.11 alone. Inspect the complete response, encryption state, AUTH mechanism, event history, and applicable policy, then make the suppression decision in that context.
Common causes
- The client selected an AUTH mechanism that requires encryption while the underlying SMTP connection lacked a sufficient encryption layer.
- The server advertised a mechanism that was not permitted in the current encryption state, although modern implementations should not do so.
Diagnostic steps
- Inspect the raw SMTP response and confirm that the enhanced code is exactly 5.7.11, that the basic reply is in the 5xx class, and that the code was returned to the AUTH command; retain the complete response text.
- Correlate the response with the attempt time, client, server endpoint, selected AUTH mechanism, and the state and strength of the encryption layer; determine these details from configuration and safe logs instead of inferring them from the code alone.
- Stop unchanged retries; before a controlled new attempt, confirm sufficient encryption or a permitted mechanism, check suppression again, and compare the result.
Actions by owner
Sender
- Do not manually repeat the same attempt; give the administrator the complete response, attempt time, and account used without disclosing credentials.
Sender administrator
- Inspect the client configuration, endpoint, AUTH mechanism, and the encryption state and strength for the specified attempt.
- After a verified correction to encryption or the mechanism, check suppression again and make one controlled attempt instead of repeating the unchanged AUTH request.
Recipient administrator
- If you manage the server that returned the code, inspect its logs, AUTH policy, and the mechanisms advertised in the encryption state applicable to the specified attempt.
- Correct a confirmed mismatch between advertised mechanisms and encryption policy, or give the sender administrator safe information about the required connection method.
Provider
- If you operate a service involved in the attempt, inspect its encryption and AUTH logs and give the administrator safe context needed to identify the required correction.
- Correct a confirmed problem in managed configuration or identify the owner of the correction; do not trigger automatic suppression from 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 4954 — SMTP Service Extension for Authentication — SMTP AUTH extension and related reply status codes.
- Gmail SMTP errors and codes — Official Gmail Help table of SMTP error messages and status codes.
Last verified:
