DNS inverso (PTR): por qué tu correo sufre y cómo arreglar rDNS correctamente

Qué es realmente el DNS inverso (PTR)—y qué no es

El DNS normalmente responde: “¿A qué IP corresponde este nombre?” Eso es una consulta directa (A para IPv4, AAAA para IPv6).
El DNS inverso responde a una pregunta diferente: “¿A qué nombre corresponde esta IP?” Eso es un registro PTR.

Los registros PTR viven en zonas inversas especiales:
in-addr.arpa para IPv4 y ip6.arpa para IPv6.
Una dirección IPv4 como 203.0.113.45 se convierte en un nombre inverso como
45.113.0.203.in-addr.arpa. El propietario de la zona configura un PTR que apunta a un nombre de host, por ejemplo
mail01.example.com.

Esto es lo que PTR no es:

• No es autenticación. Un registro PTR no prueba que poseas un dominio. Prueba que quien controla la zona inversa hizo una afirmación.
• No es cifrado. No protege el correo en tránsito. Eso es TLS, MTA-STS y tecnologías afines.
• No es opcional si quieres entregabilidad consistente. SMTP técnicamente funciona sin rDNS; el filtrado moderno asume que mientes si lo omites.

La realidad incómoda: la entidad que controla rDNS suele ser tu ISP o proveedor en la nube, porque ellos controlan la asignación de IP y la delegación inversa.
Esto significa que no puedes “simplemente añadir un PTR en Cloudflare.” Puedes añadir registros directos para tu dominio allí. PTR está ligado a la zona inversa de la IP.

Por qué a los sistemas de correo les importa tanto el PTR

El correo es un juego de confianza federada jugado por máquinas que llevan décadas siendo engañadas. Si administras un servidor que recibe correo, te atacan con:
credential stuffing, botnets, hosts WordPress comprometidos, “plataformas de marketing” que actúan como malware, y negocios legítimos con higiene pésima.

Así que los receptores usan heurísticas baratas. PTR es una de las más económicas:
una consulta DNS, una cadena, juicio rápido. No es una puerta única, pero es una señal ruidosa en la puntuación anti-spam.

Qué infieren los receptores del rDNS

• ¿Esta IP “está pensada” para enviar correo? Muchos rangos residenciales y dinámicos tienen PTR como cpe-, dsl-, dynamic-. Eso es un fuerte “no”.
• ¿Este remitente se comporta como un MTA estable? Los MTAs reales tienen nombres estables y mapeos directo/inverso consistentes. A las botnets no les interesa eso.
• ¿El string HELO/EHLO parece sensato? Muchos receptores comparan el saludo SMTP con el nombre PTR, o al menos con un hostname resolvible.
• ¿El remitente está intentando demasiado? Los trucos de nombres “sobreoptimizados” pueden volverse en tu contra. Más sobre eso después.

Qué suele romper el rDNS

• Bloqueos duros por parte de receptores estrictos (algunas pasarelas empresariales aún hacen “sin PTR, sin correo”).
• Aumento de la puntuación de spam que te empuja por encima del umbral cuando se combina con otros problemas leves.
• Dolores de greylisting porque tu “identidad” no parece consistente entre reintentos.
• Sistemas de reputación que categorizan tu rango IP como dinámico/mal configurado.

Una frase que te ahorrará una semana: rDNS trata de la IP, no del dominio en tu From:
header. Si tu producto SaaS envía como billing@yourbrand.com pero lo hace desde una IP de VM aleatoria cuyo PTR es ip-10-0-3-44.internal,
le das a los filtros una razón fácil para desconfiar de ti.

Datos e historia interesantes: el papel sorprendentemente duradero del PTR

Algunos puntos de contexto que importan porque explican por qué lo “antiguo” sigue perjudicándote:

1. El DNS inverso llegó temprano. El sistema DNS y el mapeo inverso in-addr.arpa se definieron en los años 80 cuando Internet estandarizaba nombres.
2. PTR precede al anti-spam moderno. PTR no se diseñó para controlar spam; el spam hizo que fuera útil como señal barata.
3. SMTP es más antiguo que la mayoría del logic de filtrado. El comportamiento central de SMTP se especificó cuando la “identidad del host” era mayormente honesta y las redes eran más pequeñas.
4. Muchas pasarelas corporativas siguen exigiendo “PTR requerido”. Es rudimentario, pero mantiene fuera gran cantidad de basura con mínimo CPU.
5. Forward-confirmed reverse DNS (FCrDNS) se volvió una expectativa de facto. No es un requisito estricto del protocolo, pero los filtros lo tratan como algo básico.
6. IPv6 complicó más el DNS inverso. La zona inversa usa nibbles y es larga; la delegación y la corrección son fáciles de estropear.
7. La nube dividió la propiedad del rDNS. Puedes poseer el dominio en un sitio y alquilar la IP en otro, lo que crea puntos ciegos operativos.
8. Los grandes proveedores de bandeja rara vez documentan la puntuación exacta. rDNS no es “la” clave, pero forma parte de una postura más amplia: identidad estable, comportamiento consistente, bajas tasas de queja.
9. Los patrones de PTR dinámicos están intencionalmente estigmatizados. Muchos ISPs etiquetan las pools dinámicas en PTR precisamente para que los receptores puedan filtrarlas.

Broma #1: Los registros PTR son como las tarjetas de identificación en una conferencia—opcionales en teoría, sospechosos en la práctica, y siempre ausentes cuando los necesitas.

Guía de diagnóstico rápido: encuentra el cuello de botella en minutos

Cuando la entregabilidad cae, a los equipos les encanta discutir SPF vs DKIM vs “tal vez Microsoft está caído”. Empieza por lo que es más rápido de falsar.
Aquí está el orden que uso cuando estoy de guardia y mi café aún negocia con mi torrente sanguíneo.

1) Comprueba la IP de envío y su PTR (primero)

• Encuentra la IP saliente real usada (gateways NAT, balanceadores, hosts relays mienten por omisión).
• Verifica que exista un PTR y que parezca un host de correo, no un arrendamiento DHCP.
• Haz una comprobación de forward-confirmation: el nombre PTR resuelve de vuelta a la misma IP.

2) Comprueba el banner SMTP y la alineación HELO/EHLO (segundo)

• Asegúrate de que tu MTA anuncie un FQDN estable en su banner y HELO/EHLO.
• Asegúrate de que ese FQDN tenga registros A/AAAA y sea consistente con el nombre PTR (no necesariamente idéntico, pero tampoco absurdo).

3) Comprueba la autenticación (tercero)

• SPF pasa para la IP de envío.
• DKIM firma y verifica para el dominio From: (o un dominio alineado).
• La política y la alineación de DMARC no te sabotean (especialmente para correo transaccional).

4) Comprueba reputación y comportamiento de tasa (cuarto)

• Si la IP es nueva, espera requisitos de warming up.
• Busca picos: rebotes, quejas, cambios súbitos de volumen, problemas de higiene de listas.

5) Solo entonces indaga en contenido y plantillas (quinto)

• El contenido importa, pero si tu postura de identidad está rota, la prosa perfecta no te salvará.

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

Estas son comprobaciones pragmáticas que puedes ejecutar desde un host Linux con herramientas DNS básicas. Cada tarea incluye: un comando, qué significa la salida y la decisión que tomas.
Sustituye la IP/dominio de ejemplo por los tuyos.

Task 1: Find the public outbound IP from the host (sanity check)

cr0x@server:~$ curl -4 ifconfig.me
203.0.113.45

Significado: Esta es la dirección IPv4 que ven los servicios externos. Si esperabas otra cosa, estás detrás de NAT o el enrutamiento de salida difiere.

Decisión: Usa esta IP para las comprobaciones PTR/SPF. Si no es la IP de correo, detente y traza el egress.

Task 2: Confirm which IP your MTA is actually using (Postfix example)

cr0x@server:~$ postconf -n | egrep '^(smtp_bind_address|smtp_bind_address6|myhostname|myorigin|inet_interfaces) ='
myhostname = mail01.example.com
myorigin = /etc/mailname
inet_interfaces = all

Significado: No hay una dirección de bind explícita; Postfix seleccionará según el enrutamiento. Tu IP de egress puede ser diferente a la IP de la interfaz del servidor.

Decisión: Si necesitas una IP específica, establece smtp_bind_address (o arregla el enrutamiento/NAT), luego vuelve a comprobar qué ve el mundo.

Task 3: Reverse lookup (PTR) for your sending IP

cr0x@server:~$ dig +short -x 203.0.113.45
mail01.example.com.

Significado: El PTR existe y apunta a mail01.example.com.

Decisión: Continúa con la forward-confirmation. Si está vacío, necesitas establecer PTR con tu ISP/proveedor en la nube.

Task 4: Check for multiple PTRs (usually a smell)

cr0x@server:~$ dig -x 203.0.113.45 +noall +answer
45.113.0.203.in-addr.arpa. 3600 IN PTR mail01.example.com.

Significado: Exactamente un PTR. Múltiples PTRs pueden confundir a filtros y humanos.

Decisión: Mantén un PTR estable por IP de envío a menos que tengas una razón muy específica y bien entendida.

Task 5: Forward lookup of the PTR name (A record)

cr0x@server:~$ dig +short A mail01.example.com
203.0.113.45

Significado: El nombre PTR resuelve de vuelta a la misma IP. Este es el patrón clásico de “forward-confirmed reverse DNS” que los receptores aprecian.

Decisión: Si el A apunta a otro sitio, arregla tu DNS (o ajusta el PTR para que coincida con la realidad).

Task 6: Check IPv6 rDNS too (even if you “mostly use IPv4”)

cr0x@server:~$ dig +short -x 2001:db8:abcd:10::25
mail01.example.com.

Significado: Tu IPv6 también tiene PTR configurado. Bien. Si tu servidor puede enviar por IPv6, algunos destinatarios lo verán.

Decisión: Si falta, configura PTR IPv6 o desactiva el SMTP saliente por IPv6 hasta que esté correcto.

Task 7: Verify the SMTP banner and EHLO name from the outside

cr0x@server:~$ nc -v mail01.example.com 25
Connection to mail01.example.com 25 port [tcp/smtp] succeeded!
220 mail01.example.com ESMTP Postfix

Significado: El banner usa un FQDN apropiado. Si dice localhost o un nombre interno, los filtros te verán amateur.

Decisión: Ajusta myhostname correctamente y asegúrate de que resuelva en DNS público.

Task 8: Confirm the server’s HELO/EHLO string during a test session

cr0x@server:~$ printf "EHLO test.example.net\r\nQUIT\r\n" | nc -w 3 mail01.example.com 25
220 mail01.example.com ESMTP Postfix
250-mail01.example.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME

Significado: El servidor responde con su identidad. Muchos receptores comparan lo que afirmas en EHLO con PTR/banner.

Decisión: Si la identidad EHLO es extraña, corrige la configuración del MTA antes de perseguir fantasmas SPF.

Task 9: Check SPF for the From: domain (does it authorize the sending IP?)

cr0x@server:~$ dig +short TXT example.com | sed -n 's/"//g;/^v=spf1/p'
v=spf1 ip4:203.0.113.45 -all

Significado: SPF explícitamente permite la IP y prohíbe otras. Ideal para correo transaccional desde un host único.

Decisión: Si falta SPF o es muy estricto para tu ruta real de envío, arréglalo. PTR no compensará fallos de SPF.

Task 10: Check if your IP is in a “dynamic” reverse naming scheme (pattern recognition)

cr0x@server:~$ dig +short -x 198.51.100.77
cpe-198-51-100-77.isp.example.

Significado: El PTR grita “banda ancha de consumo”. Puedes ejecutar un MTA desde ahí, pero muchos receptores te tratarán como una botnet.

Decisión: Mueve el correo saliente a un rango de IPs estáticas/empresariales o a un relay reputado. No luches contra la física.

Task 11: Validate that the reverse zone is reachable and not SERVFAIL-ing

cr0x@server:~$ dig -x 203.0.113.45 +time=2 +tries=1
; <<>> DiG 9.18.24 <<>> -x 203.0.113.45 +time=2 +tries=1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53112
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
45.113.0.203.in-addr.arpa. 3600 IN PTR mail01.example.com.

;; Query time: 26 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Dec 31 12:00:00 UTC 2025
;; MSG SIZE  rcvd: 96

Significado: NOERROR y hay respuesta. Si ves SERVFAIL, probablemente tienes delegación rota o servidores de nombre “lame” para la zona inversa.

Decisión: Escala al propietario/proveedor de la IP; esto no es un problema de “cambia tu MTA”.

Task 12: Inspect a bounce for rDNS/PTR clues (don’t guess; read)

cr0x@server:~$ grep -iE 'ptr|reverse|rdns|helo|host name|554|550' /var/log/mail.log | tail -n 6
Dec 31 12:01:12 mail01 postfix/smtp[22145]: host mx.receiver.example[192.0.2.10] said: 550 5.7.1 Client host rejected: cannot find your reverse hostname (in reply to RCPT TO command)
Dec 31 12:01:12 mail01 postfix/smtp[22145]: to=<user@receiver.example>, relay=mx.receiver.example[192.0.2.10]:25, delay=0.6, delays=0.1/0/0.2/0.3, dsn=5.7.1, status=bounced (host mx.receiver.example[192.0.2.10] said: 550 5.7.1 Client host rejected: cannot find your reverse hostname (in reply to RCPT TO command))

Significado: El receptor te rechazó explícitamente por falta de rDNS. Esto es lo más cercano que tiene el correo a un mensaje de error claro.

Decisión: Arregla PTR y verifica; vuelve a encolar el correo tras la corrección.

Task 13: Confirm outbound connections use the IP you think they do

cr0x@server:~$ sudo ss -ntp | awk '$4 ~ /:25$/ {print $4, $5}' | head
203.0.113.45:54322 192.0.2.10:25
203.0.113.45:54324 192.0.2.11:25

Significado: La IP de origen es 203.0.113.45 para SMTP saliente. Bien: es la IP que comprobaste.

Decisión: Si ves otra IP de origen, has estado depurando la dirección equivocada. Arregla el enrutamiento/NAT o la configuración bind del MTA.

Task 14: Confirm your resolver isn’t lying (query a public resolver)

cr0x@server:~$ dig +short -x 203.0.113.45 @1.1.1.1
mail01.example.com.

Significado: Un resolvedor público está de acuerdo. Si tu resolvedor local muestra otra cosa, puedes tener caché o split-horizon extraño.

Decisión: Usa resolución externa como fuente de la verdad para la entregabilidad. La caché local no recibe el correo por el mundo.

Broma #2: Nada dice “confíame” como un servidor de correo cuyo DNS inverso es ubuntu. Eso es básicamente ponerse un bigote falso en un banco.

Cómo arreglar rDNS correctamente: las partes aburridas que importan

Arreglar PTR es simple en concepto y molesto en ejecución porque el plano de control suele estar fuera de tu proveedor DNS.
La solución correcta es menos “DNS ingenioso” y más “hacer explícita la propiedad y el nombrado”.

Step 1: Decide what the PTR should be

Elige un hostname que:

• Sea un nombre de dominio totalmente calificado que controles (por ejemplo, mail01.example.com).
• Sea estable en el tiempo (no ligado a instancias autoescaladas a menos que lo gestiones intencionalmente).
• Tenga un registro A coincidente (y AAAA si usas IPv6).
• No finja ser el dominio del receptor ni otra marca. A los filtros no les gusta el cosplay.

Step 2: Create forward DNS first (A/AAAA)

Muchos proveedores no aceptarán un valor PTR que no resuelva. Incluso cuando lo hagan, quieres la forward-confirmation de todos modos.
Crea:

• mail01.example.com A 203.0.113.45
• mail01.example.com AAAA 2001:db8:abcd:10::25 (si procede)

Step 3: Set the PTR with whoever owns the IP space

Esta es la parte que la gente falla. Los registros PTR no se suelen establecer en el archivo de zona de tu dominio.
Se establecen:

• En la consola de tu proveedor en la nube (para IPs elásticas/públicas), o
• A través de un ticket/correo a tu ISP / proveedor de colocación, o
• Mediante delegación de zona inversa si controlas un bloque de IPs suficientemente grande (raro, pero común en empresas grandes).

Step 4: Wait for propagation, then verify externally

Los cambios de PTR se propagan como cualquier cambio DNS: las cachés respetan TTLs y algunos resolvedores conservan datos obsoletos más tiempo del que deberían.
Verifica desde múltiples redes/resolvedores. Tu portátil en la VPN de la oficina no es un oráculo fiable.

Step 5: Align the MTA identity with reality

Para Postfix, lo básico es:

• myhostname debe ser el FQDN público (a menudo el nombre PTR).
• smtpd_banner no debe exponer basura, pero debe ser consistente.
• Tu servidor debe usar ese hostname en HELO/EHLO, ya sea por defecto o explícitamente.

Para otros MTAs (Exim, Sendmail, Exchange), el principio se mantiene: el nombre que presentas durante SMTP debe resolver y no debe contradecir el PTR.

Step 6: Don’t forget the network edge

Si envías a través de:

• Gateways NAT (comunes en VPCs en la nube), tu IP de envío es la IP pública del NAT, no la de la instancia.
• Relays salientes / smart hosts, la IP y rDNS del relay importan más que los tuyos.
• Balanceadores de carga (raro para SMTP, pero sucede), asegúrate de que la identidad del backend no se filtre o desajuste.

rDNS no es una “configuración que se hace una vez” cuando tu enrutamiento cambia cada mes.
Hazlo parte de la gestión de cambios del egress de red, no una memoria tribal.

Alineación: PTR, A/AAAA, HELO/EHLO, SPF, DKIM, DMARC

Los fallos de entregabilidad gustan de la compañía. PTR rara vez es el único problema, pero a menudo es la primera razón fácil para desconfiar de ti.
El objetivo no es “alineación perfecta” como en un examen de cumplimiento; el objetivo es “no contradicciones obvias”.

Las reglas de alineación que importan en la práctica

• PTR ↔ A/AAAA: El hostname del PTR debe resolver de vuelta a la misma IP de envío. Esto es la verificación FCrDNS.
• HELO/EHLO ↔ DNS: El nombre HELO debe ser un FQDN resolvible con A/AAAA. Evita IPs crudas en HELO a menos que disfrutes ser filtrado.
• SPF ↔ IP de envío: La IP que se conecta al receptor debe estar autorizada por SPF para el dominio envelope-from (o el dominio HELO, dependiendo de la lógica del receptor).
• DKIM ↔ dominio del mensaje: DKIM debe firmar con un dominio alineado con el From: visible para que DMARC pase.
• DMARC ↔ política: DMARC no usa PTR, pero fallos de DMARC + rDNS débil son un golpe combinado común.

Cómo se ve “bien”

Una configuración limpia y aburrida para correo transaccional:

• IP de salida: 203.0.113.45
• PTR: mail01.example.com
• Registro A: mail01.example.com → 203.0.113.45
• Banner SMTP/HELO: mail01.example.com
• SPF: incluye la IP de envío (o el relay), lo suficientemente estricto para prevenir abuso
• DKIM: habilitado y con claves estables
• DMARC: al menos p=none mientras lo implementas, luego ajusta conforme ganes confianza

Cómo se ve “mal”

• PTR está vacío, o apunta a ip-203-0-113-45.provider.example mientras tu HELO es mail.yourbrand.com.
• PTR apunta a un hostname, el A apunta a una IP distinta y tu banner SMTP usa un tercer nombre.
• IPv6 está activado y se usa, pero no tiene PTR, así que la mitad de tu tráfico parece roto según la preferencia del receptor.
• Envías desde una IP compartida donde no puedes controlar PTR; el comportamiento del vecino te arrastra abajo.

Un principio operacional para tener en una nota: la consistencia vence a la astucia.
Los receptores hacen comparación de patrones, no leen tu diagrama de arquitectura.

Cita (idea parafraseada) de Gene Kranz: “Sé duro y competente.” En términos de entregabilidad: sé aburrido y correcto, todos los días.

Tres historias corporativas desde el frente

1) Incidente causado por una suposición errónea: “Configuramos DNS, así que rDNS está hecho”

Una empresa B2B mediana migró su servicio de notificaciones de un proveedor gestionado a “Postfix autogestionado para ahorrar costes.”
El despliegue fue fluido: SPF actualizado, DKIM implementado, DMARC en modo monitor, plantillas probadas.
Su entorno de staging entregaba bien. Producción no.

La cola de soporte empezó a llenarse con “no recibí mi restablecimiento de contraseña.” Ventas lo escaló porque los prospectos dejaron de recibir invitaciones de prueba.
Ingeniería revisó métricas: el MTA estaba entregando mensajes al siguiente salto, la cola no crecía y los logs mostraban rebotes—algunos de pasarelas estrictas,
otros de grandes proveedores de bandeja, y un número sospechoso que simplemente desaparecía en la purgatoria del greylisting.

La suposición errónea: el equipo creyó que crear mail01.company.com y su registro A significaba que el DNS inverso estaba “cubierto”.
Habían hecho trabajo de DNS en su zona autorizada y marcaron mentalmente la casilla “DNS hecho”.
Nadie preguntó quién posee la zona inversa de la IP. No era ellos.

La solución fue poco glamorosa. Abrieron una solicitud al proveedor para establecer el PTR de la IP de egress pública a mail01.company.com.
Alinearon el banner de Postfix y el HELO para que coincidieran. Desactivaron IPv6 hasta que el proveedor configurara también el PTR IPv6.
En un día, los rebotes duros por “sin PTR” cesaron y los retrasos por greylisting se redujeron porque la identidad del remitente dejó de cambiar.

El cambio duradero: un paso en el runbook que dice “PTR es propiedad del proveedor de la IP; verifica con dig -x desde fuera.”
Es el tipo de conocimiento institucional que solo obtienes después de que Producción te humille frente a Finanzas.

2) Optimización que salió mal: “Hagamos rDNS por cliente para mejor branding”

Una plataforma empresarial quería que el correo de cada cliente “pareciera venir de ellos” aunque se enviara desde la infraestructura del proveedor.
Alguien propuso: asignar un pool de IPs y poner PTRs como customer-a-mail.vendor.example, customer-b-mail.vendor.example,
quizá incluso usar el dominio del cliente en PTR para mejorar la confianza.

En papel parecía ingenioso: segmentar reputación, aislar inquilinos ruidosos y dar a los clientes una sensación de control.
En realidad se volvió una telaraña frágil. Los cambios de PTR dependían de automatización y flujos de tickets.
A veces los registros directos iban por detrás de las actualizaciones de PTR. A veces la identidad HELO no se actualizaba con el mapeo del cliente.
A veces el pool rotaba más rápido de lo que expiraban los TTLs.

Los receptores vieron inconsistencia: la IP conectante tenía PTR customer-a-mail.vendor.example, pero el HELO decía mail-gw.vendor.example.
O el PTR apuntaba a un nombre cuyo A aún no existía.
La entregabilidad de la plataforma no solo falló; falló intermitentemente, que es el peor tipo de fallo porque genera superstición.

El retroceso fue predecible: los patrones de “identidad dinámica” parecen abuso.
Algunos filtros tratan combinaciones PTR/HELO que cambian frecuentemente como sospechosas porque las botnets exhiben esa misma inestabilidad.
Mientras tanto, la carga operativa aumentó: más piezas móviles, más problemas de temporización de propagación, más excepciones.

Finalmente hicieron rollback. Mantuvieron IPs dedicadas para clientes de alto volumen pero volvieron a un esquema de nombres estable y aburrido:
un pequeño conjunto de hostnames de gateway de correo con PTR y HELO consistentes, y la separación de inquilinos gestionada por dominios de sobreenvelope y autenticación.
El branding pertenece al campo From: y a la alineación DKIM, no a la gimnasia con PTR.

3) Práctica aburrida pero correcta que salvó el día: cheques previos en la canalización de despliegue

Una compañía con un entorno regulado enviaba correo saliente desde una capa de relays controlada. No eran rápidos, pero eran consistentes.
Cada cambio de infraestructura pasaba por una lista de verificación: inventario de IPs de egress, verificación de PTR, autorización SPF, ajustes TLS, monitorización de códigos de rebote.

Durante una renovación de red se introdujo un nuevo gateway NAT para simplificar el enrutamiento. Funcionó. El tráfico fluyó.
Pero la IP de salida cambió. Aquí es donde la mayoría de equipos aprenden sobre rDNS a la fuerza—después de que lleguen las quejas.

Su pipeline lo captó antes de que los usuarios de producción notaran. Un job de preflight ejecutó búsquedas inversas contra la IP candidata de egress y comparó resultados
contra una lista de permitidos de nombres PTR aprobados. Falló el cambio porque la IP NAT tenía PTR por defecto del proveedor.
La migración se pausó, se solicitó el PTR y la migración continuó una vez verificada.

No pasó nada dramático. Esa fue la victoria.
La fiabilidad suele ser una serie de pequeñas decisiones “no” tomadas lo suficientemente temprano como para que nadie lo llame incidente.

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

1) Síntoma: “550 5.7.1 Client host rejected: cannot find your reverse hostname”

Causa raíz: No hay registro PTR para la IP conectante, o la delegación DNS inversa está rota.

Solución: Configura PTR con el propietario/proveedor de la IP. Verifica con dig -x desde un resolvedor público. Si SERVFAIL, escala problemas de delegación de la zona inversa.

2) Síntoma: El correo llega a spam en algunos proveedores, a la bandeja en otros

Causa raíz: rDNS existe pero no coincide con el DNS directo (FCrDNS falla), o el nombre HELO no resuelve.

Solución: Asegura que el hostname del PTR tenga A/AAAA que vuelvan a la IP de envío, y que el HELO del MTA use un FQDN resolvible consistente con PTR.

3) Síntoma: Todo funcionaba hasta un “cambio de red menor”

Causa raíz: La IP de salida cambió (nuevo NAT, nueva ruta de egress), pero no se actualizaron PTR/SPF.

Solución: Trata la IP de egress como una dependencia. Actualiza PTR y SPF antes del corte; verifica con consultas DNS externas.

4) Síntoma: Entregabilidad IPv4 OK, IPv6 terrible

Causa raíz: IPv6 no tiene PTR, o el AAAA apunta a otro sitio, o la zona inversa IPv6 del proveedor no está delegada.

Solución: Establece PTR y AAAA IPv6 correctamente, o desactiva SMTP por IPv6 hasta que esté alineado. No permitas que un IPv6 parcialmente configurado te degrade.

5) Síntoma: PTR configurado correctamente, pero algunos receptores aún dicen “sin inverso”

Causa raíz: Propagación/caché DNS, o no estás probando la IP real que se conecta, o confusión por DNS split-brain.

Solución: Confirma la IP de origen con ss o logs del MTA; consulta resolvedores públicos; espera los TTLs; vacía cachés locales donde proceda.

6) Síntoma: No puedes establecer PTR en la interfaz de tu proveedor DNS

Causa raíz: No controlas la zona inversa de la IP. Tu proveedor DNS de dominio es irrelevante aquí.

Solución: Usa la función PTR del proveedor en la nube o abre un ticket con tu ISP. Si posees el bloque de IPs, organiza la delegación inversa correctamente.

7) Síntoma: PTR apunta a un hostname, pero el registro A apunta a una IP diferente “por diseño”

Causa raíz: Abstracción intentada (balanceador, pool o nombres de marca) sin considerar las comprobaciones FCrDNS.

Solución: Haz que el hostname del PTR mapee de vuelta a la misma IP. Si necesitas abstracción, hazla en capas superiores, no rompas las señales de identidad.

8) Síntoma: La entregabilidad varía por inquilino/cliente en infraestructura compartida

Causa raíz: Reputación de IP compartida y control limitado sobre PTR/identidad. El comportamiento del vecino envenena la pool.

Solución: Usa IPs dedicadas para correo saliente o un servicio relay reputado. Si debes compartir, aplica controles estrictos de abuso y políticas de tasa.

Listas de verificación / plan paso a paso

Checklist A: Nuevo servidor de correo saliente (mínimo viable “no vergonzoso”)

1. Elige un hostname estable para el MTA: mail01.example.com.
2. Crea registro A: mail01.example.com → your outbound IPv4.
3. Crea registro AAAA si usas IPv6: mail01.example.com → your outbound IPv6.
4. Solicita/establece PTR para IPv4 a mail01.example.com.
5. Solicita/establece PTR para IPv6 a mail01.example.com (o desactiva IPv6 saliente).
6. Configura el banner/HELO del MTA para usar mail01.example.com.
7. Asegura que el egreso por puerto 25 esté permitido y sea estable (los proveedores en la nube a veces lo restringen).
8. Configura SPF para autorizar tu(s) IP(s) de salida o el relay.
9. Habilita firma DKIM para el dominio From: visible.
10. Configura DMARC en modo monitor inicialmente y endurece conforme ganes confianza.
11. Envía una prueba a un buzón externo controlado; inspecciona cabeceras para resultados de autenticación.
12. Configura monitorización: códigos de rebote, profundidad de cola, anomalías de tasa y comprobaciones DNS para PTR/FCrDNS.

Checklist B: Cuando cambias la red (NAT, egress, proveedores)

1. Haz inventario de las nuevas IP(s) de egress para SMTP.
2. Pre-provisiona PTR para cada IP (v4 y v6).
3. Asegura que los hostnames PTR tengan A/AAAA que vuelvan a esas IPs.
4. Actualiza SPF para incluir las nuevas IP(s) (o mecanismo include del relay).
5. Ejecuta verificación externa: dig -x contra múltiples resolvedores.
6. Corta gradualmente si es posible; vigila logs de rebote por rechazos relacionados con rDNS.
7. Mantén las IP(s) antiguas en servicio hasta que caches y sistemas remotos converjan, si el negocio lo permite.

Checklist C: Guardarraíles operativos que evitan regresiones en rDNS

1. Documenta quién posee los cambios PTR (¿consola del proveedor? ¿cola de tickets del ISP?). Pon nombres responsables.
2. Registra las IPs de salida en la gestión de configuración, no en la memoria de alguien.
3. Añade un job periódico para validar: outbound IP → existe PTR → hostname PTR → A/AAAA devuelve la misma IP.
4. Alerta en caso de fallo, pero mantén bajo el ruido (diario es suficiente a menos que cambies IPs con frecuencia).
5. En incidentes, exige al equipo identificar la IP conectante antes de debatir DNS.

Preguntas frecuentes

1) ¿Necesito DNS inverso para que el correo funcione?

SMTP aún entregará a algunos destinos sin PTR, pero muchos receptores te rechazarán o pondrán en spam. Si la entregabilidad importa, trata PTR como requisito.

2) ¿Dónde creo un registro PTR?

Con quien controle la zona inversa de la IP—tu ISP, proveedor de hosting o plataforma en la nube. Tu proveedor DNS habitual normalmente no puede fijar PTR para IPs alquiladas.

3) ¿El PTR debe coincidir con mi registro MX?

No necesariamente. PTR debe representar el host/IP que se conecta. Tus registros MX representan el enrutamiento entrante para un dominio.
A menudo están relacionados, pero forzarlos a coincidir no es un requisito y puede ser contraproducente.

4) ¿Qué es FCrDNS y lo necesito?

Forward-confirmed reverse DNS significa: IP → nombre PTR, y el nombre → A/AAAA incluye la misma IP. No es una ley formal, pero es una comprobación común de los filtros.
Si puedes cumplirla, hazlo. Elimina una excusa fácil para desconfiar de ti.

5) ¿Puedo usar un PTR como “smtp.example.com” si varias IPs envían correo?

Puedes, pero entonces el mapeo A/AAAA se complica. Si varias IPs comparten el mismo PTR, FCrDNS puede fallar a menos que el registro directo liste todas las IPs.
Operativamente, un hostname único por IP es más limpio para entregabilidad y resolución de problemas.

6) ¿Y los IPs compartidos donde no puedo controlar PTR?

Esa es una desventaja estructural. Heredas reputación y a veces malas prácticas de rDNS.
Para correo serio saliente, usa una IP dedicada o un relay donde controlen PTR y reputación correctamente.

7) Si mi PTR es correcto, ¿garantiza la entrega en la bandeja de entrada?

No. PTR es condición necesaria, no garantía. La entregabilidad depende de autenticación, reputación, tasas de queja, higiene de listas, patrones de volumen y contenido.
PTR solo evita que falles la prueba de “competencia básica”.

8) ¿Qué rapidez tienen los cambios de PTR en propagarse?

Depende de los TTLs y del comportamiento de caché de los resolvedores. Espera desde minutos hasta horas. Algunos sistemas retienen datos antiguos más tiempo del que quisieras.
Siempre verifica desde múltiples resolvedores públicos y redes externas antes de declarar victoria.

9) ¿DMARC exige PTR?

DMARC no comprueba PTR. Pero los receptores evalúan muchas señales juntas. Un pase de DMARC puede verse socavado por una identidad de host obviamente rota.
A la inversa, un buen rDNS no puede rescatar una falla de alineación DMARC.

10) ¿Debo desactivar IPv6 si no puedo obtener PTR IPv6?

Si tu MTA puede enviar por IPv6 y la identidad IPv6 está rota, desactivar el IPv6 saliente suele ser la movida pragmática hasta que puedas arreglarlo correctamente.
Un IPv6 medio configurado es una trampa para la entregabilidad.

Siguientes pasos que puedes hacer hoy

1. Identifica tu IP real de envío. No supongas; verifica mediante logs o sockets salientes.
2. Ejecuta comprobaciones PTR + FCrDNS desde al menos un resolvedor público.
3. Haz el HELO y el banner del MTA aburridos y resolvibles. Idealmente alinéalo con el PTR.
4. Arregla IPv6 deliberadamente. O bien configura AAAA + PTR IPv6 correctamente o mantén IPv6 fuera del SMTP saliente por ahora.
5. Operationalízalo. Añade una comprobación recurrente y un paso en la gestión de cambios ligado a actualizaciones del egress de red.

El DNS inverso no es glamoroso y no ganará premios de arquitectura. Por eso está tan a menudo roto.
Pero si envías correo desde tus propios sistemas, rDNS es la diferencia entre “servicio profesional” y “duendecillo misterioso del correo”.
Elige lo aburrido. Tu colocación en la bandeja de entrada te lo agradecerá.