SMTP Error 432

What is SMTP Error 432?

432 is a transient negative reply (a 4yz code, so the condition is temporary and the action can be retried). Its authoritative meaning is defined in RFC 4954 §6, the SMTP authentication extension:

432 4.7.12 A password transition is needed — This response to the AUTH command indicates that the user needs to transition to the selected authentication mechanism. This is typically done by authenticating once using the PLAIN authentication mechanism.

In other words, 432 is returned during the AUTH handshake, not during recipient delivery. The server is telling the client that the stored credential or authentication state is stale and must be refreshed before the selected SASL mechanism (CRAM-MD5, etc.) will work again. It is closely related to 454 4.7.0 Temporary authentication failure (also RFC 4954), which signals a temporary server-side auth failure that the client should not re-prompt for.

What causes SMTP Error 432?

• A password change or forced rotation. The account password was reset on the provider, so the mechanism needs a one-time re-authentication to re-sync.
• A stale or cached credential in the sending client/library that no longer matches the server.
• A mechanism that requires a PLAIN bootstrap. Some servers require you to authenticate once with PLAIN (over an encrypted channel) before a stronger mechanism is usable in later sessions.
• Exchange variant: Some Microsoft Exchange deployments and third-party bounce tables map the bare code 432 to a message like "The recipient's Exchange Server incoming mail queue has been stopped." In that case 432 reflects a halted/paused receive queue on the destination server (maintenance, too many open connections, or admin troubleshooting) rather than an auth problem. Read the enhanced status code and text the server actually returned to tell the two apart — 4.7.12 means auth; a queue/connection message means the Exchange variant.

How do I fix SMTP Error 432?

If you received 432 4.7.12 (the RFC meaning — most common from your sending app):

1. Re-authenticate with a current credential. Log in to your email/SMTP provider, reset or regenerate the password (or API key/SMTP credential), and update it everywhere your client or app stores it.
2. Make sure the session is encrypted before AUTH. RFC 4954 §4 requires servers to refuse plaintext mechanisms unless STARTTLS has been negotiated (or another mechanism protects the session from password snooping). In practice that means STARTTLS on port 587 (RFC 6409, message submission) or implicit TLS on port 465 (RFC 8314). Confirm TLS is enabled so PLAIN/LOGIN are permitted.
3. Do the PLAIN bootstrap if required. Authenticate once using AUTH PLAIN over TLS, then retry the originally selected mechanism in a subsequent session.
4. For Gmail: "Less Secure Apps" was removed for personal Gmail accounts in 2022, and Google Workspace's basic-auth/Less Secure Apps support fully ended in May 2025 — do not rely on it for either. Use an App Password (requires 2-Step Verification) or OAuth2 as the credential.

S: 250 AUTH CRAM-MD5 PLAIN LOGIN
C: AUTH CRAM-MD5
S: 432 4.7.12 A password transition is needed
C: AUTH PLAIN <base64 over TLS>      # one-time bootstrap
S: 235 2.7.0 Authentication successful

If you received the Exchange "queue stopped" variant:

1. This is a problem on the recipient's server, not your credentials. Retry later — 4xx codes are temporary and most senders/MTAs will requeue automatically.
2. If you administer the receiving Exchange server, check the Queue Viewer (Get-Queue / Resume-Queue) for a stopped/paused queue and resume it; investigate connection limits or maintenance that halted the queue.
3. If you are the sender and it persists, contact the recipient's mail administrator with the timestamp and full bounce text.