SMTP error 5.7.9 Authentication mechanism is too weak
The credentials may be entirely correct; the method used to present them is not good enough for this account. The reply is 534 5.7.9. The version most people actually meet is Google Workspace using it to say an application-specific password is required, which is really a statement about two-step verification on the account rather than about the mechanism itself. On other servers it means the client selected something like CRAM-MD5 or a plain login where policy demands better, and the correct response is for the client to try again with a stronger method.
What SMTP error 5.7.9 Authentication mechanism is too weak actually means
A server can hold different users to different standards. An administrator, a finance account or anything with elevated rights may be barred from methods that ordinary accounts can still use, and this reply is the server saying so. In theory a client receiving it retries with a better mechanism from the list it was offered. In practice hardly any client does; scanners, scripts and older applications simply record the failure and stop, which is why this looks to the user like a hard authentication failure rather than a negotiation. It is reported permanently, with only a 5 registered in the leading position, even though the remedy is often a single setting in the client and takes a minute.
This response to the AUTH command indicates that the selected authentication mechanism is weaker than server policy permits for that user. The client SHOULD retry with a new authentication mechanism.
— RFC 4954
How 5.7.9 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 534 5.7.9 as the pairing for this status.
The leading 5 is the server's verdict rather than part of the code's identity: it marks this as a permanent failure, which means the sending server has given up and returned the message.
What causes SMTP error 5.7.9 on a business phone system
- Two-step verification on a Google account and a client that cannot do OAuthWorkspace answers legacy clients with this code and expects an application-specific password to be generated in the account security settings. The text alongside it is unusually helpful and normally includes a link straight to the right page.
- Older challenge-response mechanisms withdrawn at the serverMechanisms that were considered adequate a decade ago have been removed from many platforms. A client that still asks for one is refused rather than downgraded, because silently accepting a weaker method would defeat the point of removing it.
- A client hard-coded to one methodApplications written against a single provider often name their mechanism explicitly instead of reading the server's EHLO response. Point that application at a different provider and it keeps asking for something no longer on offer.
- Policy requiring modern authentication for that accountWhere an organisation has mandated OAuth-based sign-in, password-based mechanisms are refused regardless of whether the password is right. The account holder often has no idea the policy exists until a device stops working.
- A mechanism advertised generally but restricted for one userBecause the standard is per-user, the same method can work for a colleague and fail for you. That asymmetry is a useful diagnostic: if one account works and another does not from the identical client, look at the account policy rather than the client.
How to fix SMTP error 5.7.9
- Read the text following the code firstThis is one of the few codes where providers write genuinely useful wording. Google names the required action explicitly. Whatever the server says here is worth more than any general advice, including this page.
- Move the client onto modern authenticationOutlook, Thunderbird, Apple Mail and every current mobile client support OAuth-based sign-in. Removing and re-adding the account rather than editing it is usually what forces the client to renegotiate rather than reuse its stored method.
- Generate an application-specific password where the platform still allows itTreat the result as a full credential: it bypasses the second factor by design. Record which device holds it, and revoke it the moment that device is replaced or leaves the building.
- For anything you build yourself, use the provider's OAuth flowA script or line-of-business application sending through Google or Microsoft should obtain a token rather than store a password. It is more work once and it survives every policy change afterwards.
- Relay the devices that cannot be changedWhere firmware will never support anything better, put an internal relay in front of it and let the relay hold the modern credential. One managed component authenticating properly beats a dozen appliances holding passwords.
Fixing the underlying problem
This page explains the code. These guides walk through the fix in detail.
Questions about SMTP error 5.7.9
How is this different from an invalid credentials error?
Are application-specific passwords safe to use?
Does Microsoft 365 send this code?
Related SMTP status codes
- SMTP error 4.7.12A password transition is needed
- SMTP error 5.7.10Encryption Needed
- SMTP error 5.7.11Encryption required for requested authentication mechanism
- SMTP error 5.7.8Authentication credentials invalid
Source. SMTP error 5.7.9 Authentication mechanism is too weak 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.