A mailbox login failure can come from credentials, TLS, network filtering, suspension or the Dovecot service itself. Compare one controlled login with the matching server log entry to identify which layer rejected the connection.
IN THIS ARTICLE
Gather the details you will need
Confirm the mailbox full address and the configured IMAP or POP hostname. Do not request or paste a customer password into logs or a support ticket. Record the client error, time, source IP and whether webmail has the same symptom.
01 Diagnose Dovecot login errors on DirectAdmin
- Try one login through trusted webmail or a configured mail client using the documented secure connection settings. Repeated guesses can trigger brute-force protection.
- Inspect the appropriate Dovecot entries in
/var/log/maillog, the system journal or the log destination configured for this server. Match the timestamp and account rather than reading an unrelated failure. - If authentication is rejected, verify the mailbox exists, is not suspended and uses the correct full username. Reset its password through the authorized panel only when necessary, then update legitimate clients.
- If no connection reaches Dovecot, check hostname resolution, the listener and applicable firewall or brute-force block. If TLS fails, compare the requested hostname with the installed mail certificate and chain.
- For an authenticated session that fails when opening mail, investigate quota, storage, permissions or index errors separately. Preserve mailbox data before any corrective maintenance.
02 Example: inspect the IMAP listener and recent Dovecot events
On a self-managed DirectAdmin Linux server, an authorised administrator can inspect IMAPS and its service log. The sample uses the common dovecot.service unit and TCP port 993. Adjust them only to match the installed service and documented mail settings.
sudo ss -ltnp 'sport = :993'
sudo journalctl -u dovecot.service --since '-10 minutes' --no-pager -n 60Read the result: A listener confirms that a process has bound the port in this namespace; it does not prove a customer can authenticate. Correlate the time of one controlled login with the log entry. If this server writes mail events to /var/log/maillog or another configured file, inspect that destination instead.
Keep mailbox passwords out of the shell and support transcript. If the TLS handshake fails before authentication, inspect the mail hostname and certificate separately. If no attempt reaches the server, investigate DNS, routing and access controls before resetting the mailbox password.
Why does webmail work while my phone fails?
The phone may use an old password, different hostname, incompatible TLS settings or a blocked source IP. Compare those settings and connection paths before changing the mailbox itself.
Confirm the intended access works
Confirm a secure login succeeds and test reading a harmless message. Check that the corresponding successful session appears in logs and that the client is no longer retrying old credentials. Test another unaffected mailbox to establish the scope.
If the problem continues
Do not delete Maildir contents or rebuild every mailbox index to fix an ordinary password error. Dovecot versions and log formats change, so use installed-version documentation for deeper repair. Share only sanitized log lines showing the failure reason and relevant account context.