481 Authentication Failed

This code is the point where responsibility becomes genuinely shared, which is why it generates more misdirected support tickets than any other login failure. The server has read a username and password and decided the session may not continue. That decision can rest on the credentials themselves or on a limit attached to a perfectly valid account, and the code alone does not say which.

Two unrelated conditions behind one code

The first is what the name suggests: the credential pair does not match an active account. The second is that the account is fine but has no room, because every connection it is allowed is already open. The specification has 502 for the second case and many servers use it, but some report an exhausted connection allowance as an authentication rejection instead. This is why a login that worked twenty minutes ago and fails now is far more likely to be a connection problem than a password problem. Passwords do not expire quietly between sessions; connection slots fill and empty constantly.

The test that separates them

Stop every client and background application that touches the server, wait roughly a minute for the server side to notice the sockets are gone, then connect with one client set to a single connection. A successful login proves the credentials are correct and the earlier failure was contention over slots. A failure under those conditions puts the fault on the credentials or the account state. This test is worth running before any password is changed, because changing a password while several clients still hold stale sessions produces a confusing mix of both failure modes at once.

Username formats that get rejected

Providers differ in what they consider the username. Some issue a distinct login string, some use the account email address, and some accept either. Entering an email address where a separate username was issued produces 481 with a completely correct password. The mirror image also occurs, where a domain suffix is stripped by a client that assumes the field is a bare name. Credentials for a reseller account are frequently different from the ones used to log into the reseller's billing site, and using the billing login here fails every time.

Account states that produce it

An expired subscription, a block account with its bytes consumed, a suspended account, and an account whose payment failed all present identically as 481 or 502 depending on the server. None of these are visible from the protocol; the account page is the only place to check. Fault here is neither the client's nor a defect on the provider side, and no configuration change will clear it. A reader who has confirmed the credentials with the single-connection test above and still sees 481 should treat the account status as the next thing to verify rather than continuing to adjust client settings.