Recover an email account blocked for suspicious logins

If we detect activity suggesting possible unauthorised use of the mailbox, we may restrict it to contain the incident. Login, receiving and sending are separate controls: do not assume the account is still receiving or that every restriction is lifted by changing the password.

Check which logins caused the restriction

Compare the date, user, access type and the service or device that was connecting. A new location may be a VPN, a mobile network or an app that connects on your behalf: on its own it does not prove a compromise. The guide to suspicious login alerts explains how to recognise that activity.

If the logins are authorised

If you identify the logins that triggered the block as legitimate and there is no other outside activity, you can keep the password you were using or set it again if it was replaced as a precaution.

In cPanel > Email Accounts > Manage, select the affected mailbox. If you need to reset its password, enter it under Security. Under Restrictions, select Allow for login and sending if those are the suspended permissions, and save with Update Email Settings. You do not need to change receiving if it was already allowed.

Recognising one login does not necessarily explain the others. If there is still unidentified activity, sending or changes by someone else, or the password was exposed some other way, follow the recovery in the next section. If you cannot work out what caused the restriction or lift it, contact support.

If you do not recognise the logins or there was a compromise

1. Check where the account was being used from. Check computers, browsers, extensions and apps. The source may be phishing, a reused password or malware. Update and scan your devices; use a trusted one to change the credentials. The guide to compromised passwords helps you review those possibilities.
2. Change the mailbox password to a new, unique one, following how to recover your email password. If it was reused on other services, change the affected credentials there too.
3. Review the activity and rules. Check Sent, Track Delivery, forwarders, filters and autoresponders. Not every SMTP send keeps a copy in Sent, so an empty folder does not rule out abuse.
4. Check pending messages before allowing sending. Check Imunify360 > Email if it is available. If you cannot check the queue, ask support to confirm its status; changing the password does not remove messages that have already been accepted.
5. Review the restrictions in cPanel > Email Accounts > Manage. Restore only the permissions whose cause has been resolved. Do not set outgoing sending to Allow while outside activity remains pending. If the block persists or you cannot change it, contact support.

Reconnect your devices

Update the password on the devices you have checked, for both receiving and SMTP. Make sure no app keeps retrying with the old password.

Test logging in to webmail and sending and receiving with another of your own accounts. Check whether warnings or unfamiliar messages reappear. To look into a failure, give us the affected account, the time and the error text, never the password.