--- title: "Cómo analizar los logs de Postfix y Dovecot en Ubuntu" description: "Aprende a leer los logs de Postfix y Dovecot en Ubuntu 24.04, seguir un mensaje por su ID de cola y diagnosticar rebotes, retrasos y fallos de autenticación." category: "Servidor de Correo" language: es source: https://cubepath.com/es/docs/servidor-de-correo/analisis-y-diagnostico-de-logs-de-correo updated: 2026-09-25 --- # Cómo analizar los logs de Postfix y Dovecot en Ubuntu Cuando un correo no llega, llega tarde o un cliente no puede iniciar sesión, la respuesta casi siempre está en los logs del servidor. En este tutorial aprenderás dónde escriben sus logs Postfix y Dovecot en Ubuntu 24.04, cómo interpretar cada línea, cómo seguir un mensaje concreto de principio a fin y cómo diagnosticar los problemas más habituales: rebotes, mensajes en cola y ataques de fuerza bruta contra SMTP e IMAP. ## Requisitos previos - Un servidor con Ubuntu 24.04 LTS con Postfix y Dovecot ya instalados y funcionando, por ejemplo un VPS de CubePath. - Un usuario no root con privilegios `sudo`. - Conocimientos básicos de la terminal (`grep`, `less`, tuberías). Los ejemplos también sirven para Debian 12. En Rocky Linux 9 el archivo equivalente es `/var/log/maillog`. ## Paso 1: Localizar los logs de correo Postfix y Dovecot envían sus mensajes a syslog con la facilidad `mail`. En Ubuntu, rsyslog los escribe en `/var/log/mail.log`, y también quedan en el journal de systemd. Comprueba que el archivo existe y se está escribiendo: ```bash ls -lh /var/log/mail.log* ``` ```output -rw-r----- 1 syslog adm 1.2M Sep 25 10:40 /var/log/mail.log -rw-r----- 1 syslog adm 4.8M Sep 21 00:00 /var/log/mail.log.1 -rw-r----- 1 syslog adm 612K Sep 14 00:00 /var/log/mail.log.2.gz ``` Los archivos `.1` y `.gz` son rotaciones anteriores, gestionadas por logrotate según `/etc/logrotate.d/rsyslog`. Si `/var/log/mail.log` no existe, rsyslog no está instalado; puedes instalarlo con `sudo apt install rsyslog` o trabajar directamente con `journalctl`, como se ve más abajo. El archivo pertenece al grupo `adm`. Para leerlo sin `sudo`, añade tu usuario a ese grupo y vuelve a iniciar sesión: ```bash sudo usermod -aG adm $USER ``` Para ver los mensajes en tiempo real mientras envías un correo de prueba, usa `tail -f` (sal con `Ctrl+C`): ```bash tail -f /var/log/mail.log ``` Con el journal puedes filtrar por proceso. Cada componente de Postfix usa su propio identificador (`postfix/smtpd`, `postfix/smtp`, `postfix/qmgr`...): ```bash sudo journalctl -t postfix/smtpd -t postfix/smtp --since "1 hour ago" sudo journalctl -u dovecot --since today ``` ## Paso 2: Entender el formato de una línea de Postfix Cada mensaje que atraviesa Postfix recibe un **ID de cola** (por ejemplo `4F2A11C0A3`) y pasa por varios procesos. Este es el recorrido completo de un correo entrante entregado en local: ```text 2026-09-25T10:12:41.301245+00:00 mail postfix/smtpd[20114]: connect from mx.example.org[203.0.113.25] 2026-09-25T10:12:41.512873+00:00 mail postfix/smtpd[20114]: 4F2A11C0A3: client=mx.example.org[203.0.113.25] 2026-09-25T10:12:41.623010+00:00 mail postfix/cleanup[20118]: 4F2A11C0A3: message-id= 2026-09-25T10:12:41.640551+00:00 mail postfix/qmgr[1402]: 4F2A11C0A3: from=, size=4210, nrcpt=1 (queue active) 2026-09-25T10:12:41.702334+00:00 mail postfix/lmtp[20120]: 4F2A11C0A3: to=, relay=mail.your_domain[private/dovecot-lmtp], delay=0.4, delays=0.33/0.01/0.02/0.04, dsn=2.0.0, status=sent (250 2.0.0 Saved) 2026-09-25T10:12:41.703120+00:00 mail postfix/qmgr[1402]: 4F2A11C0A3: removed ``` Ubuntu 24.04 usa marcas de tiempo ISO 8601 en syslog; versiones anteriores muestran el formato clásico `Sep 25 10:12:41`. Los campos que más te interesan son: | Campo | Significado | |-------|-------------| | `postfix/smtpd` | Recepción por SMTP (correo entrante o enviado por tus usuarios) | | `postfix/smtp` | Entrega a otro servidor por SMTP (correo saliente) | | `postfix/qmgr` | Gestor de cola: remitente, tamaño y eliminación de la cola | | `from=`, `to=` | Remitente y destinatario del sobre SMTP | | `relay=` | Servidor o transporte al que se entregó | | `delays=a/b/c/d` | Segundos en cola antes del gestor, en el gestor, en conexión y en transmisión | | `dsn=` | Código de estado extendido (`2.x.x` éxito, `4.x.x` temporal, `5.x.x` permanente) | | `status=` | `sent`, `deferred`, `bounced` o `expired` | Las líneas de Dovecot son más sencillas: indican el servicio, el usuario y la IP. ```text 2026-09-25T10:15:02.118802+00:00 mail dovecot: imap-login: Login: user=, method=PLAIN, rip=198.51.100.7, lip=192.0.2.10, mpid=20210, TLS, session= 2026-09-25T10:15:40.990215+00:00 mail dovecot: imap(info@your_domain)<20210>: Disconnected: Logged out in=120 out=5832 ``` ## Paso 3: Seguir un mensaje por su ID de cola El método más fiable para investigar un correo concreto es localizar su ID de cola y después filtrar todas las líneas con ese ID. Busca primero por destinatario (o remitente): ```bash grep 'to=' /var/log/mail.log ``` ```output 2026-09-25T09:58:13.442190+00:00 mail postfix/smtp[19870]: 8C31E1C0B7: to=, relay=mx.example.com[198.51.100.40]:25, delay=1.8, delays=0.1/0/0.6/1.1, dsn=5.1.1, status=bounced (host mx.example.com[198.51.100.40] said: 550 5.1.1 : Recipient address rejected: User unknown (in reply to RCPT TO command)) ``` El ID de cola es `8C31E1C0B7`. Muestra todo su recorrido: ```bash grep '8C31E1C0B7' /var/log/mail.log ``` Si el mensaje es de hace varios días, búscalo también en los logs rotados. `zgrep` lee tanto archivos comprimidos como sin comprimir: ```bash zgrep 'to=' /var/log/mail.log* ``` La parte entre paréntesis al final de la línea `status=` es la respuesta literal del servidor remoto, y suele contener la causa exacta del problema. ## Paso 4: Diagnosticar rebotes y mensajes retrasados Lista los rebotes permanentes del log actual: ```bash grep 'status=bounced' /var/log/mail.log ``` Y los mensajes que Postfix no pudo entregar todavía y reintentará más tarde: ```bash grep 'status=deferred' /var/log/mail.log ``` Para ver qué dominios de destino concentran más retrasos, extrae el dominio del campo `to=` y cuenta: ```bash grep 'status=deferred' /var/log/mail.log | grep -oP 'to=<[^@]+@\K[^>]+' | sort | uniq -c | sort -rn | head ``` ```output 42 gmail.com 7 outlook.com 2 example.net ``` Estas son las respuestas más frecuentes y lo que suelen indicar: | Respuesta | Causa habitual | Qué hacer | |-----------|----------------|-----------| | `550 5.1.1 User unknown` | El buzón de destino no existe | Corregir la dirección | | `554 5.7.1 Relay access denied` | Tu servidor intenta reenviar sin autenticar | Revisar `mynetworks` y la autenticación SASL del cliente | | `421 4.7.0 ... try again later` o `450 4.7.1` | Greylisting o límite de velocidad del destino | Normalmente nada, Postfix reintenta solo | | `550 5.7.1 ... SPF` o `... DMARC` | El destino rechaza por autenticación del dominio | Revisar los registros SPF, DKIM y DMARC | | `550 5.7.1 ... blocked using` | Tu IP está en una lista negra (RBL) | Consultar la lista indicada y pedir la baja | | `Connection timed out` en `relay=` | No se alcanza el puerto 25 del destino | Comprobar que el puerto 25 saliente está abierto | > Nota: Si todos los envíos salientes fallan con `Connection timed out`, comprueba primero la conectividad con `nc -vz gmail-smtp-in.l.google.com 25`. Si no conecta, el puerto 25 saliente está bloqueado en el firewall o en la red. ## Paso 5: Revisar la cola de Postfix Los mensajes con estado `deferred` siguen en la cola hasta que se entregan o caducan (por defecto a los 5 días, parámetro `maximal_queue_lifetime`). Para ver la cola: ```bash sudo postqueue -p ``` ```output -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- A7D021C0C2 3412 Thu Sep 25 09:40:12 newsletter@your_domain (connect to mx.example.net[198.51.100.80]:25: Connection timed out) usuario@example.net -- 1 Kbytes in 1 Request. ``` Para ver las cabeceras y el contenido de un mensaje en cola: ```bash sudo postcat -vq A7D021C0C2 ``` Cuando hayas corregido la causa (por ejemplo, un problema de DNS), fuerza un nuevo intento de entrega de toda la cola: ```bash sudo postqueue -f ``` Si la cola está llena de spam que salió de una cuenta comprometida, elimina un mensaje concreto con `sudo postsuper -d A7D021C0C2`. Evita `postsuper -d ALL` salvo que tengas claro que no hay correo legítimo pendiente. ## Paso 6: Detectar fallos de autenticación y fuerza bruta Los intentos de inicio de sesión fallidos en SMTP aparecen como avisos de SASL: ```bash grep 'SASL .* authentication failed' /var/log/mail.log | tail -n 5 ``` ```output 2026-09-25T10:21:03.551120+00:00 mail postfix/smtpd[20301]: warning: unknown[192.0.2.200]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 ``` Cuenta las IP con más fallos para ver si hay un ataque en curso: ```bash grep 'SASL .* authentication failed' /var/log/mail.log | grep -oP '\[\K[0-9a-f.:]+(?=\]: SASL)' | sort | uniq -c | sort -rn | head ``` ```output 318 192.0.2.200 54 203.0.113.99 3 198.51.100.7 ``` En Dovecot, los fallos de IMAP y POP3 aparecen en las líneas de `imap-login` y `pop3-login`: ```bash grep -E 'dovecot: (imap|pop3)-login: .*auth failed' /var/log/mail.log | tail -n 5 ``` ```output 2026-09-25T10:25:47.004411+00:00 mail dovecot: imap-login: Disconnected: Connection closed (auth failed, 3 attempts in 12 secs): user=, method=PLAIN, rip=203.0.113.99, lip=192.0.2.10, TLS, session= ``` Dovecot también guarda en memoria los últimos errores, útil cuando el log es muy grande: ```bash sudo doveadm log errors ``` Si ves cientos de intentos desde las mismas IP, instala Fail2ban con las jaulas `postfix-sasl` y `dovecot` en lugar de bloquearlas a mano. ## Paso 7: Aumentar el detalle de los logs temporalmente Cuando los logs normales no bastan, puedes pedir más información. Para registrar los detalles de TLS en las conexiones entrantes y salientes: ```bash sudo postconf -e 'smtpd_tls_loglevel = 1' 'smtp_tls_loglevel = 1' sudo systemctl reload postfix ``` Para ver por qué Dovecot rechaza una autenticación (usuario inexistente, contraseña incorrecta, mecanismo no permitido), edita la configuración de logging: ```bash sudo nano /etc/dovecot/conf.d/10-logging.conf ``` ```ini auth_verbose = yes auth_verbose_passwords = no ``` Recarga Dovecot y repite la prueba: ```bash sudo systemctl reload dovecot ``` ```text 2026-09-25T10:31:12.300214+00:00 mail dovecot: auth: passwd-file(admin@your_domain,203.0.113.99): Password mismatch ``` > Importante: Vuelve a dejar `auth_verbose = no` y los niveles de TLS a `0` cuando termines. Los logs detallados crecen rápido y pueden contener datos personales. ## Solución de problemas **`/var/log/mail.log` está vacío o no se actualiza.** Comprueba que rsyslog está activo con `systemctl status rsyslog` y que Postfix arranca sin errores con `sudo postfix check` y `sudo journalctl -u postfix@- -n 50`. **Aparece `warning: ... hostname does not resolve to address`.** El registro PTR de la IP del cliente no coincide con su nombre. Es solo un aviso para correo entrante; si ocurre con tu propia IP de salida, configura el DNS inverso de tu servidor para que apunte a su nombre (`myhostname`). **`fatal: open database /etc/postfix/...db: No such file or directory`.** Se ha editado un mapa (`virtual`, `transport`, `sasl_passwd`...) sin regenerarlo. Ejecuta `sudo postmap /etc/postfix/nombre_del_mapa` y recarga Postfix. ## Conclusión Ya sabes dónde buscar los logs de Postfix y Dovecot, cómo seguir un mensaje por su ID de cola, cómo interpretar los códigos de respuesta de los servidores remotos y cómo detectar intentos de fuerza bruta. Como siguientes pasos, protege el servidor con Fail2ban, revisa tus registros SPF, DKIM y DMARC si ves rechazos por autenticación del dominio, y configura una alerta que te avise cuando la cola de Postfix supere un tamaño razonable.