Dovecot IMAP Login Fails: Where Auth Breaks and How to Fix It

How Dovecot IMAP auth actually works (and where it breaks)

Dovecot authentication is a pipeline. Your client speaks IMAP to the IMAP service. That service hands credentials to Dovecot’s auth service. Auth consults one or more passdb backends to verify the secret, then one or more userdb backends to map the user to a UID/GID/home/mail location. Then the IMAP process tries to open the mailbox with those credentials and filesystem permissions. If any stage fails, the user experiences the same thing: “Login failed.” Which is why you can’t troubleshoot this by vibes.

The stages you need to keep straight

1. Network/TLS stage: client reaches the server; TLS negotiates if required.
2. IMAP protocol stage: client sends LOGIN/AUTHENTICATE; server offers mechanisms (PLAIN, LOGIN, SCRAM, OAUTHBEARER, etc.).
3. Dovecot auth stage: the auth process (and its workers) runs passdb checks.
4. User mapping stage: userdb resolves UID/GID/home/mail path; optional extra fields (quota, namespaces, ACLs) may be injected.
5. Mailbox access stage: Dovecot opens mail storage (Maildir, mdbox, sdbox, etc.), acquires locks, reads indexes.

You’re hunting for the first stage that fails. Everything after that is collateral damage.

One opinion worth adopting: treat auth failures as an observability problem first, and a configuration problem second. You don’t fix what you can’t see.

One quote to keep you honest: “Hope is not a strategy.” — Gen. Gordon R. Sullivan

Short joke #1: Authentication bugs are like onions: they have layers, and they make someone cry. Usually the on-call.

Fast diagnosis playbook (first/second/third checks)

This is the shortest path to a root cause when IMAP logins fail. Run it in order. Don’t skip steps because you “already know.” That’s how incidents get promoted from annoying to legendary.

First: confirm what is actually failing (TLS, auth, or mailbox)

• Check logs for the canonical error line (auth failed vs. userdb vs. mail permission).
• Reproduce with a known-good client path (doveadm auth test and an IMAP openssl s_client check).

Second: isolate Dovecot auth pipeline (passdb/userdb)

• Use doveconf -n to see the active config (not what you think you deployed).
• Test passdb (password verification) and test userdb (UID/GID/home/mail).
• Watch for worker failures (timeouts, auth socket perms, SQL/LDAP connectivity).

Third: validate storage access as the mapped user

• Confirm the UID/GID Dovecot chooses and whether that user can read the mail store.
• Look for lock/index errors that masquerade as login problems (especially with mdbox and NFS-like storage).

If you do just these three steps, you’ll solve most “IMAP login failed” tickets with less drama and fewer “let’s restart everything” rituals.

Interesting facts and historical context (short, useful, and mildly nerdy)

• IMAP predates modern “identity” stacks. IMAP grew up with simple username/password auth; bolting on OAuth is a late-career makeover.
• Dovecot became popular partly because it’s careful with mail storage. Performance and mailbox integrity were major differentiators versus older IMAP servers in many deployments.
• CRAM-MD5 exists because plaintext passwords were scary even in the 1990s. It’s also a reminder that “legacy secure” can be “modern liability.”
• STARTTLS on IMAP (port 143) is historically common in enterprises. But implicit TLS on 993 is operationally simpler because fewer middleboxes mangle it.
• Dovecot’s auth is split into master/auth/worker processes. That separation reduces blast radius: a crashing auth worker shouldn’t take down your entire IMAP service.
• Maildir vs mdbox isn’t just preference. It changes locking behavior, index patterns, and failure modes (especially on networked storage).
• “userdb” is not optional in practice. Even when passdb succeeds, a bad userdb mapping can make logins fail or mail open errors look like auth issues.
• UID/GID mismatches are a classic post-migration failure. Old servers and new servers disagree on numeric IDs, and maildirs don’t care about your feelings.

Practical tasks: commands, expected output, and decisions (12+)

These are field-tested tasks you can run under pressure. Each one includes: the command, what output means, and what decision you make next.

Task 1: Confirm Dovecot is actually running and listening

cr0x@server:~$ systemctl status dovecot
● dovecot.service - Dovecot IMAP/POP3 email server
     Loaded: loaded (/lib/systemd/system/dovecot.service; enabled)
     Active: active (running) since Mon 2026-01-03 09:12:19 UTC; 2h 3min ago
...

Meaning: If it’s not active, you don’t have an “auth problem,” you have a “service is down” problem.

Decision: If inactive/failed, inspect journalctl -u dovecot before restarting. If active, move on.

cr0x@server:~$ ss -lntp | egrep ':143|:993'
LISTEN 0 100 0.0.0.0:143 0.0.0.0:* users:(("dovecot",pid=1123,fd=45))
LISTEN 0 100 0.0.0.0:993 0.0.0.0:* users:(("dovecot",pid=1123,fd=46))

Meaning: Ports are bound. If 993 is missing, TLS-only clients fail. If 143 is missing, STARTTLS deployments fail.

Decision: Match what clients expect. Don’t guess; verify the client config or the last known-good baseline.

Task 2: Read the last 200 Dovecot log lines like a human

cr0x@server:~$ journalctl -u dovecot -n 200 --no-pager
Jan 03 10:58:12 mail dovecot[22144]: imap-login: Disconnected (auth failed, 1 attempts): user=<alice@example.com>, method=PLAIN, rip=203.0.113.50, lip=192.0.2.10, TLS, session=<...>
Jan 03 10:58:14 mail dovecot[22144]: auth: passwd-file(alice@example.com,203.0.113.50): unknown user

Meaning: The IMAP login service reports “auth failed”; the auth service says “unknown user.” That’s not a bad password; that’s a lookup failure.

Decision: Focus on passdb/userdb configuration and identity normalization (usernames, domains), not password hashes.

Task 3: Dump the effective Dovecot config (not the one you think you deployed)

cr0x@server:~$ doveconf -n
auth_mechanisms = plain login
disable_plaintext_auth = yes
mail_location = maildir:/var/vmail/%d/%n/Maildir
passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
ssl = required

Meaning: This is the truth Dovecot is running with. doveconf -n shows overrides and resolved values.

Decision: If the config doesn’t match expectations, stop. Fix deployment/config management first; troubleshooting the wrong config is performance art.

Task 4: Test auth without IMAP clients (passdb verification)

cr0x@server:~$ doveadm auth test alice@example.com 'CorrectHorseBatteryStaple'
passdb: alice@example.com auth succeeded
extra fields:
  user=alice@example.com

Meaning: Password verification works. If IMAP still fails, the break is likely TLS, SASL mechanism mismatch, userdb mapping, or mailbox access.

Decision: Run a userdb lookup next, then reproduce via IMAP with debug logs.

cr0x@server:~$ doveadm auth test alice@example.com 'wrongpassword'
passdb: alice@example.com auth failed

Meaning: That’s a real password failure. Now you check hashing, SQL query correctness, or upstream identity provider if applicable.

Decision: Don’t touch filesystem permissions yet. You haven’t earned that detour.

Task 5: Test userdb mapping (UID/GID/home/mail location)

cr0x@server:~$ doveadm user alice@example.com
field	value
uid	vmail
gid	vmail
home	/var/vmail/example.com/alice
mail	maildir:/var/vmail/example.com/alice/Maildir

Meaning: Dovecot knows where the mailbox should live and under which user/group it will access it.

Decision: If UID/GID are missing or wrong, fix userdb query or static mapping. If they look right, validate the filesystem next.

Task 6: Validate SQL connectivity and the exact queries Dovecot runs

cr0x@server:~$ doveadm -Dv auth test alice@example.com 'CorrectHorseBatteryStaple'
...
sql(alice@example.com): query: SELECT username, password FROM users WHERE username = 'alice@example.com'
sql(alice@example.com): result: username=alice@example.com password={BLF-CRYPT}$2y$10$...
passdb: alice@example.com auth succeeded
...
sql(alice@example.com): query: SELECT home, uid, gid FROM users WHERE username = 'alice@example.com'
sql(alice@example.com): result: home=/var/vmail/example.com/alice uid=vmail gid=vmail

Meaning: You can see real queries and results. This is gold when your SQL config “looks right” but isn’t.

Decision: If queries return no rows, fix schema/where clause/username normalization. If they’re slow, check DB latency and indexes.

Task 7: Check auth worker health and timeouts

cr0x@server:~$ journalctl -u dovecot --no-pager | egrep 'auth-worker|timeout|BUG|panic' | tail -n 30
Jan 03 10:41:02 mail dovecot[1128]: auth-worker(21987): Error: sql(alice@example.com): Connection timed out
Jan 03 10:41:02 mail dovecot[1128]: auth: Error: auth-worker exited unexpectedly

Meaning: Your auth failures are downstream of dependency timeouts. The DB/LDAP is the real incident.

Decision: Treat this like a dependency outage: check DB reachability, pool limits, TLS to DB, and network policy.

Task 8: Reproduce an IMAP login manually over TLS to separate protocol/TLS from Dovecot internals

cr0x@server:~$ openssl s_client -connect 127.0.0.1:993 -crlf -quiet
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
a login alice@example.com "CorrectHorseBatteryStaple"
a OK [CAPABILITY IMAP4rev1 SASL-IR ...] Logged in

Meaning: TLS works, and IMAP login succeeds from localhost. If remote users still fail, you likely have firewall/NAT/TLS interception issues or client-side mechanism constraints.

Decision: Compare remote path vs local path. Check certificates, SNI, and whether a load balancer terminates TLS correctly.

cr0x@server:~$ openssl s_client -connect 127.0.0.1:993 -crlf -quiet
* OK Dovecot ready.
a login alice@example.com "wrongpassword"
a NO [AUTHENTICATIONFAILED] Authentication failed.

Meaning: Now you have a clean reproduction of a real auth failure. The logs should line up with this session.

Decision: Enable targeted auth debug and re-test once, not for an hour.

Task 9: Check TLS certificate validity and chain quickly

cr0x@server:~$ openssl s_client -connect mail.example.com:993 -servername mail.example.com -showcerts /dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = mail.example.com
issuer=CN = Example Issuing CA
notBefore=Dec 15 00:00:00 2025 GMT
notAfter=Mar 15 23:59:59 2026 GMT

Meaning: If the cert is expired or wrong CN/SAN, many clients will fail before auth even begins.

Decision: Fix the certificate and chain first. Don’t “work around” TLS failures with plaintext auth in 2026.

Task 10: Verify the auth socket permissions (common when integrating Postfix SASL too)

cr0x@server:~$ ls -l /var/spool/postfix/private/auth
srw-rw---- 1 postfix dovecot 0 Jan  3 10:12 /var/spool/postfix/private/auth

Meaning: Socket exists and is writable by Postfix. Wrong ownership/mode causes SASL auth failures for SMTP, and sometimes people confuse that with IMAP login issues.

Decision: If permissions are wrong, fix service auth { unix_listener ... } and reload Dovecot.

Task 11: Confirm the mapped mailbox path exists and is accessible

cr0x@server:~$ getent passwd vmail
vmail:x:5000:5000::/var/vmail:/usr/sbin/nologin

cr0x@server:~$ sudo -u vmail test -d /var/vmail/example.com/alice/Maildir && echo OK || echo NO
OK

Meaning: The mailbox exists and the runtime user can see it. If this fails, Dovecot may authenticate the password but still refuse the login or error right after.

Decision: Fix ownership/permissions, or fix userdb mapping so Dovecot points to the real location.

Task 12: Look for “looks like auth” but is actually mailbox/index corruption or lock errors

cr0x@server:~$ journalctl -u dovecot --no-pager | egrep 'Permission denied|Corrupted|Mailbox is locked|Index' | tail -n 40
Jan 03 11:02:31 mail dovecot[23102]: imap(alice@example.com): Error: open(/var/vmail/example.com/alice/Maildir/dovecot.index) failed: Permission denied

Meaning: Auth might be fine; mailbox open is failing. Users still experience it as “can’t log in” because the session drops immediately after login or during SELECT INBOX.

Decision: Fix filesystem ACLs/ownership. Then consider rebuilding indexes if needed (carefully).

Task 13: Turn on targeted auth debug (safely) to catch the exact break

cr0x@server:~$ sudo doveconf -n | egrep 'auth_debug|auth_verbose|mail_debug'

cr0x@server:~$ sudo sed -i 's/^#\?auth_verbose.*/auth_verbose = yes/' /etc/dovecot/conf.d/10-logging.conf
cr0x@server:~$ sudo sed -i 's/^#\?auth_debug.*/auth_debug = yes/' /etc/dovecot/conf.d/10-logging.conf
cr0x@server:~$ sudo systemctl reload dovecot

Meaning: You’ve increased auth visibility. Do this briefly in production; it can leak metadata into logs.

Decision: Reproduce once, capture the relevant lines, then turn it back off.

Task 14: Validate PAM behavior when using system users (common on smaller systems)

cr0x@server:~$ doveconf -n | egrep 'passdb|pam'
passdb {
  driver = pam
}

cr0x@server:~$ sudo tail -n 50 /var/log/auth.log
Jan 03 11:11:10 mail dovecot: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser= rhost=203.0.113.50  user=bob

Meaning: PAM is rejecting the login. The failure may be wrong password, locked account, expired password policy, or PAM module order.

Decision: Check account status and PAM stack. Don’t “fix” Dovecot when PAM is doing exactly what it was told.

Where auth breaks: failure modes by stage

Stage 1: Network and TLS (the failures that look like “auth”)

Clients often collapse connectivity and authentication into the same user-facing error. Your job is to separate them.

• Firewall/NAT: Some users succeed, others fail. Check security groups and geo/IP allowlists.
• TLS handshake mismatch: Old clients require legacy ciphers; modern servers refuse them. Or a middlebox terminates TLS and re-encrypts with a different cert.
• SNI/certificate mismatch: Multi-domain setups fail if the client hits the wrong name or the proxy doesn’t pass SNI.

Fix TLS first. Disabling TLS requirements to “get users in” is like removing brakes to make the car go faster downhill.

Stage 2: IMAP mechanism negotiation

Dovecot advertises mechanisms via CAPABILITY. Clients choose based on policy. The mismatch patterns are predictable:

• disable_plaintext_auth = yes with no TLS: client tries PLAIN/LOGIN without encryption and gets rejected.
• Mechanisms removed: you disabled LOGIN and the client can’t do PLAIN with SASL-IR, or can’t do SCRAM. Result: “authentication failed” but really “no compatible mechanism.”
• OAuth/OAUTHBEARER: modern clients may try OAUTHBEARER first; if your backend is half-configured, you’ll see confusing fallbacks.

Stage 3: passdb failure (real authentication problems)

passdb is where the secret is checked. Failures are usually:

• User not found: SQL/LDAP query returns no row. Common causes: wrong filter, wrong domain, unexpected username format, trailing spaces, or case sensitivity.
• Password hash mismatch: hash scheme mismatch (bcrypt vs SHA512-CRYPT), wrong query field, or the stored hash got “helpfully” re-encoded.
• Dependency failure: DB timeouts, LDAP TLS failures, DNS issues, connection pool exhaustion.

Stage 4: userdb failure (you authenticated, now you can’t become a user)

This is the quiet killer. passdb says yes, userdb says “I don’t know what you are,” and the session dies.

• Missing UID/GID: Dovecot can’t determine which user to run as, or uses defaults that don’t match mailbox ownership.
• Wrong home/mail path: userdb points to a non-existent path, or one server uses /var/mail/vhosts while another uses /var/vmail.
• Per-user overrides gone wrong: you inject mail field or namespace settings per user and accidentally break a subset.

Stage 5: mailbox access failure (auth succeeded, reality refused)

Classic signs: users “log in” but immediately get disconnected, or INBOX can’t be selected, or only some folders work.

• Filesystem permissions: wrong UID/GID, missing execute bit on directories, ACLs not applied, or SELinux/AppArmor denial.
• Index and lock issues: corrupted indexes, lock timeouts, or storage that doesn’t honor POSIX locking semantics.
• Quota plugin behavior: quota warnings or hard failures may prevent appends; some clients interpret that as “login problems.”

Short joke #2: If you “fixed” IMAP by restarting Dovecot, congratulations—you’ve discovered the IT equivalent of turning it off and on again.

Common mistakes: symptom → root cause → fix

1) Symptom: “Authentication failed” immediately for all users

Root cause: passdb backend unreachable (SQL/LDAP down, DNS failure, TLS to DB broken), or auth workers can’t connect.

Fix: Confirm with doveadm -Dv auth test and logs showing timeouts. Restore DB/LDAP connectivity, check firewall rules, and verify credentials in dovecot-sql.conf.ext.

2) Symptom: Only remote users fail; localhost tests succeed

Root cause: TLS interception/proxy misconfiguration, SNI mismatch, or network policy differences (WAF, geo-blocking).

Fix: Compare openssl s_client from a remote host, verify cert chain, and ensure the proxy passes SNI and ALPN as expected.

3) Symptom: “Unknown user” for users that exist

Root cause: wrong username normalization: client sends alice but DB stores alice@example.com, or vice versa; or domain stripping added/removed during migration.

Fix: Decide on canonical username format. Update Dovecot auth_username_format and SQL/LDAP queries accordingly. Verify with debug output showing the query.

4) Symptom: Some users can log in; others can’t; pattern matches a domain

Root cause: multi-domain mapping bug: %d handling in mail_location, missing domain row in DB, or proxy/virtual host config mismatch.

Fix: Run doveadm user user@domain for affected domains and compare resolved home/mail paths.

5) Symptom: Login succeeds, then immediate disconnect or “Mailbox doesn’t exist”

Root cause: userdb points to wrong mailbox path; or mail storage permissions deny Dovecot from reading indexes.

Fix: Validate doveadm user fields, then sudo -u vmail test directory access. Correct ownership and paths.

6) Symptom: Works for a while, then auth starts timing out under load

Root cause: auth worker saturation: DB connection pool limits, slow password hashing cost, or LDAP response latency. Dovecot’s auth workers queue up.

Fix: Measure DB latency, add indexes, tune pool sizes, and consider caching carefully. Increase auth worker processes only after confirming the backend can handle it.

7) Symptom: “Plaintext authentication disallowed”

Root cause: disable_plaintext_auth = yes with clients attempting LOGIN/PLAIN without TLS, often due to STARTTLS not being used.

Fix: Enforce implicit TLS on 993 or ensure STARTTLS is enabled and clients are configured to require it. Don’t relax security to accommodate broken clients without a plan.

8) Symptom: After migration, everyone’s password “stopped working”

Root cause: hash scheme mismatch, or the DB field content got transformed (truncated, encoding changed, whitespace added).

Fix: Confirm hash schemes Dovecot supports and the stored format. Test a user with doveadm auth test and confirm the returned hash prefix matches the expected scheme.

Three corporate mini-stories from production life

Incident caused by a wrong assumption: “It’s just the password”

The ticket storm started on a Monday morning, which is already a crime. A regional office couldn’t log into IMAP after a “routine security change.” The helpdesk narrative was clean: “Passwords aren’t working.” So the first response was predictably messy: resets, more resets, and a few executive resets for good measure.

On the mail side, nothing was obviously down. Dovecot ran fine. SQL was reachable. doveadm auth test succeeded for multiple users. That’s the moment the story shifts: it’s not passwords. It’s the client path.

Turns out the “routine security change” was a TLS inspection policy pushed to that office’s outbound proxy. The proxy re-signed certificates with an internal CA that their Windows machines trusted, but several mobile clients didn’t. Those clients failed the TLS handshake and reported “authentication error” because the app’s UX team decided that was close enough.

The fix wasn’t in Dovecot. The fix was: stop intercepting IMAPS, or deploy the CA to the devices that need it, and make the policy explicit. The important lesson: if local IMAP login works but remote fails, you’re not debugging authentication—you’re debugging the path between the user and the port.

Also, stop resetting passwords as a diagnostic tool. It destroys signal and trains the org to solve technical problems with ritual.

Optimization that backfired: “Let’s crank up auth workers”

A different environment had intermittent login failures during peak hours. Dovecot logs showed auth timeouts talking to the SQL backend. Someone noticed that Dovecot had configurable auth worker processes and decided to “increase parallelism” as an optimization. They pushed more workers and declared victory after five calm minutes.

Peak hour arrived again, and the system faceplanted harder. Why? Because the database wasn’t slow due to lack of concurrency—it was slow due to contention. More auth workers meant more concurrent SQL connections, which meant more lock contention, which meant slower queries, which meant longer auth queues. The auth service didn’t just fail; it failed loudly.

The eventual fix was boring and effective: add the right index for the username lookup, reduce query cost, and size the DB connection pool with intention. Dovecot’s worker count returned to a sane value. The system stabilized without theatrics.

The lesson: if your backend is the bottleneck, parallelism is not a free lunch. It’s an invoice with interest.

Boring but correct practice that saved the day: “We had a known-good auth test and logs”

A mail cluster upgrade introduced a subtle regression: a subset of users could authenticate but got disconnected when accessing INBOX. The incident could have gone sideways quickly because the symptom looked like auth failure in client apps. But the team had a habit that sounds dull until you need it: a pre-upgrade and post-upgrade checklist with doveadm tests and a small bank of synthetic accounts.

Within minutes, they confirmed that passdb worked and userdb mapping returned correct values. Then they used one of the synthetic accounts to log in via openssl s_client and saw an error right after login: an index permission denial in the new mail location. That narrowed it to filesystem layout/permissions, not credentials.

The root cause was a missed step in the deployment: a directory creation routine ran as root and created new per-user index directories with root ownership. Existing users had old directories owned by vmail, but newly touched users got root-owned paths. Classic split-brain-by-ownership.

The fix was a targeted ownership correction and a deployment hook to create directories with the correct UID/GID. No password resets. No random restarts. Just controlled diagnosis and a change that made the system less fragile.

The lesson: test the boring things before you ship. It’s cheaper than an incident bridge call where everyone says “it worked yesterday” like that’s a metric.

Checklists / step-by-step plan (boring on purpose)

Step-by-step plan when IMAP login fails

1. Confirm scope: one user, one domain, one network segment, or global?
2. Capture a single reproduction: time, username, source IP, client type, and whether it’s 993 or STARTTLS on 143.
3. Check Dovecot logs first: identify whether it says auth failed, unknown user, userdb missing, or permission denied.
4. Run doveconf -n: verify you’re troubleshooting the active configuration.
5. Run doveadm auth test: confirm passdb behavior independent of IMAP.
6. Run doveadm user: confirm userdb mapping and mail location fields.
7. Reproduce via openssl s_client: validate TLS and IMAP capability/mechanism negotiation.
8. Check backend dependencies: SQL/LDAP reachability, timeouts, TLS, credentials, pool limits.
9. Check filesystem permissions as the runtime user: home, maildir, and index files.
10. Enable targeted auth debug briefly if needed: reproduce once, capture, disable debug.
11. Fix the root cause: config, backend, or permissions—not symptoms.
12. Verify with three paths: doveadm, localhost IMAPS, remote IMAPS.

Operational checklist for changes that commonly break auth

• TLS certificate renewals: verify notAfter dates and chain before rollout.
• DB schema changes: verify the exact Dovecot SQL queries still return rows.
• Username format changes: decide canonical format and enforce it consistently.
• Storage migrations: verify UID/GID ownership, and test mailbox open, not just auth.
• Proxy/LB changes: confirm SNI, pass-through vs termination, and source IP logging.
• Security hardening: check auth_mechanisms and client compatibility before disabling legacy methods.

FAQ

1) Why does Dovecot say “auth failed” when the real problem is TLS?

Many clients map any connection failure to “authentication.” Dovecot logs plus an openssl s_client test are how you separate TLS handshake issues from real passdb failures.

2) What’s the difference between passdb and userdb, and why should I care?

passdb answers “is this password/token valid?” userdb answers “what UID/GID/home/mail path does this user map to?” You need both. passdb succeeding doesn’t guarantee the mailbox can be opened.

3) I can authenticate with doveadm auth test but IMAP still fails. Now what?

Test TLS and IMAP negotiation via openssl s_client, then check doveadm user and filesystem permissions. This pattern usually means mechanism/TLS mismatch or mailbox access problems.

4) What does “unknown user” usually mean?

Your passdb lookup returned no result. Common causes: wrong SQL WHERE clause, wrong LDAP filter, username format mismatch (missing domain), or case/whitespace issues.

5) Should I enable auth_debug in production?

Briefly, for a controlled reproduction, yes. Leave it on for hours, no. It increases log volume and can leak sensitive metadata. Turn it on, reproduce once, capture, turn it off.

6) Users can log in but some folders fail or clients disconnect. Is that authentication?

Usually no. That’s mailbox open/index/permission trouble. Look for “Permission denied,” “Mailbox is locked,” and index errors in logs.

7) How do I know if my SQL backend is the bottleneck?

Dovecot logs will show SQL timeouts or slow queries under -Dv output. If auth failures correlate with DB latency spikes, treat it as a dependency capacity problem, not a Dovecot tuning contest.

8) Is it okay to allow plaintext auth to fix user complaints?

No, not as a “fix.” If you must temporarily relax settings to unblock a migration, do it with a time box and a rollback plan. The real fix is ensuring TLS works and clients are configured correctly.

9) How do I differentiate a bad password from a hash scheme mismatch?

With doveadm -Dv auth test you can see the returned hash and whether Dovecot recognizes the scheme prefix. If the scheme is wrong or the hash is malformed, even correct passwords will fail.

Conclusion: practical next steps

When Dovecot IMAP logins fail, stop arguing with the symptom and start locating the break in the chain. Check logs, confirm the active config, test passdb and userdb independently, validate TLS, and only then go spelunking in filesystem permissions and indexes.

Next steps you can do today:

• Save a runbook version of the Fast diagnosis playbook and the command tasks above.
• Create two synthetic test accounts per domain and automate doveadm auth test plus an IMAPS openssl s_client login check.
• Baseline and monitor auth latency (DB/LDAP response times, worker timeouts) so you see the failure before users do.
• Standardize username format and document it like it’s an API contract—because it is.

Do that, and the next “IMAP login failed” page becomes a short investigation, not a career moment.