Dovecot 2.4 Mail Login Failed: Fix Broken Logins on cPanel

cPanel introduced Dovecot 2.4 with version 132 and made it standard across 134, 136 and 138, at the same time as tightening the hash algorithm used for mail account passwords. On most servers the upgrade is invisible. On a minority, mailboxes that had not changed their password in years, or clients using obsolete TLS or authentication mechanisms, stop logging in immediately after upcp. The symptoms look identical from the customer’s side (“wrong password”), so the first job is to separate the causes from the server log.

Short answer: Read the auth failed lines in /var/log/maillog: an unknown or unverifiable password scheme means the mailbox still has an old $1$ or DES hash and needs a password reset with uapi Email passwd_pop, while “no auth attempts” means the client cannot complete a TLS 1.2 handshake and must be updated or reconfigured for port 993 with SSL/TLS. Mechanism errors are fixed on the client by choosing normal password authentication.

Read the Dovecot log for the real reason

Every failed IMAP or POP login writes a line to /var/log/maillog with the reason after auth failed. Pull the last few hours for the affected account:

grep -i 'auth failed' /var/log/maillog | grep 'user@example.com' | tail -20
grep -i 'dovecot' /var/log/maillog | grep -iE 'ssl|tls|proto' | tail -20

The distinguishing phrases are:

• unknown password scheme or Password data is not valid — the stored hash is in a format the new Dovecot cannot verify.
• no auth attempts in 0 secs or disconnected (no auth attempts) — the client never sent credentials, which nearly always means a TLS handshake failure.
• Unsupported authentication mechanism — the client is asking for a mechanism that is now disabled.
• Plain (auth failed, 1 attempts in 2 secs): user=<...>, method=PLAIN with the correct password — the hash exists but does not verify.

The first and last are password-hash problems; the middle two are client or protocol problems.

Password-hash problems

cPanel stores mail passwords in /home/USER/etc/example.com/shadow. Older accounts may have hashes prefixed $1$ (MD5-crypt) or, on very old migrations, plain DES. The 2.4 packaging in cPanel prefers $6$ (SHA-512) and can be configured to refuse weak schemes. Inspect the stored hash prefix:

cut -d: -f1,2 /home/USER/etc/example.com/shadow | awk -F: '{print $1, substr($2,1,3)}'

Anything not starting with $6$ (or $2y$ for bcrypt on newer builds) is a candidate. The fix is a password reset, which rewrites the hash in the current scheme. You can do this without knowing the old password, either per account through cPanel » Email Accounts or in bulk from the shell:

uapi --user=USERNAME Email passwd_pop email=user domain=example.com password='NewStrongPassword'

For a large server, generate a list of all accounts with weak schemes first, then decide whether to reset them with notification or ask customers to reset themselves before a deadline. Resetting silently generates a support storm; announce it.

If you need a stopgap while customers reset, check whether your build exposes a setting to allow legacy schemes in WHM » Service Configuration » Mailserver Configuration. Enabling it lowers security and should be temporary; treat it as a bridge for a week, not a permanent state.

Client TLS and cipher failures

Dovecot 2.4 in cPanel disables TLS 1.0 and 1.1 and drops several weak ciphers. Clients that fail with “no auth attempts” are typically:

• Outlook 2010 or older on Windows 7 with no TLS 1.2 support.
• Old Android mail apps and some multifunction printers or scanners that send to IMAP.
• Anything configured for SSL/TLS on port 143 rather than STARTTLS, or STARTTLS on 993.

Confirm the server side is healthy first:

openssl s_client -connect mail.example.com:993 -tls1_2 </dev/null 2>&1 | grep -E 'Protocol|Cipher'
doveconf -n | grep -E 'ssl_min_protocol|ssl_cipher'

If the server negotiates TLS 1.2 fine, the fix is on the client: update the software, or change the client to port 993 with SSL/TLS and normal password authentication. Re-enabling TLS 1.0 server-wide to accommodate one printer is the wrong trade; if the device really cannot be replaced, an SMTP-only path on port 587 for outbound scans is usually enough.

Authentication mechanism mismatches

Some clients were configured years ago for CRAM-MD5 or NTLM. Dovecot 2.4 in cPanel enables PLAIN and LOGIN over TLS by default. Check the enabled list:

doveconf -n auth_mechanisms

If a customer’s client insists on an encrypted-password mechanism, switch the client to “normal password” (PLAIN over TLS is fully encrypted on the wire). Adding CRAM-MD5 server-side requires plaintext-recoverable password storage, which cPanel does not support, so this is not a server-side fix.

Sieve and Roundcube side-effects

Because 2.4 arrived with Pigeonhole Sieve integration in Roundcube, an upgrade also enables the managesieve service on port 4190. If a customer’s login works in a mail client but Roundcube shows a filter error, it is a different problem covered in Setting up Dovecot Sieve filters. Webmail login loops themselves are usually a Roundcube database issue, covered in our Roundcube guide.

A common pitfall: mixed cPanel builds behind one MX

Providers with an inbound mail proxy or a hot spare that still runs Dovecot 2.3 will see intermittent logins fail only for some users. The affected users are those whose passwords were reset on the 2.4 box in a scheme the 2.3 box cannot verify. Keep all servers that share mailbox storage or password files on the same major version; do not run a 2.3 secondary against 2.4 hashes.

Verify

For each fixed account, test directly rather than relying on the customer’s client:

curl -s --url 'imaps://mail.example.com/INBOX' --user 'user@example.com:NewStrongPassword' -X 'STATUS INBOX (MESSAGES)'

A * STATUS line back means authentication and TLS both work. Then re-check the log for new auth failed lines for that user over the following hour. Server-wide, count failures before and after:

grep -c 'auth failed' /var/log/maillog

If the count keeps climbing for many distinct users, the hash scheme is still the problem and a bulk reset is warranted. Keep an eye on whmapi1 version after the next update as well; Dovecot minor versions (2.4.5 shipped with 138) occasionally adjust defaults, and the changelog for your build will say if anything in the auth path moved again.

Dovecot 2.4 mail login failed at a glance

Official documentation: Dovecot documentation, cPanel & WHM documentation, RFC 5321 (SMTP).

Related guides: Exim outbound mail limits in WHM: hourly caps, X-Source tracking and “nobody” restrictions that stop spam runs · Warm up a new mail server IP or sending domain without landing in spam · Setting up MailBaby with cPanel/WHM Exim: router, transport, SRS and DKIM.

Frequently asked questions