SMTP error 5.7.13 User Account Disabled
The password was right and the account is still switched off. A reply of 525 5.7.13 is the polite way of saying stop retrying and go and speak to an administrator, because re-entering the password will never help. In a Microsoft 365 tenant it maps to a blocked sign-in, a licence that has been removed or a user who has been deleted, and in Google Workspace to a suspended account. The classic version is an offboarding: the leaver is blocked on their last day and three weeks later somebody notices the despatch notifications stopped arriving.
What SMTP error 5.7.13 User Account Disabled actually means
The distinguishing feature is the order of events. Authentication succeeded, and only then did the server refuse, which is why the specification is careful to separate this from a generic credential failure. A client receiving an ordinary authentication error is supposed to prompt for the password again on the assumption the user mistyped it. A client receiving this one is supposed to stop, because the problem is administrative and no amount of typing will move it. Only the permanent class is registered, so there is no transient variant to wait out. Keep it distinct from 5.2.1, which concerns a mailbox that will not accept incoming messages; this code is about an identity that is no longer allowed to sign in and send.
Sometimes a system administrator will have to disable a user's account (e.g., due to lack of payment, abuse, evidence of a break-in attempt, etc). This error code occurs after a successful authentication to a disabled account. This informs the client that the failure is permanent until the user contacts their system administrator to get the account re-enabled. It differs from a generic authentication failure where the client's best option is to present the passphrase entry dialog in case the user simply mistyped their passphrase.
— RFC 5248
How 5.7.13 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 525 5.7.13 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.13 on a business phone system
- Sign-in blocked as part of an offboardingBlocking the account is the correct first move when somebody leaves, and it breaks everything that was quietly authenticating as them. Scanners, accounting software, a booking system and the warehouse label printer are the usual list, and none of them is documented anywhere.
- The licence has been removed or the subscription lapsedThe user object survives licence removal but the mailbox and its service plan do not. A failed card payment on a small tenant produces exactly the same effect across every account at once, which at least makes it easy to spot.
- The account was restricted after a compromiseMicrosoft 365 restricts an account from sending when it detects behaviour consistent with a compromised mailbox, and Google suspends outright. This is the platform protecting you, and clearing it properly matters more than clearing it quickly.
- Disabled in on-premise Active Directory and synchronised upIn a hybrid environment the directory on the ground is authoritative. An account disabled there propagates to the cloud on the next synchronisation cycle, so the change can appear to happen hours after somebody made it and nobody connects the two events.
- Suspended for exceeding sending limitsAn application looping and resending, or a genuine bulk send done through a normal mailbox, trips per-day limits and gets the account suspended. Investigate what generated the volume before asking for it to be lifted, or it will happen again the same week.
How to fix SMTP error 5.7.13
- Identify the account signing in, not the address on the messageThese are frequently different. Read the sign-in name out of the device or application configuration, because the From address it puts on messages tells you nothing about which identity it authenticates with.
- Look at the user object in the admin centreCheck three things in one visit: whether sign-in is blocked, what licences are assigned, and whether the account is flagged as restricted from sending. That covers the great majority of occurrences without any command line work.
- Move the function off a departed person's identityDo not simply re-enable a leaver so the printer works again. Create a dedicated account for the device or application, or convert the mailbox to a shared one where that fits, then block the leaver again properly.
- Work through a compromise fully before unblockingReset the password, revoke active sessions, review inbox rules and forwarding for anything the attacker left behind, and check what was sent whilst they had access. Unblocking first and investigating later usually means doing it all again in a fortnight.
- Build a leaver checklist that lists systems, not just peopleBefore disabling anybody, enumerate what authenticates as them. Ten minutes at offboarding removes an entire class of mystery failure that otherwise surfaces weeks later with no obvious cause.
Fixing the underlying problem
This page explains the code. These guides walk through the fix in detail.
Questions about SMTP error 5.7.13
Will resetting the password fix this?
We deleted a leaver and now an application is failing — what now?
How long should we keep a leaver's mailbox after they go?
Does this affect incoming mail to that person as well?
Related SMTP status codes
- SMTP error 5.2.1Mailbox disabled, not accepting messages
- SMTP error 5.7.0Other or undefined security status
- SMTP error 5.7.8Authentication credentials invalid
Source. SMTP error 5.7.13 User Account Disabled is defined in RFC 5248 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.