TL;DR
Permanent AUTH refusal: the mechanism needs TLS or another strong privacy layer first. Enable encryption or pick a stronger mechanism before retrying. A transport setup gap, not a recipient bounce; fix it to restore sending and protect reputation. Do not retry unchanged.
What this code means
Clear-text AUTH that must wait for an external strong privacy layer such as TLS falls under registry pattern X.7.10, and code 5.7.10 carries that detail into the SMTP reply. The status is a transport confidentiality precondition for the requested mechanism. Permanent class 5 refuses the current attempt. It does not establish invalid credentials, a bad recipient address, or the exact TLS configuration the server will accept.
Provider examples
523 5.7.10 SMTP protocol violation, no commands allowed to pipeline after STARTTLS. For more information, go to About SMTP error messages and review RFC 3207 specifications. - gsmtpTechnical meaning
Before the requested authentication mechanism may be used, an external strong privacy layer is required under X.7.10. The detail is intended primarily for clear-text authentication; the client may activate a security layer such as TLS first, or choose a stronger mechanism instead. Code 5.7.10 applies this detail in class 5.
Delivery status
The leading digit 5 denotes a permanent failure of the current attempt. Repeating the attempt without changing the privacy layer or mechanism does not resolve the stated condition; the code alone identifies neither a supported TLS configuration nor a stronger mechanism and does not 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. Make a new, controlled attempt only after confirming that the required privacy layer, such as TLS, is active or configuring a stronger mechanism allowed by the server; check suppression again first.
Suppression decision
Operational guidance: do not automatically add the address or domain to a suppression list based on code 5.7.10 alone. Inspect the complete response, connection-security state, selected mechanism, server policy, and event history, then make the decision according to the confirmed cause and applicable policy.
Common causes
- The client attempted to use an authentication mechanism that requires an external strong privacy layer before such a layer was active.
Diagnostic steps
- Inspect the raw SMTP response or attempt report and confirm that the enhanced code is exactly 5.7.10 and that the basic reply is in the 5xx class; retain the complete response text.
- Correlate the response with the attempt time, client, server endpoint, selected mechanism, and connection privacy-layer state; inspect available logs for TLS negotiation and authentication policy instead of inferring the required configuration from the code alone.
- Stop unchanged retries; before a new, controlled attempt, confirm activation of the required privacy layer or selection of an allowed stronger mechanism, check suppression again, and compare the result.
Actions by owner
Sender
- Do not make further manual attempts without a change; give the administrator the complete response, attempt time, and account used without disclosing credentials.
Sender administrator
- Retain the complete response and inspect the client configuration, TLS or other privacy-layer state, selected mechanism, and server endpoint for the specified attempt.
- Configure a confirmed security layer or stronger mechanism that complies with server policy, check suppression again, and make one controlled attempt instead of repeating the unchanged authentication.
Recipient administrator
- If you manage the server that returned the code, inspect its logs, privacy-layer availability, and authentication policy applied to the specified attempt.
- Correct the configuration only if it does not match the intended policy; otherwise give the sender administrator safe information needed to establish the required layer or select an allowed mechanism.
Provider
- If you operate a service involved in authentication or secure-connection establishment, inspect its logs and policy for the specified time, endpoint, and mechanism.
- Correct a confirmed problem in the managed layer or identify the supported way to establish the required protection or use a stronger mechanism; 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.
- Gmail SMTP errors and codes — Official Gmail Help table of SMTP error messages and status codes.
Last verified:
