Dar el visto bueno a un servidor Dovecot recién montado sin una pasada de comprobaciones es la receta clásica para descubrir el fallo tres semanas después, cuando un usuario llama porque su cliente de correo no conecta y nadie sabe por qué. La checklist que sigue está pensada para ejecutarse en orden, con acceso al panel de hosting y a una shell, y cubre los cuatro puntos donde se concentran casi todos los errores reales: mecanismos de autenticación, certificado, ubicación del buzón y tratamiento del correo catch-all. Si algo falla en cualquiera de ellos, el servicio no está listo, por mucho que el demonio arranque y responda en el puerto 993.
Punto de partida: qué debe demostrar Dovecot antes de considerarse operativo
Un Dovecot que arranca no es un Dovecot que funciona. El demonio puede levantar sin quejarse, escuchar en IMAP y POP3, y aun así rechazar todas las credenciales válidas porque el backend de autenticación no encuentra las contraseñas, o aceptarlas y servir un buzón vacío porque mail_location apunta a una ruta que el usuario del proceso no puede leer. La diferencia entre “arranca” y “está listo” se mide con pruebas concretas que reproduzcan el flujo real de un cliente: conexión TLS, autenticación con usuario y contraseña, listado de carpetas, entrega de un mensaje y recuperación del mismo.
Antes de tocar nada, conviene tener claro qué piezas intervienen. Dovecot gestiona la entrega final en IMAP y POP3 y delega la autenticación en su propio proceso de auth, que puede consultar un fichero passwd, una base de datos SQL, un directorio LDAP o un socket de Postfix o Exim. Los registros MX del DNS indican qué hosts aceptan correo para el dominio, y ese es el camino de entrada; el correo saliente lo rigen SPF, DKIM y DMARC, que son otra capa y se validan por separado. La checklist que sigue se centra en la capa de Dovecot, pero sin perder de vista que un fallo de autenticación puede tener su origen en un registro mal puesto en el DNS o en una política DMARC que rechaza el reenvío.
La prueba de humo mínima es siempre la misma: abrir un cliente con TLS obligatorio, autenticar con un usuario real, enviar un mensaje desde fuera al dominio y comprobar que aparece en la bandeja de entrada. Si eso funciona para un usuario normal, se repite para un usuario del dominio que no exista y para el buzón catch-all. Solo entonces se puede decir que el servicio está listo.
Autenticación: auth_mechanisms, TLS obligatorio y el fallo silencioso del certificado
El primer bloque de la checklist es el que más disgustos da porque los síntomas son confusos: el cliente dice “contraseña incorrecta” cuando la contraseña es correcta, o directamente no llega a conectar. La causa casi siempre está en la combinación de auth_mechanisms con el estado del certificado TLS. Dovecot permite desactivar el anuncio de mecanismos en texto plano si no hay TLS, y esa es una decisión sensata; el problema es hacerlo mal y dejar el servidor en un estado en el que solo anuncia mecanismos que el cliente no soporta.
Verificar auth_mechanisms con PLAIN y LOGIN sobre TLS
La directiva auth_mechanisms debe incluir PLAIN y LOGIN, y ambos deben quedar disponibles solo cuando la conexión esté cifrada. En la práctica esto se consigue con ssl = required en el bloque de protocolos o con la directiva disable_plaintext_auth = yes, que impide anunciar PLAIN y LOGIN sin TLS. Comprobar el valor efectivo con doveconf auth_mechanisms y doveconf disable_plaintext_auth es el primer comando de la checklist. Si el resultado es “plain login” y disable_plaintext_auth está en yes, el cliente que conecte por el puerto 143 sin STARTTLS no podrá autenticar, y eso es exactamente lo que se busca.
El error frecuente es dejar disable_plaintext_auth = no para “que funcione todo” en una red interna, y luego olvidar revertirlo cuando el servidor se expone a internet. La comprobación definitiva es conectar con openssl s_client al puerto 993, emitir el comando CAPABILITY y confirmar que AUTH=PLAIN y AUTH=LOGIN aparecen en la lista. Si no aparecen, el cliente moderno caerá a otro mecanismo o fallará; si aparecen en el puerto 143 sin STARTTLS, hay un agujero que hay que cerrar antes de seguir.
El certificado caducado como causa de fallo de autenticación silencioso
Un certificado caducado no siempre produce un error visible. Muchos clientes de correo, cuando la validación del certificado falla, no muestran “certificado caducado”: muestran un error de autenticación genérico o simplemente dejan de sincronizar. El usuario cree que su contraseña ha cambiado y llama al soporte, y el técnico pierde una hora revisando el backend de auth cuando el problema era una fecha. Por eso la checklist incluye una comprobación explícita de la validez del certificado antes de dar el servicio por bueno.
El comando openssl s_client -connect localhost:993 -servername correo.ejemplo.com muestra la cadena completa y la fecha de expiración. Hay que confirmar tres cosas: que la fecha de “notAfter” está en el futuro con margen suficiente, que el nombre del certificado coincide con el hostname que usan los clientes y que la cadena intermedia está completa. Un certificado válido pero sin la cadena intermedia provoca el mismo fallo silencioso en algunos clientes. Si el servidor usa Let’s Encrypt, conviene además revisar que el hook de renovación recarga Dovecot, porque un certificado renovado en disco pero no recargado en el proceso sigue caducado a efectos prácticos.
Buzones: mail_location, permisos y la prueba de entrega real
Con la autenticación resuelta, el siguiente bloque comprueba que el buzón existe, que Dovecot sabe dónde está y que el usuario del proceso puede leerlo y escribirlo. La directiva mail_location define el formato y la ruta; los formatos habituales son Maildir y mdbox, y la ruta debe apuntar a un directorio con los permisos correctos para el usuario virtual o del sistema que ejecuta la entrega. Un mail_location mal puesto no da error al arrancar: da un buzón vacío o un error de “permission denied” en el log cuando el cliente intenta listar carpetas.
La comprobación práctica es doble. Primero, doveadm mailbox list -u usuario@dominio.com debe devolver al menos INBOX, Drafts, Sent y Trash. Segundo, enviar un mensaje desde fuera y confirmar que aparece con doveadm fetch -u usuario@dominio.com “hdr” mailbox INBOX. Si el listado funciona pero la entrega no, el problema está en el LDA o en el LMTP, no en Dovecot como servidor IMAP. Si el listado falla con permission denied, el propietario del directorio y el usuario configurado en mail_uid y mail_gid no coinciden.
Un detalle que se pasa por alto con frecuencia: el directorio de índices y el de control deben ser escribibles por el mismo usuario que el buzón. En configuraciones con mail_location apuntando a /var/mail/%d/%n, el usuario del sistema suele ser vmail y el grupo mail, y un chown mal aplicado deja el buzón en solo lectura. guía de correo catch-all aporta más contexto sobre este asunto. La prueba de entrega real, con un mensaje que incluya un adjunto, confirma que el buzón acepta escritura y que el cliente puede recuperar el mensaje completo por IMAP y por POP3.
Catch-all: cómo encaja en Dovecot y por qué no debe compartir buzón entre usuarios
El correo catch-all es un ajuste en el servidor de correo que hace que el dominio acepte cualquier mensaje enviado a una dirección que no existe. No es una función del DNS: el DNS no tiene ningún tipo de registro para activar catch-all. Lo que hay son registros MX que indican qué hosts aceptan correo para el dominio, y a partir de ahí el servidor de correo decide qué hacer con la parte local que no coincide con ninguna cuenta. La regla catch-all se aplica después de que falla la búsqueda normal de dirección, y solo entonces se entrega al buzón comodín.
En Dovecot, el catch-all se materializa normalmente como una cuenta más o como un alias en el MTA que redirige el correo no coincidente a un buzón concreto. El buzón catch-all se recoge con un solo login POP3 o IMAP, lo que es cómodo para revisar correo perdido pero peligroso si se configura mal. La comprobación clave de la checklist es que el catch-all no comparta buzón entre usuarios: si el buzón comodín es el mismo que el de un usuario real, ese usuario termina viendo correo dirigido a otras personas, y el aislamiento entre cuentas se rompe.
Separar el buzón comodín del buzón personal
La configuración correcta crea una cuenta dedicada, por ejemplo catchall@dominio.com, con su propia ruta en mail_location y su propio login. El MTA redirige a esa cuenta las direcciones no coincidentes mediante una regla en Postfix o Exim, y Dovecot la sirve como cualquier otra. Lo que no debe hacerse es apuntar el catch-all al buzón de un usuario concreto ni usar el mismo mail_location para ambos, porque Dovecot indexa por cuenta y dos cuentas sobre el mismo directorio producen corrupción de índices y mensajes duplicados.
La prueba es sencilla: enviar un mensaje a una dirección inventada del dominio y comprobar que llega al buzón catch-all y no al de ningún usuario. Después, enviar un mensaje a una dirección real y confirmar que llega solo a esa cuenta. Si ambos mensajes acaban en el mismo buzón, la regla está mal. También conviene revisar que el buzón catch-all no se use como destino de reenvío de alias legítimos, porque entonces se mezclan dos flujos distintos y la trazabilidad se pierde.
Integración con el resto de la pila: MTA, DNS y autenticación de correo saliente
Dovecot no vive solo. La entrega final depende de que Postfix o Exim le pasen los mensajes por LMTP o por el LDA, y de que el DNS tenga los registros correctos para que el correo entrante llegue al host adecuado. La checklist incluye una revisión de la integración: que el socket de auth esté accesible para el MTA, que el transporte para el dominio apunte al LMTP de Dovecot y que los registros MX tengan la prioridad esperada. Un MX con prioridad mal puesta puede hacer que el correo llegue a un servidor de respaldo que no tiene las cuentas, y el usuario ve un buzón vacío sin ningún error visible.
En el lado saliente, SPF, DKIM y DMARC rigen el correo que sale del dominio, y su configuración se valida con un mensaje de prueba enviado a una cuenta externa. Un DMARC en modo reject con una alineación mal configurada rechaza el reenvío legítimo, y el síntoma es un correo que nunca llega al destinatario. La comprobación con doveadm auth test usuario@dominio.com contraseña confirma que el backend de autenticación responde, pero no confirma que el correo saliente pase las políticas del dominio; para eso hace falta revisar las cabeceras del mensaje recibido y confirmar que SPF, DKIM y DMARC dan “pass”.
Un punto que merece atención es la diferencia entre correo catch-all, alias, reenvío y correo desechable. Un alias de correo redirige una dirección concreta a otra; un reenvío hace lo mismo pero normalmente hacia fuera del dominio; un correo desechable es una dirección temporal que se descarta tras su uso. El catch-all es distinto: acepta cualquier mensaje enviado a un dominio, coincida o no con una cuenta. Confundir estas figuras lleva a configurar un catch-all donde bastaba un alias, y a acumular correo basura en un buzón que nadie revisa.
Pruebas finales y criterios para dar el servicio por cerrado
La última pasada de la checklist es la que convierte una configuración “que debería funcionar” en un servicio verificado. Se ejecuta desde fuera de la red local, con un cliente real y con las mismas credenciales que usará un usuario. El orden importa: primero TLS, después autenticación, después listado de carpetas, después entrega, después recuperación por POP3 y por IMAP, y por último la prueba del catch-all. Si algo falla, se anota el punto exacto y no se avanza.
Los comandos de verificación que conviene tener a mano son doveconf -n para revisar la configuración efectiva sin comentarios, doveadm auth test para validar credenciales contra el backend, doveadm mailbox list para confirmar que el buzón existe y es legible, y openssl s_client para el certificado y los mecanismos anunciados. En el panel de hosting se confirma que la cuenta tiene el cupo correcto, que el buzón catch-all está activo y que la ruta de mail_location coincide con la que muestra doveconf. Cualquier discrepancia entre lo que dice el panel y lo que dice doveconf es una señal de alarma.
La prueba final que casi nadie hace y que debería ser obligatoria: conectar por IMAP con el usuario catch-all y comprobar que su INBOX no contiene mensajes dirigidos a usuarios reales. Si contiene alguno, la separación de buzones falló y hay que corregirla antes de cerrar. Con eso resuelto, el servidor de correo responde 550 no such user cuando no hay coincidencia y no hay catch-all activo, o entrega al buzón comodín cuando lo hay, y el comportamiento es el esperado en ambos casos.
Si has llegado hasta aquí con todas las casillas marcadas, Dovecot está listo para producción. La rutina que evita sustos es repetir esta checklist cada vez que se renueve el certificado, se cambie de proveedor de DNS o se toque la configuración del MTA. En allmail.one puedes contrastar la configuración de referencia y comprobar que los registros MX, SPF, DKIM y DMARC del dominio están alineados con lo que Dovecot espera; un último vistazo a esos cuatro puntos antes de dar el servicio por cerrado ahorra muchas llamadas de soporte y algún que otro fin de semana perdido.