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:
ls -lh /var/log/mail.log*
-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:
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):
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...):
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:
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=<[email protected]>
2026-09-25T10:12:41.640551+00:00 mail postfix/qmgr[1402]: 4F2A11C0A3: from=<[email protected]>, size=4210, nrcpt=1 (queue active)
2026-09-25T10:12:41.702334+00:00 mail postfix/lmtp[20120]: 4F2A11C0A3: to=<info@your_domain>, 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 <info@your_domain> 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.
2026-09-25T10:15:02.118802+00:00 mail dovecot: imap-login: Login: user=<info@your_domain>, method=PLAIN, rip=198.51.100.7, lip=192.0.2.10, mpid=20210, TLS, session=<k3L9c0x>
2026-09-25T10:15:40.990215+00:00 mail dovecot: imap(info@your_domain)<20210><k3L9c0x>: 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):
grep 'to=<[email protected]>' /var/log/mail.log
2026-09-25T09:58:13.442190+00:00 mail postfix/smtp[19870]: 8C31E1C0B7: to=<[email protected]>, 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 <[email protected]>: Recipient address rejected: User unknown (in reply to RCPT TO command))
El ID de cola es 8C31E1C0B7. Muestra todo su recorrido:
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:
zgrep 'to=<[email protected]>' /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:
grep 'status=bounced' /var/log/mail.log
Y los mensajes que Postfix no pudo entregar todavía y reintentará más tarde:
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:
grep 'status=deferred' /var/log/mail.log | grep -oP 'to=<[^@]+@\K[^>]+' | sort | uniq -c | sort -rn | head
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 |
NotaSi todos los envíos salientes fallan con
Connection timed out, comprueba primero la conectividad connc -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:
sudo postqueue -p
-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)
[email protected]
-- 1 Kbytes in 1 Request.
Para ver las cabeceras y el contenido de un mensaje en cola:
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:
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:
grep 'SASL .* authentication failed' /var/log/mail.log | tail -n 5
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:
grep 'SASL .* authentication failed' /var/log/mail.log | grep -oP '\[\K[0-9a-f.:]+(?=\]: SASL)' | sort | uniq -c | sort -rn | head
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:
grep -E 'dovecot: (imap|pop3)-login: .*auth failed' /var/log/mail.log | tail -n 5
2026-09-25T10:25:47.004411+00:00 mail dovecot: imap-login: Disconnected: Connection closed (auth failed, 3 attempts in 12 secs): user=<admin@your_domain>, method=PLAIN, rip=203.0.113.99, lip=192.0.2.10, TLS, session=<p0Qx1m2>
Dovecot también guarda en memoria los últimos errores, útil cuando el log es muy grande:
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:
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:
sudo nano /etc/dovecot/conf.d/10-logging.conf
auth_verbose = yes
auth_verbose_passwords = no
Recarga Dovecot y repite la prueba:
sudo systemctl reload dovecot
2026-09-25T10:31:12.300214+00:00 mail dovecot: auth: passwd-file(admin@your_domain,203.0.113.99): Password mismatch
ImportanteVuelve a dejar
auth_verbose = noy los niveles de TLS a0cuando 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.