Postfix «host not found»: problemas DNS que silencian el correo

Qué significa realmente «host not found» en Postfix

Postfix no está siendo poético. «Host not found» suele significar que preguntó al resolvedor y no obtuvo una respuesta utilizable. Esa respuesta puede ser «NXDOMAIN» (no existe), o «SERVFAIL» (el servidor DNS se rindió), o «timeout» (sin respuesta), o «no data» (el dominio existe, pero no el tipo de registro solicitado).

Los lugares más comunes donde verás esto:

• Entrega saliente a destinatarios remotos: Postfix intenta resolver MX para example.com, luego A/AAAA para los nombres MX.
• Restricciones SMTP entrantes como reject_unknown_client_hostname o reject_unknown_sender_domain, donde Postfix realiza consultas durante la conversación SMTP.
• Enrutamiento local cuando usas mapas de transporte basados en DNS o reglas de relayhost.

De dónde sale la cadena de error

Postfix usa las librerías del resolvedor del sistema para la mayoría de las búsquedas. Así que la frase «name service error» no es realmente una excentricidad de Postfix; a menudo surge del comportamiento del resolvedor de libc, influenciado por:

• el contenido de /etc/resolv.conf y los dominios de búsqueda
• resolvedores locales en caché (systemd-resolved, unbound, dnsmasq)
• la ruta de red hacia los resolvedores ascendentes
• fallos de validación DNSSEC (si están habilitados en tu ruta)
• comportamiento de IPv6 (las consultas AAAA pueden ser sorprendentemente «ruidosas»)

La mayoría de las veces, el problema operativo inmediato es simple: el correo queda atascado en la cola como deferred. El problema más peligroso es que nada te alerta a menos que estés vigilando la profundidad de cola, razones de diferimiento o patrones de logs.

Idea parafraseada (atribuida): John Allspaw lleva tiempo impulsando la mentalidad de operaciones de que la fiabilidad viene de aprender cómo fallan realmente los sistemas, no de asumir que no fallarán.

Tómalo en serio aquí. Los fallos DNS son normales. Tu sistema de correo debería tratarlos como turbulencia rutinaria, no como un cometa raro.

Guía de diagnóstico rápido (primero/segundo/tercero)

Esta es la secuencia «deja de adivinar». Hazla en orden. Está diseñada para encontrar el cuello de botella rápidamente: ¿es configuración de Postfix, el resolvedor local, el DNS ascendente o el dominio remoto?

Primero: confirma el error e identifica el dominio objetivo

1. Encuentra un mensaje fallido en la cola y captura el dominio del destinatario y el texto exacto del error.
2. Comprueba si es un dominio o muchos. Un dominio apunta al DNS remoto; muchos dominios apuntan a tu ruta de resolvedor.

Segundo: prueba DNS desde el host de Postfix (no desde tu portátil)

1. dig MX y A/AAAA para el dominio del destinatario y para los objetivos MX.
2. Repite contra tu resolvedor configurado y luego contra un resolvedor público conocido (temporalmente, para diagnóstico). Las diferencias importan.
3. Revisa los códigos de respuesta: NXDOMAIN vs SERVFAIL vs timeout son especies distintas de fallo.

Tercero: verifica la cadena del resolvedor local y los timeouts

1. Inspecciona /etc/resolv.conf y los servicios de resolvedor locales.
2. Busca fallos de DNSSEC, discrepancias de split-horizon y conectividad IPv6 rota.
3. Confirma que Postfix no esté enjaulado en un namespace de red o contenedor con DNS distinto.

Si completas esos tres pasos, dejarás de discutir si «el DNS está caído» y empezarás a hablar de qué ruta de resolvedor te está mintiendo.

Hechos e historia que explican las rarezas actuales

DNS y correo crecieron juntos, por eso sus modos de fallo están profundamente entrelazados. Algunos hechos breves que ayudan a entender el desorden:

1. Los registros MX se introdujeron para desacoplar el enrutamiento de correo del direccionamiento de hosts. Antes de MX, la entrega de correo dependía mucho de registros A y convenciones implícitas.
2. Los TTL de DNS se diseñaron para eficiencia de caché, no para claridad operativa. Cuando alguien dice «arreglamos DNS», aún debes preguntar «¿dónde, y cuál es el TTL?»
3. El caché negativo existe. Las respuestas NXDOMAIN también pueden ser cacheadas, así que una errata transitoria puede quedarse como un mal olor.
4. Los resolvedores suelen reintentar entre varios servidores. Un resolvedor defectuoso junto a uno bueno aún puede crear fallos intermitentes que parecen «problemas aleatorios de Postfix».
5. SMTP se diseñó para la demora. Se esperan fallos temporales; los MTAs encolan y reintentan. Eso es genial—hasta que enmascara tu incidente.
6. La adopción de IPv6 introdujo comportamientos tipo «happy eyeballs» en muchas pilas, pero no siempre como quisieras. La latencia de consultas AAAA aún puede hacerte daño aunque no tengas enrutamiento IPv6 funcional.
7. DNSSEC puede convertir «funciona en mi resolvedor» en «SERVFAIL en todas partes». Los fallos de validación aparecen como SERVFAIL a los clientes, lo que parece «el dominio está roto» aunque existan registros.
8. El split-horizon DNS es común en empresas. El mismo dominio puede resolverse de forma diferente dentro y fuera. Los servidores de correo que cruzan fronteras son víctimas frecuentes.
9. Los grandes proveedores publican configuraciones DNS complejas. Múltiples registros MX, geo-DNS y TTLs cortos pueden amplificar cualquier debilidad en tu cadena de resolvedores.

DNS no es «solo una guía telefónica». Es una base de datos distribuida con cachés, timeouts, fallos parciales y política. El correo depende de él más que la mayoría de las aplicaciones, por eso puedes perder entregabilidad mientras todo lo demás parece estar bien.

Broma #1: DNS es la única base de datos donde «depende» es una característica, no un bug.

Cómo Postfix usa DNS (y dónde puede fallar)

Salida: búsqueda MX, luego A/AAAA

Para user@recipient.tld, Postfix hace, más o menos:

1. Buscar MX para recipient.tld.
2. Si no hay MX, retroceder a A/AAAA para recipient.tld (según política y comportamiento RFC).
3. Para cada hostname MX, buscar A/AAAA.
4. Intentar entrega SMTP a las IP resueltas, respetando prioridad y lógica de reintentos.

«Host not found» puede ocurrir en varios puntos: falla la búsqueda MX, el MX existe pero apunta a un hostname sin A/AAAA, o tu resolvedor devuelve basura.

Entrada: comprobaciones de política que disparan DNS durante SMTP

Las configuraciones modernas de Postfix a menudo incluyen restricciones que llaman a DNS:

• reject_unknown_sender_domain provoca una comprobación A/AAAA (y a veces MX).
• reject_unknown_client_hostname realiza PTR y luego FCrDNS (forward-confirmed reverse DNS).
• Las búsquedas RBL también son consultas DNS; pueden detenerse si tus resolvedores son lentos.

Estas comprobaciones son útiles, pero también inyectan una dependencia. Has integrado la disponibilidad de DNS en la ruta de respuesta SMTP. Si tu resolvedor es lento, tu servicio SMTP se vuelve lento. Si tu resolvedor está roto, tu SMTP se vuelve «misteriosamente grosero».

Ruta del resolvedor local: tu dependencia real

Postfix típicamente depende de lo que el host use para resolución de nombres. Eso significa que tu «diseño DNS» incluye:

• Resolvedor stub (127.0.0.53 con systemd-resolved, o unbound local, etc.)
• Resolvedores ascendentes (DNS corporativo, DNS de VPC, ISP, públicos)
• Reglas de firewall y enrutamiento (especialmente UDP/53, TCP/53 y UDP fragmentado)
• Comportamiento EDNS0 y DNSSEC

Si quieres menos interrupciones de correo, trata DNS como una dependencia de nivel 0. Monitorízalo. Provísionalo redundante. Manténlo aburrido.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las tareas que realmente ejecuto cuando aparece «host not found». Cada tarea incluye: comando, lo que podrías ver, qué significa y la decisión que tomas.

Task 1: Identificar la razón exacta del diferimiento en la cola

cr0x@server:~$ postqueue -p | sed -n '1,40p'
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9C2E12A3B5      3123 Fri Jan  3 10:21:54  sender@example.net
(connect to mx1.recipient.tld[203.0.113.10]:25: Connection timed out)
                                         user@recipient.tld

B1A7F0D91C      2210 Fri Jan  3 10:22:09  sender@example.net
(host mx2.recipient.tld[198.51.100.77] said: 450 4.1.8 <user@recipient.tld>: Recipient address rejected: Domain not found)
                                         user@recipient.tld

C4F9A3D2E1      1444 Fri Jan  3 10:22:32  sender@example.net
(host or domain name not found. Name service error for name=recipient.tld type=MX: Host not found, try again)
                                         user@recipient.tld

Qué significa: Estás viendo distintas clases de fallo. Sólo la última es el fallo de consulta DNS. No las confundas.

Decisión: Elige un mensaje representativo con el error DNS y concéntrate en ese dominio y tipo de consulta.

Task 2: Extraer un archivo de cola para contexto completo

cr0x@server:~$ postcat -q C4F9A3D2E1 | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size:           1444            1444
message_arrival_time:   Fri Jan  3 10:22:32 2026
sender:                 sender@example.net
named_attribute:        rewrite_context=remote
recipient:              user@recipient.tld
*** DELIVERED TO THIS RECIPIENT ***
remote:                 recipient.tld
offset:                 1234
status:                 deferred
reason:                 host or domain name not found. Name service error for name=recipient.tld type=MX: Host not found, try again

Qué significa: La llamada al resolvedor falló en una consulta MX para el dominio en sí, no para los hostnames objetivo MX.

Decisión: Prueba la resolución MX para recipient.tld desde este host, usando la misma ruta de resolvedor.

Task 3: Leer logs de correo para patrones y alcance

cr0x@server:~$ sudo grep -E "Name service error|host not found|type=MX" -n /var/log/mail.log | tail -n 15
38412:Jan  3 10:22:32 server postfix/smtp[21903]: C4F9A3D2E1: to=<user@recipient.tld>, relay=none, delay=12, delays=0.1/0.01/12/0, dsn=4.4.3, status=deferred (host or domain name not found. Name service error for name=recipient.tld type=MX: Host not found, try again)
38458:Jan  3 10:24:10 server postfix/smtp[21922]: 7A11B7D4C2: to=<ops@another.tld>, relay=none, delay=10, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=another.tld type=MX: Host not found, try again)

Qué significa: Varios dominios están fallando. Eso es una fuerte pista de que tu ruta de resolvedor está enferma, no sólo el DNS de un dominio remoto.

Decisión: Cambia de «depurar recipient.tld» a «depurar nuestra ruta de cliente DNS».

Task 4: Confirmar qué resolvedores usará el host

cr0x@server:~$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search corp.internal

Qué significa: Estás usando el stub de systemd-resolved. Postfix preguntará a 127.0.0.53, que a su vez reenviará a lo que systemd-resolved considere correcto.

Decisión: Inspecciona el estado de systemd-resolved y los servidores ascendentes a continuación. También vigila dominios de search que puedan causar consultas sorpresa.

Task 5: Inspeccionar DNS ascendentes y configuración por enlace de systemd-resolved

cr0x@server:~$ resolvectl status | sed -n '1,120p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens3)
Current Scopes: DNS
     Protocols: +DefaultRoute
Current DNS Server: 10.20.0.10
       DNS Servers: 10.20.0.10 10.20.0.11
        DNS Domain: corp.internal

Qué significa: Los resolvedores ascendentes son 10.20.0.10 y 10.20.0.11. Si estos son inalcanzables o están mal configurados, Postfix fallará en las búsquedas.

Decisión: Prueba consultas directamente contra cada servidor ascendente para detectar split-brain o falla de uno de ellos.

Task 6: Consultar MX directamente contra los resolvedores configurados

cr0x@server:~$ dig +time=2 +tries=1 @10.20.0.10 MX recipient.tld

; <<>> DiG 9.18.24 <<>> +time=2 +tries=1 @10.20.0.10 MX recipient.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45123
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 1998 msec
;; SERVER: 10.20.0.10#53(10.20.0.10) (UDP)
;; WHEN: Fri Jan 03 10:31:22 UTC 2026
;; MSG SIZE  rcvd: 56

Qué significa: No es NXDOMAIN. SERVFAIL implica que el resolvedor no pudo completar la consulta (fallo DNSSEC, problema ascendente, delegación defectuosa, recursión rota).

Decisión: Consulta el segundo resolvedor; si uno funciona y otro responde SERVFAIL, tienes fallos intermitentes según qué servidor se use.

Task 7: Comparar con el segundo resolvedor

cr0x@server:~$ dig +time=2 +tries=1 @10.20.0.11 MX recipient.tld

; <<>> DiG 9.18.24 <<>> +time=2 +tries=1 @10.20.0.11 MX recipient.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6112
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
recipient.tld.   300 IN MX 10 mx1.recipient.tld.
recipient.tld.   300 IN MX 20 mx2.recipient.tld.

;; Query time: 28 msec
;; SERVER: 10.20.0.11#53(10.20.0.11) (UDP)

Qué significa: Un resolvedor está roto. Tu host seguirá usándolo a veces, dependiendo de la selección de resolvedor y los timeouts.

Decisión: Elimina o arregla 10.20.0.10. No «esperes a que se recupere». Los servidores DNS que a veces responden SERVFAIL son cómo obtienes colas encantadas.

Task 8: Validar que los objetivos MX resuelvan a direcciones

cr0x@server:~$ dig +short A mx1.recipient.tld.
203.0.113.10

Qué significa: Existe una dirección IPv4 para el host MX. Haz lo mismo para AAAA aunque «no uses IPv6».

Decisión: Si A existe pero la consulta AAAA se atasca por una ruta IPv6 rota, puede que necesites arreglar IPv6 o ajustar el comportamiento del resolvedor; ver Task 12.

Task 9: Comprobar NXDOMAIN vs NODATA con precisión

cr0x@server:~$ dig @10.20.0.11 MX nonexistent-example.tld

; <<>> DiG 9.18.24 <<>> @10.20.0.11 MX nonexistent-example.tld
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13255
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
. 300 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2026010300 1800 900 604800 86400

Qué significa: NXDOMAIN es definitivo: el nombre de dominio no existe en DNS. Eso es un fallo permanente en principio, pero Postfix puede tratarlo como temporal según el contexto.

Decisión: Para correo saliente: rebota si es realmente inválido; para comprobaciones entrantes: considera si quieres rechazar correo basado en la existencia del dominio del remitente (puede causar falsos positivos durante incidentes DNS).

Task 10: Confirmar si las consultas hacen timeout (red/firewall/MTU)

cr0x@server:~$ dig +time=2 +tries=1 @10.20.0.10 MX recipient.tld
;; connection timed out; no servers could be reached

Qué significa: No es SERVFAIL—esto es un problema de conectividad. Podría ser firewall, enrutamiento, servicio DNS caído o fragmentos UDP bloqueados.

Decisión: Prueba TCP/53 y la conectividad básica al resolvedor.

Task 11: Probar DNS sobre TCP (detecta «UDP funciona hasta que no»)

cr0x@server:~$ dig +tcp +time=2 +tries=1 @10.20.0.10 MX recipient.tld
;; connection timed out; no servers could be reached

Qué significa: Si tanto UDP como TCP hacen timeout, el resolvedor es inalcanzable o está bloqueado. Si UDP falla pero TCP funciona, puedes tener un problema de fragmentación UDP/EDNS0.

Decisión: Arregla reglas de firewall y MTU/fragmentación. Para mitigación rápida, algunos entornos reducen el tamaño UDP EDNS0 en los resolvedores, pero eso es un parche que debes rastrear y eliminar luego.

Task 12: Detectar IPv6 roto que ralentiza la resolución

cr0x@server:~$ dig +time=2 +tries=1 AAAA mx1.recipient.tld. +stats

; <<>> DiG 9.18.24 <<>> +time=2 +tries=1 AAAA mx1.recipient.tld. +stats
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9001
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 1995 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; MSG SIZE  rcvd: 49
;; Query time: 1995 msec

Qué significa: «NOERROR con 0 respuestas» (NODATA) está bien. Lo malo es la latencia de dos segundos. Eso suele ser un retraso del resolvedor (timeout ascendente, problema de ruta v6 o reintentos por DNSSEC).

Decisión: Si las consultas AAAA cuestan segundos constantemente, estás añadiendo latencia a cada intento de entrega. Arregla la ruta del resolvedor; no «desactives IPv6» a menos que comprendas totalmente el alcance del cambio.

Task 13: Confirmar que Postfix no usa una vista DNS diferente (contenedores/namespaces)

cr0x@server:~$ sudo postconf -n | grep -E "smtp_host_lookup|smtp_dns|inet_protocols|resolve"
inet_protocols = all
smtp_host_lookup = dns

Qué significa: Postfix está realizando búsquedas DNS de forma normal. Si esto corre en un despliegue containerizado, aún podría usar el resolv.conf del contenedor.

Decisión: Si Postfix corre en un contenedor, ejecuta los mismos comandos dig desde dentro del contenedor. Si corre en el host, sigue depurando en el host.

Task 14: Comprobar timeouts de la librería del resolvedor y comportamiento de rotación

cr0x@server:~$ grep -E "nameserver|options" /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad

Qué significa: No estás controlando explícitamente timeout y attempts aquí. Los valores por defecto varían. Algunos entornos activan rotate, lo que puede repartir el dolor equitativamente entre resolvedores.

Decisión: Si un resolvedor ascendente está enfermo, elimínalo o arréglalo. Ajustar parámetros de reintento no sustituye a un DNS sano.

Task 15: Validar que tu propio hostname y nombre HELO resuelvan

cr0x@server:~$ postconf -n | grep -E "myhostname|mydomain|myorigin"
myhostname = mail01.corp.internal
myorigin = /etc/mailname

cr0x@server:~$ dig +short A mail01.corp.internal
10.30.4.21

Qué significa: Si tu propio hostname no resuelve en la vista DNS que usas, provocarás rechazos remotos extraños y a veces fallos de política local.

Decisión: Asegúrate de que la identidad que Postfix presenta (myhostname, smtpd_banner, nombres TLS) sea resoluble y consistente en las vistas que importan.

Task 16: Si los diferimientos se acumulan, confirma crecimiento de cola y comportamiento de reintento

cr0x@server:~$ postqueue -p | tail -n 1
-- 12753 Kbytes in 2843 Requests.

Qué significa: Tienes un backlog. Postfix volverá a intentar, pero necesitas gestionar el impacto operativo: uso de disco, tormentas de rebotes y flujos de trabajo empresariales retrasados.

Decisión: Arregla DNS primero. Luego considera un vaciado controlado de la cola (postqueue -f) en una ventana tranquila y vigila límites remotos.

Tres mini-historias corporativas (anonimizadas, plausibles, técnicamente exactas)

Mini-historia 1: El incidente causado por una suposición incorrecta

Migraron un par de relays de correo a una nueva VPC. Todo lo demás ya estaba allí: servidores de aplicaciones, bases de datos, caches, el zoo habitual de la nube. El equipo supuso que DNS «simplemente funcionaría», porque DNS había funcionado para todo lo demás.

En menos de una hora, la cola de correo empezó a hincharse. No hubo alarmas, porque el servicio SMTP estaba arriba. La CPU bien. Los discos bien. Desde fuera parecía un martes tranquilo. Desde dentro, el correo saliente se acumulaba con errores host not found en múltiples dominios destinatarios.

La suposición que les pegó: «Si curl puede resolver nombres, Postfix también puede». Excepto que Postfix vivía en una imagen de contenedor endurecida con su propio /etc/resolv.conf fijado a una IP de resolvedor interno antigua que no existía en la nueva VPC. El DNS del host funcionaba; el del contenedor no.

Arreglarlo fue vergonzosamente simple: reconstruir el contenedor para usar el DNS de la plataforma y añadir una prueba que haga una búsqueda MX real durante el despliegue. Lo que dolió fue el tiempo invertido depurando «Postfix» mientras el fallo real era DNS.

También añadieron una alerta de profundidad de cola. No porque sea sofisticado, sino porque te dice la verdad incluso cuando todo lo demás miente.

Mini-historia 2: La optimización que salió mal

Un equipo de seguridad desplegó restricciones SMTP agresivas para reducir spam y suplantación. Buenos objetivos. Habilitaron reject_unknown_sender_domain y algunas comprobaciones adicionales de hostname cliente. Los logs de correo se veían más limpios. Menos remitentes basura evidentes. Todos se sintieron realizados.

Entonces llegó una ventana de mantenimiento rutinaria para los resolvedores DNS corporativos. No fue una caída total—solo una falla parcial donde un resolvedor respondió SERVFAIL de forma intermitente y el otro estaba bien. El tráfico web no lo notó porque navegadores y pilas de apps reintentaron, cachearon y enmascararon el problema. SMTP, sin embargo, hace decisiones de política en tiempo real por conexión. Los relays de correo empezaron a rechazar correo legítimo de forma esporádica durante la inestabilidad del DNS.

La «optimización» fue costosa operativamente: movieron el fallo de «entrega saliente diferida» (recuperable) a «correo entrante rechazado» (potencialmente perdido, según el comportamiento del remitente). Algunos remitentes reintentaron; otros no. Eso no es un fallo moral del remitente. Es solo cómo se comporta el ecosistema.

Mantuvieron las comprobaciones, pero cambiaron la filosofía: las negativas dependientes de DNS se aplicaron solo donde tenían alta confianza y bajo riesgo de pérdida, y construyeron monitorización de salud de resolvedores en la capa de correo. Lo más importante: decidieron que cuando DNS está degradado, el MTA debe degradarse con gracia—más diferimientos, menos rechazos permanentes.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Otra compañía tenía una regla aburrida: cada relay de producción ejecutaba un resolvedor local en caché (unbound) en localhost, con dos resolvedores upstream y timeouts estrictos. También tenían una verificación sintética pequeña: cada minuto, resolver MX para tres dominios externos bien conocidos y uno interno, desde el host de correo. La comprobación no era ingeniosa. Era simplemente persistente.

Una mañana, el DNS ascendente empezó a perder fragmentos UDP debido a un cambio de firewall. Algunas consultas seguían funcionando—las pequeñas. Otras hacían timeout—respuestas más grandes, respuestas con DNSSEC, ciertos conjuntos MX. Las comprobaciones sintéticas lo detectaron de inmediato porque las respuestas MX suelen ser «más pesadas» que registros A básicos.

La cola de correo empezó a crecer, pero ya tenían alertas para la longitud de cola y para la latencia de resolución DNS. La respuesta al incidente fue aburrida también: revertir la política de firewall, vaciar la caché del resolvedor, ver cómo la cola se vaciaba, y no tocar perillas no relacionadas.

No ganaron premios. Entregaron correo. En operaciones, ese es el premio.

Errores comunes: síntoma → causa raíz → solución

1) «Host not found» para muchos dominios a la vez

Síntoma: Varios dominios no relacionados fallando con errores en la búsqueda MX.

Causa raíz: Tu ruta de resolvedor está rota (un resolvedor ascendente caído, systemd-resolved confundido, firewall bloqueando DNS o fallos de validación DNSSEC).

Solución: Identifica qué resolvedor devuelve SERVFAIL/timeout, elimínalo de la rotación, restaura la conectividad de red y verifica con pruebas dig @resolver MX domain.

2) «Host not found» solo para un dominio destinatario

Síntoma: Un dominio falla consistentemente; otros se entregan.

Causa raíz: DNS del dominio remoto mal configurado (falta MX y sin fallback A, delegación rota, registro DS obsoleto causando fallo DNSSEC).

Solución: Verifica desde múltiples resolvedores. Si falla en todas partes, es problema de ellos; encola y reintenta. Si falla solo desde tu resolvedor corporativo, arregla tu resolvedor o evita usando un resolvedor recursivo estable para correo saliente.

3) Fallos intermitentes: funciona la mitad de las veces

Síntoma: El mismo dominio alterna entre funcionar y «host not found».

Causa raíz: Múltiples resolvedores con comportamiento inconsistente; la selección/timeout del resolvedor produce ruleta. A veces también es split-horizon DNS según la ruta de red.

Solución: Consulta cada resolvedor directamente. Elimina el malo. Si el split-horizon es intencional, asegura que el relay de correo esté en la vista DNS correcta consistentemente.

4) Entrega lenta, no fallo total

Síntoma: El correo eventualmente llega pero tarda minutos; las sesiones SMTP parecen lentas.

Causa raíz: Las búsquedas DNS están haciendo timeout antes de tener éxito (común con rutas IPv6 rotas, resolvedores sobrecargados o timeouts RBL).

Solución: Mide el tiempo de consulta con dig +stats. Arregla el rendimiento del resolvedor, asegura que IPv6 funcione de extremo a extremo o gestiona correctamente, y evita comprobaciones DNS síncronas en la ruta SMTP cuando tu SLO de resolvedor no es sólido.

5) Tras «arreglar DNS», Postfix sigue fallando por horas

Síntoma: Corregiste registros pero Postfix sigue viendo NXDOMAIN o respuestas incorrectas.

Causa raíz: Cachés. Caché negativo. Resolvedor local manteniendo datos antiguos. O arreglaste un servidor autoritativo pero no los demás.

Solución: Revisa TTLs y SOA. Vacía cachés locales donde corresponda. Verifica consistencia autoritativa. No sigas reiniciando Postfix; no es un sacrificio ritual que aplace a los dioses del resolvedor.

6) «Host not found» después de habilitar reglas anti-spam estrictas

Síntoma: El correo entrante se rechaza con comprobaciones de dominio/hostname durante pequeñas inestabilidades del DNS.

Causa raíz: Moviste la dependencia de DNS a la vía de decisión SMTP en vivo.

Solución: Reevalúa las restricciones. Prefiere diferimientos temporales sobre rechazos permanentes cuando el DNS es poco fiable. Monitoriza la salud del resolvedor y considera caché local con comportamiento predecible.

Broma #2: Reiniciar Postfix no arreglará DNS, pero sí quema calorías—principalmente tuyas.

Listas de verificación / plan paso a paso

Paso a paso: cuando estás perdiendo entrega de correo activamente

1. Confirma alcance: ¿Un dominio o muchos? Usa grep en logs de correo y entradas de la cola muestreadas.
2. Ejecuta consultas DNS directas: dig MX para dominios fallidos contra cada resolvedor configurado.
3. Clasifica el fallo: NXDOMAIN vs SERVFAIL vs timeout. No los trates igual.
4. Arregla la ruta de resolvedor:
   • Si un resolvedor está mal, elimínalo de la configuración o sácalo de servicio.
   • Si la red bloquea, arregla firewall/enrutamiento.
   • Si DNSSEC es el problema, corrige la cadena de validación; no desactives DNSSEC a ciegas en el resolvedor sin una decisión de riesgo clara.
5. Estabiliza el comportamiento de Postfix: Evita cambios de configuración durante el incidente. Primero sana DNS.
6. Vacia la cola con cuidado: Una vez estable DNS, considera postqueue -f y vigila límites remotos.
7. Endurecimiento post-incidente: Añade alertas de profundidad de cola, comprobaciones de latencia DNS y redundancia de resolvedores.

Checklist de endurecimiento: evitar que «host not found» sea una sorpresa

• Ejecuta un resolvedor en caché local en los relays de correo (o usa un diseño probado stub-a-recursive) y monitorízalo.
• Usa al menos dos resolvedores ascendentes saludables e independientes.
• Prueba DNS desde el mismo namespace de red/contenedor que ejecuta Postfix.
• Alerta sobre:
  • tamaño y tasa de crecimiento de la cola de correo
  • ritmo de líneas de log «Name service error»
  • latencia de consultas DNS y tasas de SERVFAIL desde hosts de correo
• Sé cauteloso con las restricciones SMTP que hacen DNS síncrono en la vía crítica.
• Documenta cómo debe funcionar el split-horizon DNS para los relays de correo. Si es «nadie lo sabe», fallará a las 3 a.m.
• Valida la entregabilidad saliente en CI/CD: al menos una búsqueda MX y una conexión SMTP de prueba a un dominio conocido.
• Mantén IPv6 completamente funcional o explícitamente diseñado. IPv6 medio-configurado es un impuesto de latencia.

Puntos de decisión operativos (los que generan discusión)

• ¿Bordeamos el DNS corporativo? Para relays de correo saliente, a veces sí—si el DNS corporativo es fuente frecuente de incidentes. Hazlo una decisión gestionada, no un apaño a medianoche.
• ¿Rechazamos correo entrante cuando DNS está inestable? Usualmente no. Prefiere fallos temporales para que los remitentes puedan reintentar.
• ¿Desactivamos IPv6? Solo si aceptas las consecuencias. Mejor: corrige IPv6, o asegura que el resolvedor y el enrutamiento no se queden bloqueados por ello.

Preguntas frecuentes

1) ¿Cuál es la diferencia entre NXDOMAIN y SERVFAIL en este contexto?

NXDOMAIN significa que el nombre de dominio no existe en DNS. SERVFAIL significa que el resolvedor no pudo completar la consulta (fallo ascendente, problema de validación DNSSEC, recursión deshabilitada, delegación defectuosa). NXDOMAIN es una respuesta de «no existe tal dominio»; SERVFAIL es «lo intenté y algo falló».

2) ¿Por qué Postfix dice «try again» si el dominio realmente no existe?

Postfix a menudo trata los fallos DNS como transitorios porque DNS es un sistema distribuido y los fallos pueden ser temporales. Además, «el dominio no existe» puede ser causado por problemas del resolvedor o vistas split-horizon. Si quieres un comportamiento de rebote determinista, necesitas decisiones de política informadas por señales DNS fiables.

3) ¿Puede un resolvedor malo realmente causar fallos intermitentes de correo?

Sí. Si tu sistema tiene dos resolvedores y la librería del resolvedor rota o falla imperfectamente, verás SERVFAIL/timeouts esporádicos. La entrega de correo entonces parece «aleatoria», porque depende de qué resolvedor respondió esa consulta en ese momento.

4) ¿Por qué importan las consultas AAAA si solo entregamos por IPv4?

Aun si la entrega acaba usando IPv4, el resolvedor puede seguir consultando AAAA y esperar timeouts o reintentos. Eso añade latencia y puede desencadenar «host not found» si la ruta del resolvedor es poco saludable. No necesitas amar IPv6. Sí tienes que tenerlo en cuenta.

5) ¿Cómo sé si esto es nuestro DNS o el DNS del destinatario?

Prueba desde tu host de correo contra múltiples resolvedores. Si tu resolvedor configurado falla pero un resolvedor conocido bueno devuelve MX correctos, probablemente es tu ruta de resolvedor. Si varios resolvedores independientes fallan igual, probablemente es el DNS del dominio destinatario o su delegación/estado DNSSEC.

6) ¿Reiniciar Postfix ayuda?

Rara vez. Postfix no suele cachear DNS de forma que un reinicio lo corrija. Los reinicios pueden añadir churn y retraso mientras la cola sigue creciendo. Arregla DNS y luego vacía la cola cuando esté estable.

7) ¿Por qué vemos «host not found» solo durante horas punta?

Tus resolvedores pueden estar sobrecargados, dejando caer consultas, o ser limitados por upstream. Los problemas en horas punta suelen ser capacidad o pérdida de paquetes disfrazados de «misterios DNS». Mide latencia y tasas de timeout durante la carga, no a las 2 p.m. cuando todo está calmado.

8) ¿Qué ajustes de Postfix amplifican más comúnmente los fallos DNS?

Las restricciones SMTP que hacen búsquedas DNS durante el manejo de la conexión (comprobaciones de dominio del remitente, comprobaciones de hostname del cliente) y el uso intensivo de RBL pueden convertir la lentitud del resolvedor en lentitud SMTP o en rechazos. No es intrínsecamente incorrecto—es un trade-off que debes hacer intencionalmente.

9) ¿Cómo mantengo el correo fluyendo durante un incidente de resolvedor?

A corto plazo: elimina el resolvedor fallido de tu configuración, o apunta los relays de correo a un resolvedor recursivo estable diseñado para producción. A medio plazo: ejecuta un resolvedor en caché local en el host de correo para suavizar fallos ascendentes y reducir latencia.

10) ¿Son reales los dominios de «search» en resolv.conf como problema para Postfix?

Pueden serlo. Un punto final faltante o un nombre parcial puede disparar consultas extra cuando el resolvedor añade dominios de búsqueda. Eso desperdicia tiempo y puede crear patrones de tráfico sorpresa. Para infraestructura de correo, sé conservador con dominios de búsqueda y prefiere nombres totalmente calificados en las configuraciones.

Conclusión: siguientes pasos que puedes hacer esta semana

Si solo haces tres cosas, haz estas:

1. Añade monitorización que refleje la realidad: alerta sobre profundidad de cola y fallos/latencia de búsquedas DNS desde los hosts de correo mismos.
2. Haz aburrida tu ruta de resolvedor: dos resolvedores ascendentes saludables, comportamiento predecible y, idealmente, un resolvedor en caché local en los relays de correo.
3. Evita convertir los pequeños fallos DNS en pérdida de correo: sé cauto con los rechazos SMTP dependientes de DNS a menos que tengas alta fiabilidad de resolvedor y una intención de negocio clara.

Luego planifica un ejercicio corto: elige un relay de staging, rompe intencionadamente una IP de resolvedor y observa qué sucede. Si tu sistema falla «silenciosamente», habrás aprendido algo impagable—y lo habrás aprendido sin que la producción ardiera.