Most “email is down” tickets aren’t about sending. They’re IMAP problems. Clients can’t log in, folders disappear, or connections hang on port 993. This Dovecot IMAP troubleshooting tutorial gives you a repeatable workflow for cPanel (WHM) and standard Linux VPS setups. You can usually narrow the failure in minutes.
The steps below assume you manage a VPS or dedicated server. The goal is to fix IMAP without breaking SMTP, webmail, or SSL.
If you’re building a new stack, a HostMyCode VPS gives you root access to what matters most: logs, limits, and TLS files.
What you’ll collect first (2-minute checklist)
Before you change anything, collect a small set of facts. This reduces guesswork and makes rollback easier.
- Scope: one mailbox or many? one domain or all domains?
- Protocol: IMAP over TLS (993), IMAP STARTTLS (143), or POP3 (995/110)? This guide focuses on IMAP.
- Error text: from the client (Outlook/Thunderbird/Apple Mail) and from webmail if applicable.
- Server type: cPanel/WHM (Dovecot + Exim) or “plain” Postfix + Dovecot.
- Time of failure: correlate to logs.
# On the server, note OS and dovecot version
cat /etc/os-release
dovecot --version 2>/dev/null || /usr/sbin/dovecot --version
Dovecot basics on hosting servers (so the rest makes sense)
Dovecot serves IMAP. It handles mailbox access, indexing, and authentication.
On cPanel, it usually authenticates against cPanel-managed accounts. Mail typically lives under user home directories (Maildir).
On a typical VPS mail stack, Dovecot may authenticate via system users, SQL, or virtual users.
Most incidents fall into three buckets:
- Network/TLS: can the client reach 993, and does TLS present the certificate you expect?
- Auth: is the password right, and is the auth backend reachable?
- Mailbox IO: permissions, disk pressure, corrupted indexes, or too many concurrent connections.
Dovecot IMAP troubleshooting tutorial step 1: confirm the service is alive
Start with systemd. If Dovecot is down, pull the last 200 log lines.
Find the cause before you change anything else.
sudo systemctl status dovecot --no-pager
sudo journalctl -u dovecot -n 200 --no-pager
Common “fast wins” you’ll spot immediately:
- Bad config include: a syntax error after a change.
- Port bind failed: another process grabbed 993/143.
- Permission denied: Dovecot can’t read its cert/key or mailbox paths.
# Check ports (993/143) listening
sudo ss -lntp | egrep ':(993|143)\b'
If nothing is listening, a restart is fine. Treat it as a clue, not a fix.
If it restarts and then fails again, suspect config, permissions, or filesystem trouble.
Step 2: prove network reachability (and rule out firewall mistakes)
Test from an external network (a jump box, your laptop, or anywhere not on the server).
This separates “Dovecot is broken” from “port 993 never reaches the box.”
# Quick TCP test
nc -vz mail.example.com 993
# TLS handshake + certificate chain
openssl s_client -connect mail.example.com:993 -servername mail.example.com -showcerts
Healthy results look like this:
- TCP succeeds (connection established).
- Certificate matches the hostname users configured (CN/SAN).
- Reasonable TLS (TLSv1.2+), no “unknown CA” for public certs.
If a firewall change is in play, slow down. Verify each layer.
Check the host firewall, provider security groups, and edge devices.
If you’re on Ubuntu with UFW, this flow is a good companion: UFW firewall troubleshooting on a VPS.
Typical required ports for mail hosting:
- IMAPS: 993
- IMAP (STARTTLS): 143 (optional)
- Submission: 587
- SMTPS: 465 (optional)
- SMTP (server-to-server): 25
Step 3: isolate TLS certificate problems (a top cause of “password failed”)
Many IMAP clients show “incorrect password” when the real issue is TLS trust or a hostname mismatch.
Fix TLS first. It affects every login attempt.
On cPanel, check AutoSSL status and the mail service certificate mapping. If renewals fail or DCV breaks, follow: cPanel AutoSSL troubleshooting.
On a VPS using Certbot, confirm Dovecot points at the correct files. Paths vary by distro and config.
Common locations:
- Let’s Encrypt live cert:
/etc/letsencrypt/live/mail.example.com/fullchain.pem - Let’s Encrypt key:
/etc/letsencrypt/live/mail.example.com/privkey.pem - Dovecot config:
/etc/dovecot/conf.d/10-ssl.conf
# Inspect configured SSL paths (Dovecot)
sudo doveconf -n | egrep '^(ssl =|ssl_cert|ssl_key)'
# Verify the key is readable by dovecot
sudo namei -l /etc/letsencrypt/live/mail.example.com/privkey.pem
If Dovecot can’t read the private key, you’ll usually see “Permission denied” at startup or during the handshake.
Fix permissions without making the key world-readable. Avoid chmod 644 on private keys.
A safer approach is adding the dovecot user to a limited group that can read the key, or using distro-specific “ssl-cert” groups where appropriate.
Step 4: read the right logs (cPanel vs standard Linux)
Client screenshots waste time. Dovecot logs usually explain why it rejected a login or dropped a connection.
On cPanel/WHM servers
- Dovecot log:
/var/log/maillog(common) or/var/log/mail.log(depends) - Auth-related hints also appear alongside Exim logs in the same file
On Ubuntu/Debian VPS mail stacks
- Dovecot:
/var/log/mail.log - Systemd:
journalctl -u dovecot
# Tail and filter for IMAP errors
sudo tail -n 200 /var/log/mail.log 2>/dev/null | egrep -i 'dovecot|imap|auth|ssl|error|warning'
sudo tail -n 200 /var/log/maillog 2>/dev/null | egrep -i 'dovecot|imap|auth|ssl|error|warning'
Patterns worth flagging right away:
- Authentication failures: wrong password, wrong username format, locked mailbox, backend error
- Timeouts: slow client networks, overloaded server, DNS issues
- Mailbox errors: “Internal error occurred”, “Mailbox is locked”, “Corrupted index”
Step 5: reproduce the login with an IMAP command (no GUI required)
A command-line test removes client quirks. It also gives you a clean server response.
# Connect to IMAPS
openssl s_client -connect mail.example.com:993 -servername mail.example.com -crlf -quiet
Then type IMAP commands (example):
a1 CAPABILITY
a2 LOGIN user@example.com 'yourpassword'
a3 LIST "" "*"
a4 SELECT INBOX
a5 LOGOUT
If LOGIN fails, the logs will usually explain why.
If login succeeds but the folder list looks wrong, move to mailbox checks.
Common causes are namespace, permissions, location, or indexes.
Step 6: fix authentication failures (without randomly resetting passwords)
Auth failures tend to come from the same root causes. Work through them in order.
This avoids churn and reduces repeat tickets.
1) Wrong username format
Some stacks require the full email address. Others accept a mailbox name.
Pick a standard and stick to it, especially across migrations.
- Prefer: user@domain.tld as the IMAP username.
- Confirm what Dovecot is receiving by checking logs during a failed attempt.
2) Brute-force protection blocking IMAP
If you run Fail2Ban (common on cPanel and VPS), a user can lock themselves out. This often happens after repeated retries or a recent password change.
Check for bans that match the client IP.
For cPanel environments, keep this guide handy: cPanel Fail2Ban setup guide.
# Generic Fail2Ban check (paths/jail names vary)
sudo fail2ban-client status 2>/dev/null
sudo fail2ban-client status dovecot 2>/dev/null
3) Account lock or exceeded limits (hosting reality)
On shared hosting and reseller servers, “auth failures” can signal account-level problems.
Common examples are suspended cPanel accounts, inode/disk quota exhaustion, or account restrictions.
# Quick disk check (full disks cause strange auth/mailbox behavior)
df -h
# Inode check (Maildir can hit inode limits)
df -i
If quotas are tight, fix the cause instead of bumping limits blindly.
Common culprits include bloated cur/ folders, old attachments, and spam-heavy junk folders.
Step 7: fix timeouts and “too many connections” errors
Timeouts usually point to capacity limits or slow IO.
On busy shared nodes, you can also hit per-IP limits during mobile reconnect storms.
First confirm Dovecot is dropping sessions (not the network path):
# Look for timeout and connection-limit messages
sudo egrep -i 'timeout|disconnected|too many|max connections|imap\(' /var/log/mail.log /var/log/maillog 2>/dev/null | tail -n 60
Quick capacity triage
- CPU steal / saturation:
top,uptime - Memory pressure:
free -h, swapping is a red flag on mail-heavy nodes - Disk latency:
iostat -xz 1(installsysstatif needed)
sudo apt-get update && sudo apt-get install -y sysstat 2>/dev/null || true
iostat -xz 1 5
On smaller VPS plans that run web + mail together, IMAP latency often spikes during backups, WordPress cron bursts, or heavy log rotation.
That’s usually a signal to split workloads or add resources. For multi-tenant hosting or busy agencies, managed VPS hosting can cost less than repeated downtime and support churn.
Tuning connection limits (cautiously)
Connection limits stop one mailbox or one IP from consuming all workers.
Set them too low and normal users on flaky networks will break.
# Inspect active Dovecot settings
sudo doveconf -n | egrep 'mail_max_userip_connections|process_limit|service imap|service imap-login' -n
Common knobs (names vary by version/config):
mail_max_userip_connections: caps connections per user per IPservice imap-login { process_limit }: caps login processesservice imap { process_limit }: caps IMAP worker processes
Change one setting at a time. Then reload and watch logs for 15–30 minutes.
sudo doveadm reload 2>/dev/null || sudo systemctl reload dovecot
Step 8: fix missing folders, duplicated folders, and “INBOX only” views
This issue feels random to users. In practice, it’s usually consistent once you check namespace and subscriptions.
Diagnose namespace and subscription
Some clients hide folders unless they’re subscribed.
Multiple namespaces can also create duplicates (for example, “Sent” and “Sent Messages”).
# List mailboxes as the user (virtual users vary; on cPanel use the full email)
sudo doveadm mailbox list -u user@example.com
# Show subscribed mailboxes
sudo doveadm mailbox list -u user@example.com -s
If folders exist but don’t show up, have the user subscribe to them (Thunderbird makes this easy).
If the folders truly aren’t there, look for migration gaps, a wrong mail path, or a broken namespace configuration.
Check mail location (Maildir path issues)
Migrations and filesystem moves can leave Dovecot pointing at the wrong location.
Confirm the effective mail_location value:
sudo doveconf -n | egrep '^mail_location|^namespace' -n
On many hosting setups, Maildir lives under something like:
/home/USER/mail/(or)/home/USER/mail/DOMAIN/MAILBOX/
If you recently moved accounts between servers, your cutover process matters. Keep DNS changes controlled and predictable.
This helps reduce downtime during migrations: DNS TTL reduction for a safe cutover.
Step 9: repair corrupted Dovecot indexes (safe, common, and effective)
Index corruption shows up as “missing” messages, clients stuck on “loading,” or errors during SELECT.
In most cases, you don’t delete mail. You rebuild indexes.
Identify the user and scope first. Then run a forced resync:
# Resync indexes for the entire mailbox set for a user
sudo doveadm force-resync -u user@example.com '*'
If only one folder is affected:
sudo doveadm force-resync -u user@example.com INBOX
sudo doveadm force-resync -u user@example.com "Sent"
On busy servers, run this during lower traffic. Index rebuilds can be IO-heavy on large mailboxes.
Step 10: permissions and ownership checks (the silent mailbox killer)
Permissions issues often appear after restores, manual copies, or rsync runs as root that didn’t preserve ownership.
Typical symptoms:
- Login succeeds, but folder access fails.
- Webmail works but IMAP clients fail (or the reverse).
- Dovecot logs show “Permission denied” or “Mailbox is locked”.
# Find the mail root for a user first (depends on setup)
# Then inspect permissions; example path:
sudo namei -l /home/username/mail
# Check for obviously wrong ownership (example)
sudo ls -ld /home/username /home/username/mail
If you’re on cPanel, don’t “fix” ownership across an entire tree with generic Linux commands unless you know the expected layout.
Use cPanel tools where you can. Validate with one account before widening the change.
Step 11: practical “one mailbox is broken” workflow
For single-user tickets, aim for a fast path.
Keep it contained so you don’t disturb the rest of the server.
- Test IMAPS handshake with
openssl s_clientagainst the hostname the user configured. - Reproduce login via IMAP commands and capture the timestamp.
- Search logs around that timestamp for auth/ssl/mailbox errors.
- Check quota + inode usage for that account’s home partition.
- Run
doveadm mailbox listanddoveadm force-resyncfor that user.
If the mailbox is business-critical, treat the next steps like production work.
Take a point-in-time backup before any larger mailbox manipulation.
Step 12: prevent repeats (small hardening that helps IMAP reliability)
IMAP reliability comes from boring, consistent maintenance.
- Monitor disk and inode usage and alert before 90%.
- Keep TLS renewed and ensure Dovecot can read the private key after renewals.
- Set realistic connection limits for mobile-heavy users.
- Schedule backups that include mailbox data, and do restore tests.
If you’re running cPanel, configure backups correctly and verify them. The fastest “mail recovery” is a restore you’ve already tested: WHM backup configuration tutorial.
Summary: your IMAP fix path in 15 minutes
Check service health first. Then check network/TLS, then authentication, then mailbox IO.
Don’t skip TLS. Many clients mask certificate problems as bad credentials.
Use doveadm to confirm mailbox visibility and rebuild indexes safely. Let the logs tell you what Dovecot is refusing.
If you keep hitting IO limits or connection ceilings, the fix usually isn’t another tweak. Move mail off an overloaded node or upgrade resources.
A HostMyCode dedicated server (or a properly sized VPS) gives Dovecot enough CPU and disk throughput to stay responsive at peak.
If you’re troubleshooting IMAP issues every week, you’re already paying—just in support time. HostMyCode offers plans that make mail stability easier: start with a right-sized HostMyCode VPS, or offload patching and routine service upkeep with managed VPS hosting.
FAQ
Why does IMAP say “wrong password” when the password is correct?
Many clients surface TLS hostname mismatches or certificate trust failures as an authentication error. Confirm with openssl s_client, then check Dovecot logs for SSL-related messages.
Is it safe to run doveadm force-resync?
Yes. It rebuilds indexes; it doesn’t delete Maildir messages. It can be IO-heavy on large mailboxes, so run it off-peak on busy servers.
Only one user can’t see Sent/Trash folders. Is that a server issue?
Often it’s a subscription or client mapping problem. Use doveadm mailbox list -s to check subscribed folders, and verify the client’s “special folders” settings.
What’s the fastest way to confirm port 993 is blocked?
Run nc -vz mail.example.com 993 from an external network. If TCP fails, inspect your firewall and upstream security groups before changing Dovecot.
Should I host email on the same VPS as WordPress?
For low-volume mail it can work, but shared CPU/disk spikes can trigger IMAP timeouts. If mail is business-critical, split it onto a separate VPS or upgrade resources so Dovecot isn’t competing with PHP and backups.