Cuando un servidor de correo deja de enviar o de recibir mensajes, casi siempre la causa aparece escrita en el registro de Postfix: un rechazo del servidor remoto, un tiempo de espera en el puerto 25, un registro DNS que falta o un disco lleno. En este tutorial aprenderás a leer /var/log/mail.log en Ubuntu 24.04, a seguir un mensaje concreto por su identificador de cola, a interpretar los códigos SMTP y a aislar el fallo entre envío, recepción, DNS y reputación de la IP.
Requisitos previos
Para seguir esta guía necesitas:
- Un servidor con Ubuntu 24.04 LTS y Postfix instalado y configurado, por ejemplo un VPS de CubePath.
- Un usuario no root con privilegios
sudo. - Un dominio (en esta guía,
your_domain) con su registro MX apuntando al servidor, cuyo nombre serámail.your_domain. - Una cuenta de correo externa (Gmail, Outlook) para enviar y recibir mensajes de prueba.
Sustituye your_domain y your_server_ip por tus valores en todos los comandos.
Notasi usas Debian 12 los comandos son los mismos. En Rocky Linux 9 el registro está en
/var/log/maillogy el cortafuegos es firewalld. Si tu servidor usa Exim en lugar de Postfix, el registro principal está en/var/log/exim4/mainlogy la cola se consulta consudo exim -bp.
Cómo viaja un mensaje
Antes de buscar en los registros conviene saber qué pieza puede fallar:
- Envío: un cliente o una aplicación entrega el mensaje a Postfix (por el puerto 587 o localmente con
sendmail). Postfix lo guarda en la cola, busca el registro MX del dominio de destino y se conecta a ese servidor por el puerto TCP 25. - Recepción: un servidor remoto consulta el MX de
your_domain, se conecta al puerto 25 de tu servidor y Postfix acepta o rechaza el mensaje. Si lo acepta, lo entrega al buzón local o a Dovecot.
Cada mensaje recibe un identificador de cola (por ejemplo, 4B7E21C0A3F) que aparece en todas las líneas de registro que le afectan. Ese identificador es la herramienta principal de esta guía.
Paso 1: Comprobar el servicio y los puertos
En Ubuntu, Postfix se ejecuta como la instancia postfix@- de systemd. Comprueba que está activo:
sudo systemctl status postfix@-
● [email protected] - Postfix Mail Transport Agent (instance -)
Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled-runtime; preset: enabled)
Active: active (running) since Thu 2026-09-24 09:12:40 UTC; 1 day ago
Si no está activo, postfix check revisa la configuración y los permisos y muestra el error que impide arrancar:
sudo postfix check
Sin salida significa que no hay problemas. Después comprueba que Postfix escucha en los puertos de correo:
sudo ss -ltnp | grep -E ':(25|465|587)\b'
LISTEN 0 100 0.0.0.0:25 0.0.0.0:* users:(("master",pid=1234,fd=13))
LISTEN 0 100 0.0.0.0:587 0.0.0.0:* users:(("master",pid=1234,fd=17))
Si solo ves 127.0.0.1:25, Postfix no acepta conexiones externas. Revisa el parámetro inet_interfaces:
postconf inet_interfaces
Para recibir correo de internet debe valer all. Por último, confirma que el cortafuegos permite el tráfico:
sudo ufw status
Si UFW está activo y no aparece el puerto 25, ábrelo junto con el de envío autenticado:
sudo ufw allow 25/tcp
sudo ufw allow 587/tcp
Paso 2: Leer el registro de Postfix
Ubuntu 24.04 envía los mensajes de Postfix a /var/log/mail.log a través de rsyslog. Sigue el registro en tiempo real mientras envías un mensaje de prueba desde otra terminal:
sudo tail -f /var/log/mail.log
Si el archivo no existe (por ejemplo, en una instalación mínima sin rsyslog), consulta el diario de systemd:
sudo journalctl -u postfix@- -f
Una entrega correcta hacia fuera deja una secuencia como esta:
postfix/pickup[2211]: 4B7E21C0A3F: uid=1000 from=<your_user>
postfix/cleanup[2240]: 4B7E21C0A3F: message-id=<[email protected]_domain>
postfix/qmgr[1302]: 4B7E21C0A3F: from=<your_user@your_domain>, size=412, nrcpt=1 (queue active)
postfix/smtp[2245]: 4B7E21C0A3F: to=<[email protected]>, relay=gmail-smtp-in.l.google.com[142.250.27.26]:25, delay=1.2, delays=0.05/0.01/0.4/0.74, dsn=2.0.0, status=sent (250 2.0.0 OK 1727259303 ...)
postfix/qmgr[1302]: 4B7E21C0A3F: removed
Los campos clave de la línea de entrega son:
| Campo | Significado |
|---|---|
relay= | Servidor al que Postfix entregó (o intentó entregar) el mensaje. |
delay= | Segundos totales desde que el mensaje entró en la cola. |
delays=a/b/c/d | Tiempo en cola antes del gestor, en el gestor, en conexión (DNS, TCP, TLS) 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 (se reintentará), bounced (rechazo definitivo) o expired. |
Seguir un mensaje por su identificador
Localiza el identificador buscando por destinatario o remitente:
sudo grep 'to=<[email protected]>' /var/log/mail.log | tail -n 5
Después muestra todo el recorrido de ese mensaje:
sudo grep 4B7E21C0A3F /var/log/mail.log
Resumir los fallos recientes
Para ver solo los mensajes que no se entregaron:
sudo grep -E 'status=(deferred|bounced|expired)' /var/log/mail.log | tail -n 20
Para saber qué motivo se repite más, cuenta los textos que aparecen entre paréntesis al final de esas líneas:
sudo grep -E 'status=(deferred|bounced)' /var/log/mail.log | sed -E 's/.*status=[a-z]+ \((.*)\)$/\1/' | cut -c1-90 | sort | uniq -c | sort -rn | head
37 connect to gmail-smtp-in.l.google.com[142.250.27.26]:25: Connection timed out
4 host mx.example.net[203.0.113.10] said: 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown
Los rechazos en la recepción aparecen como líneas NOQUEUE: reject, porque el mensaje nunca llegó a entrar en la cola:
sudo grep 'NOQUEUE: reject' /var/log/mail.log | tail -n 10
Y los fallos de autenticación de clientes en el puerto 587:
sudo grep 'SASL' /var/log/mail.log | grep -i 'authentication failed' | tail -n 10
Paso 3: Interpretar los códigos SMTP
La respuesta del servidor remoto indica si el problema es tuyo, suyo o temporal. El primer dígito manda: 2 éxito, 4 error temporal (Postfix reintentará), 5 error permanente (el mensaje se devuelve al remitente).
| Mensaje en el registro | Causa habitual | Qué hacer |
|---|---|---|
connect to ...:25: Connection timed out | El puerto 25 de salida está bloqueado. | Comprobar la salida por el puerto 25 (paso 4). |
550 5.1.1 ... User unknown | El buzón de destino no existe. | Corregir la dirección. |
554 5.7.1 ... Relay access denied | El servidor receptor no acepta correo para ese dominio o el cliente no se autenticó. | Revisar mydestination o la autenticación SASL. |
550 5.7.1 o 550 5.7.26 con texto sobre SPF, DKIM o autenticación | Gmail u Outlook rechazan el mensaje por no estar autenticado. | Revisar SPF, DKIM, DMARC y PTR (paso 6). |
421 4.7.0 o 450 4.7.1 con "try again later" | Límite de velocidad o greylisting del receptor. | Esperar: Postfix reintenta solo. |
554 5.7.1 Service unavailable; Client host [...] blocked using zen.spamhaus.org | Tu IP está en una lista negra. | Consultar las listas (paso 7). |
452 4.3.1 Insufficient system storage | Tu servidor se ha quedado sin espacio para la cola. | Liberar disco (paso 8). |
Host or domain name not found | El dominio de destino no tiene MX ni A, o tu DNS no resuelve. | Probar la resolución con dig. |
El texto que sigue al código suele incluir un enlace a la documentación del proveedor receptor. Léelo antes de cambiar nada: Gmail y Outlook explican exactamente qué requisito no cumples.
Paso 4: Diagnosticar problemas de envío
Revisar la cola
Los mensajes con status=deferred se quedan en la cola y Postfix los reintenta durante cinco días por defecto. Lista la cola:
sudo postqueue -p
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
9C1D41C0B2A* 842 Thu Sep 25 10:20:11 your_user@your_domain
[email protected]
(connect to gmail-smtp-in.l.google.com[142.250.27.26]:25: Connection timed out)
-- 1 Kbytes in 1 Request.
El asterisco indica que el mensaje está en la cola activa. Para ver el contenido y las cabeceras de un mensaje:
sudo postcat -q 9C1D41C0B2A
Cuando hayas corregido la causa, fuerza un reintento inmediato de toda la cola:
sudo postqueue -f
Si la cola contiene mensajes que no deben salir (por ejemplo, spam generado por un formulario web comprometido), elimina uno concreto o todos los diferidos:
sudo postsuper -d 9C1D41C0B2A
sudo postsuper -d ALL deferred
Advertencia
postsuper -d ALLsin más argumentos borra todos los mensajes de todas las colas y no se puede deshacer.
Comprobar la salida por el puerto 25
Un Connection timed out hacia el puerto 25 de cualquier destino significa que el tráfico saliente está filtrado. Compruébalo directamente:
nc -vz -w 5 gmail-smtp-in.l.google.com 25
Connection to gmail-smtp-in.l.google.com (142.250.27.26) 25 port [tcp/smtp] succeeded!
Si la conexión no se establece, el bloqueo está fuera de Postfix. En CubePath, como en la mayoría de proveedores cloud, el puerto 25 de salida está cerrado por defecto para evitar el spam; abre un ticket de soporte describiendo el uso que harás del correo para solicitar la apertura. Si tu VPS tiene varias IPv4, indica la IP que usará el servidor de correo y asegúrate de que Postfix sale por ella:
sudo postconf -e 'smtp_bind_address = your_server_ip'
sudo systemctl reload postfix
Enviar un mensaje de prueba con swaks
swaks permite hablar SMTP desde la línea de comandos y muestra cada respuesta del servidor. Instálalo:
sudo apt install swaks
Envía un mensaje a través de tu propio Postfix:
swaks --server localhost --from your_user@your_domain --to [email protected]
Para probar el envío autenticado por el puerto 587 con STARTTLS, igual que lo haría un cliente de correo:
swaks --server mail.your_domain --port 587 --tls --auth LOGIN --auth-user your_user@your_domain --from your_user@your_domain --to [email protected]
swaks pedirá la contraseña. Una línea <~ 235 2.7.0 Authentication successful confirma que la autenticación funciona; si ves 535 5.7.8, el usuario o la contraseña no son válidos y el detalle aparecerá en mail.log con la palabra SASL.
Paso 5: Diagnosticar problemas de recepción
Si no llega correo desde fuera, comprueba primero que el dominio anuncia tu servidor. El registro MX debe apuntar a un nombre, y ese nombre debe resolver a tu IP:
dig +short MX your_domain
dig +short A mail.your_domain
10 mail.your_domain.
203.0.113.25
Después prueba el puerto 25 desde otra máquina (tu ordenador u otro servidor), nunca desde el propio servidor, porque así no compruebas el cortafuegos:
nc -vz -w 5 mail.your_domain 25
Muchas redes domésticas bloquean el puerto 25 de salida, así que si falla desde casa repite la prueba desde otro servidor antes de sacar conclusiones.
Con la conexión funcionando, envía un correo desde Gmail a your_user@your_domain y observa el registro. Una recepción correcta muestra connect from, una línea qmgr con (queue active) y la entrega local con status=sent. Si en su lugar aparece un rechazo, el texto indica el motivo:
postfix/smtpd[3120]: NOQUEUE: reject: RCPT from mail-wr1-f41.google.com[209.85.221.41]: 554 5.7.1 <info@your_domain>: Relay access denied; from=<[email protected]> to=<info@your_domain> proto=ESMTP helo=<mail-wr1-f41.google.com>
Relay access denied en la recepción significa que Postfix no se considera destino final de ese dominio. Comprueba los dominios que acepta:
postconf mydestination virtual_mailbox_domains
Añade your_domain al parámetro que uses (mydestination para buzones de usuarios del sistema, virtual_mailbox_domains si usas dominios virtuales) y recarga Postfix con sudo systemctl reload postfix. Si el rechazo es User unknown in local recipient table, el dominio es correcto pero la cuenta o el alias no existe.
Paso 6: Revisar SPF, DKIM, DMARC y el DNS inverso
Si los mensajes salen con status=sent pero llegan a la carpeta de spam, o los grandes proveedores los rechazan con 5.7.1 o 5.7.26, el problema está en la autenticación del dominio. Comprueba los cuatro registros:
dig +short TXT your_domain
dig +short TXT default._domainkey.your_domain
dig +short TXT _dmarc.your_domain
dig +short -x your_server_ip
"v=spf1 mx -all"
"v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqh..."
"v=DMARC1; p=quarantine; rua=mailto:dmarc@your_domain"
mail.your_domain.
Sustituye default por el selector DKIM que hayas configurado en OpenDKIM. Qué comprobar en cada uno:
- SPF: debe existir un solo registro
v=spf1y debe incluir la IP del servidor (directamente conip4:o a través demx). - DKIM: la clave pública debe coincidir con la que firma el servidor. Si usas OpenDKIM,
sudo opendkim-testkey -d your_domain -s default -vvvverifica la coincidencia y termina conkey OK. - DMARC: debe existir en
_dmarc.your_domain. Empieza conp=noneop=quarantinemientras verificas. - PTR: la IP debe resolver a
mail.your_domainy ese nombre debe resolver de vuelta a la misma IP. El PTR lo configura quien administra la IP, no tu zona DNS.
El PTR además debe coincidir con el nombre con el que Postfix se presenta:
postconf myhostname
La prueba definitiva es enviar un mensaje a una cuenta de Gmail y abrir Mostrar original. Las líneas SPF: PASS, DKIM: PASS y DMARC: PASS confirman que la autenticación es correcta.
Paso 7: Consultar las listas negras
Si los rechazos mencionan blocked using o listed, tu IP está en una lista de bloqueo. Las listas DNSBL se consultan con una búsqueda DNS de la IP invertida. Para la IP 203.0.113.25, la consulta a Spamhaus es:
dig +short 25.113.0.203.zen.spamhaus.org
- Sin respuesta: la IP no está listada.
127.0.0.2a127.0.0.11: la IP está listada. Consulta el motivo en la web de Spamhaus e inicia allí la solicitud de baja.127.255.255.254o similar: Spamhaus ha rechazado la consulta porque tu servidor usa un resolvedor DNS público. Repite la consulta desde otro equipo o usa el comprobador web de la lista.
Repite la consulta con bl.spamcop.net y b.barracudacentral.org para cubrir las listas más usadas. Antes de pedir la baja, averigua por qué entraste en la lista: una cola llena de mensajes que no enviaste (paso 4) indica una cuenta o un formulario comprometido, y la IP volverá a la lista si no lo corriges.
Paso 8: Comprobar disco y recursos
Postfix deja de aceptar correo cuando el sistema de archivos de la cola se queda sin espacio o sin inodos, y lo registra así:
postfix/smtpd[4102]: NOQUEUE: reject: MAIL from unknown[198.51.100.7]: 452 4.3.1 Insufficient system storage
postfix/smtpd[4102]: warning: not enough free space in mail queue: 8192000 bytes < 1.5*message size limit
Comprueba el espacio y los inodos del volumen que contiene la cola:
df -h /var/spool/postfix
df -i /var/spool/postfix
Si el disco está lleno, localiza qué ocupa el espacio antes de borrar nada. Los buzones y los registros sin rotar son los culpables habituales:
sudo du -xh --max-depth=2 /var | sort -h | tail -n 15
Una cola con miles de mensajes también es un síntoma: indica envío masivo no deseado o un destino que no responde. Cuenta los mensajes en cola con:
sudo postqueue -p | tail -n 1
Paso 9: Aumentar el detalle del registro para un destino
Si el registro no da suficiente información sobre la conversación con un servidor concreto, Postfix puede registrar la sesión SMTP completa solo para ese destino. Añade el dominio o la IP a debug_peer_list:
sudo postconf -e 'debug_peer_list = example.net'
sudo systemctl reload postfix
Reproduce el problema y revisa mail.log: verás cada comando y cada respuesta intercambiados con example.net. Cuando termines, elimina el ajuste para no llenar el registro:
sudo postconf -X debug_peer_list
sudo systemctl reload postfix
Solución de problemas
No aparece nada en mail.log al enviar desde una aplicación: la aplicación no está entregando a Postfix. Comprueba que usa localhost:25 o /usr/sbin/sendmail y revisa el registro de la propia aplicación.
Los mensajes se quedan en deferred con Connection timed out hacia todos los destinos: la salida por el puerto 25 está bloqueada. Compruébalo con nc -vz -w 5 gmail-smtp-in.l.google.com 25 y solicita la apertura al soporte.
Gmail devuelve 550 5.7.26 y Outlook 550 5.7.515: el mensaje no supera la autenticación del dominio. Revisa SPF, DKIM y DMARC en el paso 6; ambos proveedores exigen que al menos SPF o DKIM estén alineados con el dominio del remitente.
Postfix no arranca después de editar main.cf: ejecuta sudo postfix check y sudo journalctl -u postfix@- -n 50. Suele ser un parámetro con un error tipográfico o un archivo de mapa que falta ejecutar con postmap.
Conclusión
Con el registro de Postfix, el identificador de cola y el código SMTP de cada respuesta puedes localizar casi cualquier fallo de correo: un bloqueo del puerto 25, un dominio que Postfix no reconoce, un registro DNS mal publicado o una IP en lista negra. Como siguientes pasos, publica un registro DMARC con informes (rua=) para vigilar la autenticación de tu dominio, configura la rotación de mail.log con logrotate si lo has modificado y añade una alerta cuando la cola de Postfix supere un número razonable de mensajes.