Skip to content

SMTP error 4.7.12 A password transition is needed

What SMTP error 4.7.12 means

A temporary refusal telling the client that the account has to be moved onto the mechanism it just attempted, and that the way to do it is to sign in once using a plain mechanism over a protected connection so the server can store what it needs. It shows up as 422 4.7.12 or 432 4.7.12. Be realistic about how often you will meet it: it belongs to servers that keep separate credential material per mechanism, and very few UK businesses run one. It is included here because the leading 4 misleads people into waiting for it to clear on its own.

What SMTP error 4.7.12 A password transition is needed actually means

Some authentication mechanisms need the server to hold something it can compute against, rather than a one-way hash of the password. If an account was created before such a mechanism was enabled, or the stored material was cleared, the server cannot complete the exchange and asks for a single sign-in by a simpler method so it can derive and save what is missing. The leading 4 is the part worth understanding. It marks the condition as transient, so a sending system queues the message and keeps retrying instead of bouncing it. Nothing about the condition resolves itself though. The retry window simply runs down, and when it expires you get a delivery-time-expired notification instead, which sends people looking in entirely the wrong place.

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. The selected mechanism SHOULD then work for authentications in subsequent sessions.

RFC 4954

How 4.7.12 appears in a bounce

A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists these pairings for this status: 422 4.7.12, 432 4.7.12. Which one you get depends on the point in the conversation at which the server refused.

The leading 4 is the server's verdict rather than part of the code's identity: it marks this as a temporary failure, which means the sending server is still retrying.

What causes SMTP error 4.7.12 on a business phone system

How to fix SMTP error 4.7.12

  1. Sign in once with a simple mechanism over TLSThis is what the server is actually asking for. Use a client you control, connect with encryption established, authenticate with a plain mechanism and let the server record what it needs. Subsequent sessions with the original mechanism should then work.
  2. Reset the password through the provider's own interfaceDoing it through the control panel rather than directly against the store regenerates every derived value at once. It is blunt, it works, and it is usually quicker than establishing which specific material is missing.
  3. Move the client off challenge-response mechanisms entirelyConfigure it for a plain mechanism over TLS, or for OAuth where the provider supports it. Both avoid the whole category of problem and neither is less secure, because the encryption is doing the work that the challenge-response design was originally there to avoid needing.
  4. Do not wait for the queue to sort itself outThe transient class means messages are being held rather than bounced, which buys you time and nothing else. Fix the account before the retry window expires, otherwise the queue empties into delivery failure notices and the original code disappears from view.
  5. Ask the provider what operation they expectThis condition is specific to how a given server stores credentials, so their support team will recognise it immediately even though the code is unfamiliar. Quote the full reply line including the three-digit number, since that distinguishes it from ordinary authentication failures.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 4.7.12

It is a 4xx code, so will it clear on its own?
No. The transient class describes how the sending system should behave, not whether the condition is self-healing. Somebody has to perform the sign-in or the password reset the server is asking for. Left alone, the queued messages eventually expire.
Should we expect this on Microsoft 365 or Google Workspace?
Not in normal operation. Neither platform works this way, and an authentication problem on either will almost always present as 5.7.8 or as a Conditional Access block. If you are seeing this code, the server involved is a smaller hosted platform or something on-premise.
How long before queued messages start failing?
It depends on the sending system, but a day or two of retries is typical before a delay warning and a few days before final failure. That window is the whole value of the transient class, and it is easy to lose most of it establishing what the code means.

Related SMTP status codes

Source. SMTP error 4.7.12 A password transition is needed is defined in RFC 4954 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes

Sitemap