--- title: "Cómo diagnosticar Postfix con mail.log en Ubuntu 24.04" description: "Averigua por qué Postfix no envía o no recibe correo: lee mail.log, interpreta los códigos SMTP y revisa la cola, el puerto 25, el DNS y las listas negras." category: "Guía de Solución de Problemas" language: es source: https://cubepath.com/es/docs/guía-de-solución-de-problemas/correo-no-envia-recibe-analisis-de-logs updated: 2026-09-25 --- # Cómo diagnosticar Postfix con mail.log en Ubuntu 24.04 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. > Nota: si usas Debian 12 los comandos son los mismos. En Rocky Linux 9 el registro está en `/var/log/maillog` y el cortafuegos es firewalld. Si tu servidor usa Exim en lugar de Postfix, el registro principal está en `/var/log/exim4/mainlog` y la cola se consulta con `sudo 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: ```bash sudo systemctl status postfix@- ``` ```output ● postfix@-.service - Postfix Mail Transport Agent (instance -) Loaded: loaded (/usr/lib/systemd/system/postfix@.service; 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: ```bash sudo postfix check ``` Sin salida significa que no hay problemas. Después comprueba que Postfix escucha en los puertos de correo: ```bash sudo ss -ltnp | grep -E ':(25|465|587)\b' ``` ```output 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`: ```bash postconf inet_interfaces ``` Para recibir correo de internet debe valer `all`. Por último, confirma que el cortafuegos permite el tráfico: ```bash sudo ufw status ``` Si UFW está activo y no aparece el puerto 25, ábrelo junto con el de envío autenticado: ```bash 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: ```bash 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: ```bash sudo journalctl -u postfix@- -f ``` Una entrega correcta hacia fuera deja una secuencia como esta: ```output postfix/pickup[2211]: 4B7E21C0A3F: uid=1000 from= postfix/cleanup[2240]: 4B7E21C0A3F: message-id=<20260925101502.4B7E21C0A3F@mail.your_domain> postfix/qmgr[1302]: 4B7E21C0A3F: from=, size=412, nrcpt=1 (queue active) postfix/smtp[2245]: 4B7E21C0A3F: to=, 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: ```bash sudo grep 'to=' /var/log/mail.log | tail -n 5 ``` Después muestra todo el recorrido de ese mensaje: ```bash sudo grep 4B7E21C0A3F /var/log/mail.log ``` ### Resumir los fallos recientes Para ver solo los mensajes que no se entregaron: ```bash 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: ```bash 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 ``` ```output 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 : 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: ```bash sudo grep 'NOQUEUE: reject' /var/log/mail.log | tail -n 10 ``` Y los fallos de autenticación de clientes en el puerto 587: ```bash 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: ```bash sudo postqueue -p ``` ```output -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- 9C1D41C0B2A* 842 Thu Sep 25 10:20:11 your_user@your_domain someone@gmail.com (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: ```bash sudo postcat -q 9C1D41C0B2A ``` Cuando hayas corregido la causa, fuerza un reintento inmediato de toda la cola: ```bash 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: ```bash sudo postsuper -d 9C1D41C0B2A ``` ```bash sudo postsuper -d ALL deferred ``` > Advertencia: `postsuper -d ALL` sin 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: ```bash nc -vz -w 5 gmail-smtp-in.l.google.com 25 ``` ```output 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: ```bash 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: ```bash sudo apt install swaks ``` Envía un mensaje a través de tu propio Postfix: ```bash swaks --server localhost --from your_user@your_domain --to someone@gmail.com ``` Para probar el envío autenticado por el puerto 587 con STARTTLS, igual que lo haría un cliente de correo: ```bash swaks --server mail.your_domain --port 587 --tls --auth LOGIN --auth-user your_user@your_domain --from your_user@your_domain --to someone@gmail.com ``` 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: ```bash dig +short MX your_domain dig +short A mail.your_domain ``` ```output 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: ```bash 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: ```output postfix/smtpd[3120]: NOQUEUE: reject: RCPT from mail-wr1-f41.google.com[209.85.221.41]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo= ``` `Relay access denied` en la recepción significa que Postfix no se considera destino final de ese dominio. Comprueba los dominios que acepta: ```bash 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: ```bash dig +short TXT your_domain dig +short TXT default._domainkey.your_domain dig +short TXT _dmarc.your_domain dig +short -x your_server_ip ``` ```output "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=spf1` y debe incluir la IP del servidor (directamente con `ip4:` o a través de `mx`). - **DKIM**: la clave pública debe coincidir con la que firma el servidor. Si usas OpenDKIM, `sudo opendkim-testkey -d your_domain -s default -vvv` verifica la coincidencia y termina con `key OK`. - **DMARC**: debe existir en `_dmarc.your_domain`. Empieza con `p=none` o `p=quarantine` mientras verificas. - **PTR**: la IP debe resolver a `mail.your_domain` y 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: ```bash 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: ```bash dig +short 25.113.0.203.zen.spamhaus.org ``` - Sin respuesta: la IP no está listada. - `127.0.0.2` a `127.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.254` o 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í: ```output 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: ```bash 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: ```bash 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: ```bash 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`: ```bash 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: ```bash 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.