rDNS/PTR ausente: la corrección aburrida de DNS que salva la entregabilidad del correo

Qué es rDNS/PTR realmente (y por qué al correo le importa)

DNS normalmente responde: “¿Qué IP tiene mail.example.com?” Eso es DNS directo (registros A/AAAA). El reverse DNS responde lo contrario: “¿Qué nombre pertenece a 203.0.113.10?” Eso es un registro PTR almacenado bajo una zona de mapeo inverso especial (in-addr.arpa para IPv4 y ip6.arpa para IPv6).

Para el correo, ese mapeo inverso se convierte en una señal barata: “¿El operador de esta IP es lo suficientemente competente como para configurar DNS básico correctamente, y el hostname afirmado parece coherente con el resto de la identidad?” Los receptores no necesitan rDNS para entregar un paquete. Lo usan para decidir si confían en un remitente lo suficiente como para colocar el mensaje en la bandeja de entrada en lugar de la purgatoria del spam.

La expectativa central de entregabilidad: coherencia

Los receptores normalmente esperan que lo siguiente coincida:

• La IP que se conecta al servidor SMTP tiene un PTR que resuelve a un hostname, por ejemplo mail01.example.com.
• Ese hostname tiene un registro A/AAAA que resuelve de nuevo a la misma IP (forward-confirmed reverse DNS, frecuentemente abreviado FCrDNS).
• El nombre con que se saluda el SMTP (HELO/EHLO) coincide (o al menos pertenece a la misma familia de dominios que) con ese hostname.
• SPF/DKIM/DMARC se alinean con los dominios de envelope-from y/o header-from (no es estrictamente rDNS, pero los problemas de rDNS suelen correlacionarse con “lo demás también está desordenado”).

Fíjate en lo que no está en la lista: “El PTR debe coincidir con el dominio From:”. Eso es un malentendido común. Puedes enviar correo como @example.com desde un host llamado smtp-out.provider.net; se hace constantemente por remitentes legítimos. Pero si administras tu propia infraestructura, alinear estas señales sale más barato que depurar por qué Outlook está de mal humor hoy.

Una regla práctica: si operas la IP, deberías poder establecer el PTR. Si no controlas la IP (hosting compartido, ISP de consumo, dirección dinámica), no estás ejecutando un servidor de correo saliente de producción; estás ejecutando un experimento.

Broma corta #1: El reverse DNS es como poner el nombre en la puerta de tu oficina. La gente aún puede entrar al edificio sin él, pero asumirán que eres el becario y te enviarán a la carpeta de spam.

Cómo los sistemas receptores usan rDNS (comportamiento real, no folklore)

Diferentes receptores ponderan rDNS de distinta manera, y no publican la matemática exacta. Pero rDNS aparece en tres lugares que importan operacionalmente:

1) Rechazos duros y puertas de política

Algunas organizaciones (especialmente en industrias reguladas) configuran gateways de entrada para rechazar conexiones SMTP que carecen de PTR o que tienen un PTR de aspecto genérico. La lógica es brusca: “Si no te molestas en configurar rDNS, no eres serio.” Es rudimentario, pero fácil de explicar a los auditores.

Muchos proveedores grandes de consumo son más matizados: la falta de PTR por sí sola puede no ser un rechazo instantáneo, pero puede combinarse con señales de reputación (IP nueva, bajo volumen, contenido extraño, mala alineación DKIM) y empujarte al límite.

2) Puntuación de spam y limitación de velocidad

rDNS y FCrDNS a menudo alimentan heurísticas: un mapeo inconsistente o faltante aumenta la sospecha, lo que puede significar colocación en spam, limitación de tasa o comportamiento tipo greylisting. Aquí es donde se vuelve frustrante: tu correo “a veces funciona”, salvo para el 15% de destinatarios que están detrás de una política de entrada estricta.

3) Respuesta a incidentes y gestión de abuso

Cuando te marcan por abuso, alguien—humano o máquina—intenta averiguar quién posee la IP. PTR no es propiedad autoritativa, pero es una migaja. Un nombre rDNS limpio y consistente que apunte a un dominio con postmaster/abuse operativos hace que el mundo te trate como un adulto. Un PTR como ip-203-0-113-10.somecloud.internal no ayuda en nada.

Lo que los receptores no hacen (usualmente)

Los receptores por lo general no te “autentican” mediante PTR. PTR puede ser falsificado por quien controla la delegación de la zona inversa de la IP (casi siempre el ISP/proveedor cloud). Es una señal débil por diseño. Pero a los filtros de spam les encantan las señales débiles: muchas, ponderadas y combinadas.

Mentalidad operativa: rDNS no es una bala de plata para entregabilidad. Es lo mínimo indispensable. No ganas por tenerlo; pierdes por no tenerlo.

Hechos e historia: por qué esto sigue existiendo

rDNS se siente como la línea fija de las funciones DNS: todos fingen que está obsoleto, pero aún ejecuta la mitad de la lógica empresarial mundial. Algunos hechos concretos y contextos históricos que explican por qué:

1. Los registros PTR son anteriores a las defensas anti-spam modernas. El mapeo inverso existía tempranamente como conveniencia para nombrar hosts desde IPs; el correo después lo adoptó como una pista de confianza.
2. Las zonas inversas suelen ser controladas por los dueños de las IPs, no por los dueños de los dominios. Por eso a menudo no puedes configurar PTR desde la interfaz de tu proveedor DNS habitual.
3. El espacio de nombres del reverse DNS es separado. IPv4 usa in-addr.arpa con octetos invertidos; IPv6 usa ip6.arpa con nibbles invertidos—sí, es tan divertido como suena.
4. “FCrDNS” (forward-confirmed reverse DNS) es un patrón, no un protocolo. Es una comprobación de coherencia: PTR → nombre → A/AAAA → misma IP.
5. Las defensas anti-spam tempranas se apoyaban en rDNS porque es barato. Las consultas DNS eran fáciles, y muchos spammers usaban pools dinámicos sin PTRs estables.
6. Algunas redes deliberadamente establecen PTR genéricos para rangos de consumidores. Eso ayuda a los sistemas de correo a detectar “probable origen residencial” cuando alguien intenta ejecutar servidores SMTP.
7. El correo es uno de los últimos sistemas que aún recompensa señales de infraestructura estática. HTTP no se preocupa por tu PTR. SMTP, cultural y técnicamente, todavía sí.
8. Los proveedores principales combinan cada vez más señales de identidad. rDNS por sí solo no te salvará, pero un PTR faltante suele correlacionarse con SPF/DKIM/DMARC ausentes, y los filtros tratan la correlación como confesión.
9. IPv6 complicó operativamente el rDNS. El nombre inverso es largo, la delegación por nibbles es engorrosa y fácil de olvidar en despliegues—por eso se convierte en un culpable frecuente de “¿por qué falla el correo v6?”.

Una cita que merece estar en toda pared de ops, aunque solo la recuerdes durante incidentes: Everything fails, all the time. — Werner Vogels

rDNS es un pequeño “todo falla”. Trátalo como tal.

Guía rápida de diagnóstico

Esta es la lista que ejecutas cuando “alguien escaló entregabilidad” antes de empezar a culpar al contenido, la automatización de marketing o la fase de la luna.

Primero: identifica la IP real de salida usada para el correo saliente

• Confirma qué IP ven los destinatarios en los logs SMTP o en los mensajes de rebote.
• Si usas un relay, confirma si estás en un pool compartido o en IPs dedicadas.
• Si tienes múltiples NICs, NAT, egress de Kubernetes o un firewall que reescribe la IP de origen, asume que estás equivocado hasta que se demuestre lo contrario.

Segundo: comprueba existencia y corrección del PTR

• ¿No hay PTR en absoluto? Arregla eso primero. Deja de debatir.
• ¿El PTR existe pero es genérico o apunta al dominio equivocado? Decide si puedes cambiarlo; si no, mueve el correo a una IP mejor.

Tercero: verifica FCrDNS y el saludo SMTP

• El hostname del PTR debería resolverse hacia adelante a la misma IP.
• El nombre HELO/EHLO de tu MTA debería ser ese hostname (o al menos un alias sensato que resuelva correctamente).

Cuarto: confirma que SPF/DKIM/DMARC no te están socavando

• Los problemas de PTR suelen ir acompañados de un SPF “~all” de compromiso y DKIM que solo funciona los martes.
• No arregles una señal e ignores las demás.

Quinto: revisa señales básicas de listas negras/reputación

• Si estás en una IP sucia, un PTR correcto no limpiará tu reputación.
• Si estás en una IP nueva, haz warm-up; no “optimices” enviando a todo el volumen de golpe.

Broma corta #2: La entregabilidad del correo es como la plomería: el problema rara vez está en la llave elegante, y casi siempre en la tubería que no miraste.

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

Estas son tareas reales de operador. Cada una incluye un comando, un ejemplo de salida plausible, qué significa y qué decisión tomar. Sustituye IPs/dominios por los tuyos. Usa una máquina que tenga resolución DNS recursiva funcionando (o apunta las herramientas a un resolutor conocido explícitamente).

Task 1: Determine what IP your server uses to reach the internet

cr0x@server:~$ ip route get 8.8.8.8
8.8.8.8 via 203.0.113.1 dev eth0 src 203.0.113.10 uid 1000
    cache

Meaning: Your outbound traffic (and likely SMTP egress) uses source IP 203.0.113.10.

Decision: This IP is the one that must have correct PTR. If you expected a different IP, hunt down NAT rules, cloud egress, or load balancer SNAT.

Task 2: Find the public egress IP from outside your network

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

Meaning: External services see your egress as 203.0.113.10.

Decision: If this differs from what you think your SMTP server binds to, you may be behind NAT. rDNS must be set on the NAT public IP, not your private address.

Task 3: Check PTR (reverse DNS) with dig

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

Meaning: The IP has a PTR pointing to mail01.example.com.

Decision: Good start. Next verify that name resolves forward back to the same IP (FCrDNS).

Task 4: Detect missing PTR

cr0x@server:~$ dig -x 203.0.113.11
; <<>> DiG 9.18.24-1-Debian <<>> -x 203.0.113.11
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1196
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Meaning: No reverse record exists for that IP.

Decision: Fix rDNS at the IP provider (cloud/ISP). Do not keep “testing deliverability” until it’s set—your results will be noisy and mostly bad.

Task 5: Verify forward DNS of the PTR hostname

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

Meaning: Forward DNS matches the connecting IP.

Decision: This is FCrDNS passing (at least for IPv4). If you see a different IP, fix the A record, fix NAT expectations, or change PTR to the correct hostname.

Task 6: Verify AAAA too (if you have IPv6)

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

Meaning: The hostname also has IPv6.

Decision: If your SMTP listens on IPv6, you must also set IPv6 PTR and ensure IPv6 forward-reverse coherence. If you’re not ready for that, don’t publish AAAA for the mail hostname.

Task 7: Check IPv6 PTR

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

Meaning: IPv6 reverse mapping exists and matches.

Decision: Good. If it’s missing, expect some receivers to treat your IPv6 delivery as suspicious or fail entirely; either set it or disable IPv6 SMTP until you can.

Task 8: Inspect what your MTA uses for HELO/EHLO

cr0x@server:~$ postconf -n | egrep '^(myhostname|mydomain|smtp_helo_name)='
mydomain = example.com
myhostname = mail01.example.com
smtp_helo_name = $myhostname

Meaning: Postfix will greet as mail01.example.com.

Decision: Keep it consistent: HELO/EHLO should be a real FQDN with A/AAAA, ideally matching PTR. If you see localhost or a random internal name, fix it.

Task 9: See your SMTP greeting 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

Meaning: The banner shows a sane hostname.

Decision: If the banner shows localhost or an internal host, fix MTA config. Some filters treat mismatched banners as suspicious.

Task 10: Confirm TLS certificate name matches the mail hostname (optional but common)

cr0x@server:~$ openssl s_client -starttls smtp -connect mail01.example.com:25 -servername mail01.example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer
subject=CN = mail01.example.com
issuer=CN = R3, O = Let's Encrypt, C = US

Meaning: TLS identity matches mail01.example.com.

Decision: Not required for rDNS, but this is part of the “coherent sender” picture. If it doesn’t match, fix it; you want fewer reasons for receivers to distrust you.

Task 11: Check SPF for the domain you send as

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

Meaning: SPF explicitly authorizes the IP and is strict.

Decision: If SPF is missing or doesn’t include your egress IP, fix SPF. A perfect PTR won’t compensate for SPF fail at many receivers.

Task 12: Check DKIM selector presence (DNS side)

cr0x@server:~$ dig +short TXT default._domainkey.example.com | head -n 1
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Meaning: DKIM public key exists for selector default.

Decision: Ensure your MTA signs outbound mail with this selector and that mail headers show DKIM=pass at recipients. If DKIM isn’t in place, rDNS fixes will only partially help.

Task 13: Check DMARC policy

cr0x@server:~$ dig +short TXT _dmarc.example.com | sed 's/"//g'
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s

Meaning: DMARC exists with quarantine policy and strict alignment.

Decision: If DMARC is absent, deliverability may vary; if DMARC is strict but your From: domain doesn’t align with DKIM/SPF, you’ll sabotage yourself. Fix alignment before tightening policy.

Task 14: Inspect reverse DNS delegation / authority (who can set PTR)

cr0x@server:~$ dig +noall +authority -x 203.0.113.10
10.113.0.203.in-addr.arpa.  3600 IN SOA ns1.provider.net. hostmaster.provider.net. 2026010301 7200 3600 1209600 3600

Meaning: The provider’s nameserver is authoritative for the reverse zone.

Decision: You must set PTR through that provider’s control panel/API or request it via support. Changing your domain DNS provider won’t help.

Task 15: Confirm the PTR you set is visible globally (not just cached locally)

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

Meaning: A public resolver sees the correct PTR.

Decision: If public resolvers disagree, you’re racing propagation or split-horizon DNS. Receivers use their own resolvers; trust what public resolvers see.

Task 16: Check for multiple PTRs (usually a bad idea)

cr0x@server:~$ dig -x 203.0.113.10 +noall +answer
10.113.0.203.in-addr.arpa. 300 IN PTR mail01.example.com.
10.113.0.203.in-addr.arpa. 300 IN PTR mail-gateway.example.com.

Meaning: Two PTRs exist for one IP.

Decision: Pick one canonical PTR. Multiple PTRs confuse heuristics and humans. Mail wants one identity per sending IP.

Task 17: Watch SMTP transactions and see rejections tied to rDNS

cr0x@server:~$ sudo tail -n 50 /var/log/mail.log | egrep -i 'reject|rbl|helo|ptr|reverse'
Jan 03 09:14:22 mail01 postfix/smtp[12044]: host mx.remote.example[198.51.100.25] said: 550 5.7.1 Client host rejected: cannot find your reverse hostname (in reply to RCPT TO command)

Meaning: A recipient explicitly rejected due to missing reverse hostname.

Decision: Fix PTR immediately. If PTR is set, verify propagation and that the connecting IP matches the one you fixed.

Task 18: Validate your MTA binds to the intended interface/IP

cr0x@server:~$ sudo ss -ltnp | egrep ':25\s'
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=912,fd=13))

Meaning: SMTP listens on all IPv4 interfaces.

Decision: If you have multiple public IPs and only one has correct PTR, consider binding explicitly or routing outbound mail through the correct source IP.

Task 19: Confirm outbound source IP for SMTP specifically (packet-level)

cr0x@server:~$ sudo tcpdump -ni eth0 tcp port 25 and host 198.51.100.25 -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:15:01.102938 IP 203.0.113.10.48214 > 198.51.100.25.25: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 111 ecr 0,nop,wscale 7], length 0

Meaning: The SMTP connection originates from 203.0.113.10.

Decision: This is the IP whose rDNS must be correct. If you see a different source IP than expected, fix routing/NAT or MTA’s source address configuration.

Task 20: Test reverse + forward in one shot (FCrDNS quick check)

cr0x@server:~$ ip=203.0.113.10; host $ip; hn=$(host $ip | awk '/domain name pointer/{print $5}'); host ${hn%.}
10.113.0.203.in-addr.arpa domain name pointer mail01.example.com.
mail01.example.com has address 203.0.113.10

Meaning: PTR returns mail01.example.com, and that name returns the same IP.

Decision: FCrDNS passes. If the second lookup returns a different IP, you have mismatch—fix either PTR or A record so they agree.

Tres microhistorias corporativas desde el terreno

1) El incidente causado por una suposición errónea: “La nube seguro configura rDNS”

Una empresa mediana migró desde un servicio de correo gestionado a “SMTP saliente autohospedado para ahorrar costes”. El plan se veía bien en la hoja de cálculo: un par de VMs, Postfix, un relay para redundancia y un nuevo rango de IPs dedicadas del proveedor cloud. Mantuvieron SPF y DKIM en gran medida. Incluso tenían monitorización de profundidad de cola y latencia.

Entonces empezaron los rebotes. No un apagón dramático—peor. Algunos clientes recibían correo. Otros no. Saltaron tickets de soporte extraños: “El restablecimiento de contraseña no llega”, “Correo de factura ausente”, “Su sistema es inestable”. El equipo revisó los sospechosos habituales: límites de tasa, filtros de contenido, ajustes TLS y si estaban enviando desde el dominio equivocado por accidente. Estaban orgullosos de su automatización, así que naturalmente sospecharon de todos los demás.

La suposición errónea fue simple: “Si la VM tiene una IP, rDNS estará allí”. No lo estaba. Su bloque de IPs tenía PTRs apuntando a hostnames genéricos del proveedor. El MTA saludaba como mail.example.com, SPF autorizaba las IPs, pero la identidad inversa parecía un host desechable en un pool de computación.

La corrección fue anticlimática: solicitar PTRs personalizados al proveedor, hacerlos coincidir con el hostname del MTA, asegurar que el A forward coincidiera y esperar a que caduquen las cachés. El informe post-mortem fue más interesante que la reparación. Añadieron un elemento a la checklist previa al despliegue: “PTR configurado y verificado externamente para todas las IPs salientes.” No fue un avance técnico; fue madurez organizacional disfrazada de aburrimiento.

2) La optimización que salió mal: “Roteemos IPs de salida para dispersar riesgo”

Otra compañía tuvo problemas de entregabilidad y decidió intentar burlar los sistemas de reputación. La idea: rotar IPs salientes a través de un pool para que ninguna IP “acumule reputación negativa”. Alguien lo llamó incluso “sharding de entregabilidad”. Esa frase debería haber sido una alarma.

Construyeron una capa NAT ingeniosa que mapeaba las conexiones SMTP salientes a varias IPs públicas. El pool incluía IPs nuevas y un par que habían estado inactivas meses. Sus instancias Postfix no vinculaban una IP de origen específica; la red hacía el balanceo. A los ingenieros les encanta una abstracción limpia, y NAT es la mentira más limpia que nos contamos.

Lo que pasó a continuación fue predecible si alguna vez has tratado con correo: los receptores vieron señales de identidad inconsistentes. Una conexión venía de una IP con PTR mail01.example.com. Otra venía de una IP sin PTR. Otra tenía un PTR apuntando a un hostname desmantelado que ya no tenía un A forward. HELO era estable, la IP de origen no. Los filtros de spam no necesitaron un doctorado: vieron inestabilidad y la trataron como riesgo.

La entregabilidad empeoró. Además, el debugging se volvió más difícil porque los rebotes referenciaban distintas IPs según qué mapeo NAT ganara ese día. La “optimización” dispersó su reputación y aseguró que ninguna IP tuviera historia consistente. Revirtieron, fijaron el egress SMTP a una IP calentada y con rDNS correcto y solo entonces introdujeron una segunda IP—configurada correctamente—después de que la primera se estabilizara.

La lección no fue “nunca uses múltiples IPs”. La lección fue: si no puedes mantener coherencia de identidad en el pool (PTR, DNS forward, HELO, SPF), no construyas el pool. El correo castiga la astucia.

3) La práctica aburrida pero correcta que salvó el día: “Trata PTR como una dependencia de producción”

Una empresa más grande tenía un ritual casi cómicamente procedimental. Cada vez que se asignaba una nueva IP saliente—cloud, colo, recuperación ante desastres, da igual—había un pequeño ticket de “identidad de correo” que debía cerrarse antes de que la IP pudiera usarse. El ticket no era opcional. Tenía una checklist: PTR solicitado, A/AAAA forward creados, HELO configurado, SPF actualizado y una validación externa desde una máquina que no estuviera en el DNS corporativo.

Durante un corte regional, cambiaron el correo saliente a un sitio secundario. Sus MTAs se levantaron, las colas se vaciaron y los clientes apenas notaron. ¿Por qué? Porque las IPs secundarias ya tenían PTRs correctos y forward DNS meses antes, aunque el sitio permaneciera mayormente inactivo. Nada se “descubrió” durante el incidente. El trabajo aburrido fue prepagado.

Aún quedó trabajo por hacer—calentar volumen, vigilar cambios de reputación, ajustar límites de tasa—pero evitaron el peor escenario: un failover que técnicamente funciona mientras que cada proveedor principal te hunde en spam. Ese es el tipo de outage que no aparece en los gráficos de CPU y destruye la confianza de todos modos.

No es ingeniería heroica. Es simplemente negarse a ejecutar correo con identidad medio-configurada. El mantra del equipo era básicamente: si no desplegarías sin TLS, no despliegues sin PTR.

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

Estos son los patrones que veo repetidamente en entornos de producción. Cada uno tiene un síntoma específico, una causa probable y una solución que no involucra deseos.

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

Causa raíz: No hay registro PTR para la IP que se conecta, o el reverse DNS está roto por una mala configuración del proveedor.

Solución: Configura PTR en el proveedor de la IP. Verifica con dig -x desde un resolutor público. Asegúrate de que tu SMTP realmente sale desde esa IP.

2) Síntoma: El correo llega a spam en Microsoft/Google pero no en todas partes

Causa raíz: El PTR existe pero es genérico, no coincide o no se resuelve hacia adelante (FCrDNS falla). Suele combinarse con reputación nueva/baja.

Solución: Haz que el PTR apunte a un hostname que controles; asegura que el A/AAAA de ese hostname apunte de vuelta a la misma IP. Mantén HELO consistente. Calienta la IP gradualmente.

3) Síntoma: Los rebotes referencian una IP que no reconoces

Causa raíz: NAT, relay saliente, balanceador o servidor multihomed usa una IP de egress distinta a la esperada.

Solución: Confirma el egress con captura de paquetes o comprobaciones de ruta. Vincula el MTA a una IP de origen específica si es necesario. Configura PTR para la IP real de egress.

4) Síntoma: PTR apunta a un hostname, pero la búsqueda forward da otra IP

Causa raíz: Alguien cambió el registro A durante una migración, o el PTR fue copiado de infraestructura antigua. FCrDNS falla.

Solución: Decide cuál es canónico (normalmente el hostname real del mail para esa IP), y actualiza PTR y A/AAAA para que coincidan. Una IP enviadora, una identidad.

5) Síntoma: PTR apunta a localhost o a un nombre interno en los logs

Causa raíz: myhostname del MTA o HELO está mal configurado; la identidad del banner no coincide con la realidad.

Solución: Pon al MTA un hostname FQDN real con DNS forward correcto. Asegúrate de que HELO lo use. No saludes como nombres internos.

6) Síntoma: El correo IPv4 está bien; el IPv6 falla más a menudo

Causa raíz: Existe registro AAAA; SMTP ofrece IPv6; pero falta o está mal el PTR IPv6. O la dirección IPv6 pertenece a un pool con mala reputación.

Solución: O configura correctamente rDNS IPv6 y FCrDNS, o deja de anunciar IPv6 para SMTP hasta poder hacerlo bien.

7) Síntoma: “Configuré PTR”, pero algunos receptores aún dicen que falta

Causa raíz: Propagación/caché, o configuraste PTR para la IP equivocada (común con NAT), o probaste contra tu resolutor interno que miente.

Solución: Consulta resolutores públicos directamente. Confirma la IP conectante desde logs. Espera a que expiren los TTL, pero no confundas esperar con arreglar.

8) Síntoma: La entregabilidad cae tras mover a un nuevo proveedor

Causa raíz: PTR reseteado al default del proveedor; SPF no actualizado; HELO en conflicto; reputación de IP en frío.

Solución: Trata las migraciones como migraciones de identidad. Pre-provisiona PTR y registros forward. Calienta las nuevas IPs. Mantén el remitente antiguo en funcionamiento durante la transición si es posible.

Listas de verificación / plan paso a paso

Paso a paso: arregla el PTR faltante de forma segura

1. Identifica la(s) IP(s) reales de envío. Usa rebotes, logs SMTP o captura de paquetes. No adivines.
2. Elige un hostname canónico de correo por cada IP de envío. Ejemplo: mail01.example.com para 203.0.113.10. Mantenlo estable.
3. Crea el DNS forward primero. Añade A (y AAAA si aplica) para el hostname apuntando a la IP de envío.
4. Solicita/configura el PTR en el proveedor. Apúntalo al hostname canónico. Evita múltiples PTRs.
5. Verifica FCrDNS. PTR resuelve a hostname; hostname resuelve de vuelta a la IP.
6. Alinea HELO/EHLO. Configura tu MTA para saludar como el hostname canónico.
7. Confirma que SPF incluya la(s) IP(s) de envío. Usa una política estricta si puedes sostenerla.
8. Confirma que DKIM firma de extremo a extremo. Verifica con los headers en destinatarios.
9. Revisa la alineación DMARC. Especialmente si aplicas quarantine/reject.
10. Monitorea colas y rebotes durante 48–72 horas. Espera algo de lag por caches. Correlaciona por dominio destinatario.
11. Documenta la frontera de propiedad. Quién puede cambiar PTR (proveedor), quién puede cambiar DNS forward (tú) y el SLA.

Checklist operacional: antes de poner una nueva IP saliente en servicio

• PTR configurado y verificado desde al menos dos resolutores públicos.
• A/AAAA del hostname PTR existe y coincide con la IP.
• Nombre HELO del MTA es ese hostname; el banner coincide.
• SPF actualizado para los dominios emisores.
• Selector DKIM publicado; firma habilitada; mail de prueba muestra DKIM=pass.
• DMARC presente y alineado con tu estrategia de autenticación.
• IPv6 o bien totalmente configurado (incluido rDNS) o intencionadamente deshabilitado para SMTP.
• Límites de tasa salientes establecidos; plan de warm-up para IPs nuevas.
• Logging en lugar para mapear message-id → dominio destinatario → IP de envío.

Qué evitar cuando te tienta “hacer que funcione rápido”

• No uses una IP dinámica/residencial para correo saliente.
• No rotees IPs de origen sin rDNS consistente y reputación calentada.
• No pongas PTR a un hostname que no exista en forward DNS.
• No saludes como localhost, un hostname interno o un nombre sin registro A/AAAA.
• No publiques AAAA para tu hostname de correo si no puedes poner PTR IPv6.
• No asumas que tus pruebas DNS reflejan lo que ven los receptores externos; prueba con resolutores públicos.

Preguntas frecuentes

1) ¿Necesito absolutamente un registro PTR para enviar correo?

Técnicamente puedes enviar SMTP sin él, pero muchos receptores te penalizan o te rechazan. En la práctica, la falta de PTR es un daño a la entregabilidad autoinfligido.

2) ¿Quién controla el registro PTR—mi proveedor DNS o mi ISP/cloud?

El propietario de la IP controla el reverse DNS. Eso suele ser tu ISP o proveedor cloud. Tu proveedor DNS autoritativo normal controla los registros forward (A/AAAA), no el PTR.

3) ¿Debe PTR coincidir con el dominio From:?

No estrictamente. PTR debe coincidir con la identidad de la infraestructura de envío (el hostname del servidor). Si gestionas tu propio dominio, es más limpio cuando el hostname PTR está bajo tu dominio, pero no tiene que coincidir exactamente con el From:.

4) ¿Qué es FCrDNS y es obligatorio?

FCrDNS significa PTR → hostname → A/AAAA → misma IP. No es un requisito de protocolo, pero es una comprobación de coherencia ampliamente usada. Pasarla reduce la sospecha.

5) ¿Puede una IP tener múltiples PTRs?

Pue-de, pero generalmente no deberías hacerlo. Para correo, una IP enviadora debe presentar una identidad estable. Múltiples PTRs crean ambigüedad y pueden perjudicar heurísticas.

6) Si arreglo PTR, ¿mi entregabilidad se recuperará al instante?

A veces verás mejora inmediata en rechazos duros. La colocación en spam puede tardar más porque los sistemas de reputación tienen memoria. Arreglar PTR detiene la hemorragia; no borra la historia.

7) ¿Y el IPv6—también necesito PTR allí?

Si entregas correo por IPv6, sí. Algunos receptores son más estrictos con IPv6 porque es más fácil para remitentes abusivos obtener gran espacio de direcciones. Si no puedes hacer rDNS IPv6 correctamente, no anuncies IPv6 para SMTP.

8) Mi proveedor solo permite PTR como ip-203-0-113-10.provider.net. ¿Está bien?

Es mejor que no tener PTR, pero no es ideal. Si no puedes establecer un PTR significativo y te importa la entregabilidad, considera un proveedor que soporte rDNS personalizado o usa un relay SMTP reputado con opciones de IP dedicada.

9) ¿PTR reemplaza a SPF/DKIM/DMARC?

No. PTR es una señal de infraestructura débil. SPF/DKIM/DMARC son señales de autenticación y política. El filtrado moderno usa todas ellas, además de reputación y contenido.

10) ¿Qué hostname debería usar para PTR?

Usa un hostname estable y dedicado para correo saliente: mail01.example.com o smtp-out.example.com. Asegúrate de que tenga A/AAAA coincidentes y de que tu MTA lo use en HELO.

Siguientes pasos que puedes hacer hoy

1. Encuentra tu IP real de egress SMTP. No confíes en diagramas; confía en capturas de paquetes y rebotes.
2. Realiza tres búsquedas: dig -x <ip>, dig A <ptr-name> y (si aplica) dig AAAA <ptr-name>. Haz que concuerden.
3. Arregla el hostname HELO/banner de tu MTA para que sea un FQDN real resolvible que coincida con la identidad PTR.
4. Verifica externamente usando resolutores públicos para evitar que te engañe un DNS interno.
5. Luego ataca la alineación SPF/DKIM/DMARC y el warm-up de IP. rDNS te pasa la puerta de “¿eres serio?”; la autenticación te mete al edificio.

Si tus problemas de entregabilidad se sienten misteriosos, empieza por hacer la identidad de tu infraestructura aburrida y consistente. El correo recompensa lo aburrido. Castiga lo ingenioso.