DNS inverso (PTR) para correo: qué es y cómo revisarlo

Un registro PTR (puntero) es lo contrario de un registro A: asocia una dirección IP con un nombre de host. En el correo, la IP que envía tus mensajes necesita un registro PTR, y el nombre de host que indica debe resolver de vuelta a esa misma IP. Este viaje de ida y vuelta se llama DNS inverso confirmado hacia adelante (forward-confirmed reverse DNS), y Gmail y Yahoo lo exigen. Sin él, el correo se aplaza, se rechaza o se filtra.

Los registros PTR no se configuran en el DNS de tu propio dominio, y la mayoría de los remitentes nunca necesita tocar uno. Esta guía explica cómo revisarlo, qué exigen los grandes proveedores de correo y quién puede cambiar el registro cuando está mal.

Cómo funciona el DNS inverso

Un registro PTR vive en una zona inversa especial, cuyo nombre es la dirección IP escrita al revés. En IPv4 se invierten los cuatro octetos y se agrega in-addr.arpa. El PTR de 209.85.220.41 se guarda en 41.220.85.209.in-addr.arpa. IPv6 usa ip6.arpa e invierte cada dígito hexadecimal.

Por ese formato de nombre no puedes agregar un PTR en el panel DNS de tu dominio. La zona inversa pertenece a quien recibió la asignación del bloque de IPs, y es quien la delega o la administra.

Una sola consulta PTR prueba poco, porque cualquiera que controle una zona inversa puede apuntarla a cualquier nombre, incluido el tuyo. La comprobación que les importa a los receptores va en ambos sentidos:

1. Inversa: consulta el PTR de la IP que se conecta. Obtienes un nombre de host.
2. Directa: consulta el registro A (o AAAA) de ese nombre de host. Debe incluir la IP original.

Si ambas coinciden, la IP tiene DNS inverso confirmado hacia adelante (que suele escribirse FCrDNS). Esto es anterior a cualquier regla para remitentes masivos. El RFC 1912, una guía informativa de 1996 sobre errores comunes de DNS, ya decía: "Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain." (Asegúrate de que tus registros PTR y A coincidan. Para cada dirección IP debe haber un registro PTR correspondiente en el dominio in-addr.arpa.)

Cómo revisar el tuyo con dig

Ejecuta dig -x sobre la IP de envío y luego consulta el nombre de host que devuelve. Esto es lo que obtuvimos el 7 de octubre de 2026 (UTC) con algunas IPs de envío conocidas:

$ dig -x 209.85.220.41 +short
mail-sor-f41.google.com.
$ dig +short A mail-sor-f41.google.com
209.85.220.41

IP de envío	PTR	Registro A de ese nombre	¿Confirmado hacia adelante?
209.85.220.41 (Google)	mail-sor-f41.google.com	209.85.220.41	Sí
54.240.8.1 (Amazon SES)	a8-1.smtp-out.amazonses.com	54.240.8.1	Sí
198.2.128.1 (Mandrill)	mail128-1.atl41.mandrillapp.com	198.2.128.1	Sí
La IP de banda ancha de nuestra oficina	ninguno	n/a	No

El patrón es constante: todos los servicios de envío conocidos publican un par que coincide, y la conexión residencial no publica nada.

Para encontrar la IP que realmente envió un mensaje, abre los encabezados completos de un mensaje que recibiste y lee la línea Received: superior que agregó tu propio proveedor. Nuestra guía para leer encabezados de correo muestra en qué línea confiar. Si prefieres no usar la línea de comandos, Admin Toolbox Dig de Google tiene una consulta PTR.

Qué exigen Gmail y Yahoo

Ambos proveedores incluyen un DNS directo e inverso válido como requisito para todos los remitentes, no solo para los masivos.

Las Email sender guidelines (pautas para remitentes) de Google dicen: "The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname." (La dirección IP pública de un servidor SMTP de envío debe tener un registro PTR correspondiente que resuelva a un nombre de host.) Y continúan: "The same hostname must also have an A (for IPv4) or AAAA (for IPv6) record that resolves to the same public IP address used by the sending server." (Ese mismo nombre de host también debe tener un registro A, para IPv4, o AAAA, para IPv6, que resuelva a la misma IP pública que usa el servidor de envío.) Las preguntas frecuentes de Google asocian los fallos con códigos concretos, 4.7.23 y 5.7.25, que la comparación de requisitos de Gmail y Yahoo enumera junto con los demás códigos de aplicación.

Los Sender Requirements (requisitos para remitentes) de Yahoo piden "Have a valid forward and reverse DNS record for your sending IPs" (tener un registro DNS directo e inverso válido para tus IPs de envío) y van más allá sobre cómo debe verse el nombre: "Publish valid, meaningful, non-generic reverse DNS (PTR) records for all of your sending IPs" (publica registros de DNS inverso, PTR, válidos, con significado y no genéricos para todas tus IPs de envío), "Reverse DNS should reflect your domain name in some way" (el DNS inverso debe reflejar tu nombre de dominio de alguna forma) y "Do not use a reverse DNS that looks like a dynamically-assigned IP instead of a static mail server" (no uses un DNS inverso que parezca una IP asignada dinámicamente en lugar de un servidor de correo estático).

Cómo se ve un fallo

Yahoo rechazó nuestra conexión de prueba en el primer comando del sobre porque la IP no tenía DNS inverso confirmado hacia adelante. El 7 de octubre de 2026 abrimos una sesión SMTP con el servidor de entrada de Yahoo desde una conexión de banda ancha de oficina sin registro PTR, sin enviar ningún mensaje. El servidor nos saludó con normalidad y luego respondió a MAIL FROM con:

550 5.7.25 Forward-confirmed reverse DNS failed

Cerró la conexión antes de que pudiéramos indicar un destinatario. La página pública de códigos de error de Yahoo no incluye este texto, así que toma esa línea como lo que observamos y no como un comportamiento documentado. Coincide con el requisito escrito de Yahoo y usa el mismo código ampliado 5.7.25 que Google asocia con los fallos de PTR.

Spamhaus también lo trata como una señal de reputación. Su página de la lista de bloqueo CSS les pide a los remitentes listados que primero "check all technical settings for correctness" (revisen que toda la configuración técnica sea correcta), y dice "SMTP servers should be configured with correct forward and reverse DNS and HELO/EHLO values" (los servidores SMTP deben configurarse con valores correctos de DNS directo e inverso y de HELO/EHLO). Consulta cómo funciona la salida de una lista de bloqueo si ya te listaron.

¿El PTR tiene que coincidir con el nombre de EHLO?

Debería, pero el estándar no permite que un servidor rechace correo solo por esa diferencia. El RFC 5321, sección 4.1.4, dice que un cliente SMTP debe, si es posible, dar su nombre de host principal en EHLO. Luego dice que un servidor "MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis." (PUEDE verificar que el nombre de dominio del comando EHLO corresponda realmente a la dirección IP del cliente. Sin embargo, si la verificación falla, el servidor NO DEBE negarse a aceptar un mensaje por ese motivo.)

En la práctica, los receptores usan juntos el nombre de EHLO, el PTR y la consulta directa como señales de reputación, y los requisitos de los proveedores de arriba se refieren al PTR en sí. La configuración más simple evita la pregunta: un solo nombre de host, como mail.example.com, que es el PTR de la IP, tiene un registro A que apunta a la IP y es el nombre que el servidor anuncia en EHLO.

Quién puede cambiar tu registro PTR

Quien es dueño de la IP de envío controla su PTR, así que la solución depende de cómo envías.

Cómo envías	Quién es dueño de la IP	Qué haces
Google Workspace, Microsoft 365, Outlook.com, Gmail	El proveedor de correo	Nada. Sus IPs ya tienen FCrDNS
Un ESP con IP compartida (Mailchimp, SendGrid, pool compartido de SES)	El ESP	Nada. El PTR nombra al ESP, y eso es lo esperado
Un ESP con IP dedicada	El ESP	Algunos ESP te dejan poner un nombre de host con tu marca; sigue sus pasos de configuración
Tu propio servidor en un proveedor de nube o VPS	El proveedor	Configura el DNS inverso en su panel de control o pídeselo a soporte
Tu propio servidor en banda ancha empresarial	El ISP	Pídeselo al ISP; muchos no lo hacen en rangos dinámicos o residenciales

Algunas IPs dedicadas de SendGrid, por ejemplo, tienen registros PTR que nombran el dominio del propio cliente en lugar del de SendGrid, que es cómo se ve en la práctica el "reflect your domain name in some way" de Yahoo.

En un VPS, primero configura el registro A del nombre de host que elegiste y luego pon el PTR con ese nombre en el panel del proveedor. Algunos proveedores no aceptan un PTR cuyo nombre no resuelva ya a la IP. Ten en cuenta que muchos proveedores de nube bloquean por defecto el puerto 25 de salida, así que un PTR correcto no significa que puedas enviar; consulta qué proveedores de nube bloquean el puerto 25.

Errores comunes con el PTR

La mayoría de los fallos de DNS inverso vienen de una de cinco configuraciones.

• Ningún PTR. Típico de conexiones residenciales y de muchas pequeñas empresas. No envíes directo al MX desde ellas; retransmite a través de tu proveedor o de un ESP.
• Un PTR genérico. Nombres como 203-0-113-25.static.isp.example resuelven, pero se ven exactamente como lo que Yahoo llama "a dynamically-assigned IP" (una IP asignada dinámicamente). Pide un nombre dentro de tu propio dominio.
• Un PTR que no resuelve hacia adelante. El PTR dice mail.example.com, pero ese nombre no tiene registro A, o apunta a otro lado después de una migración.
• Un PTR que apunta a un CNAME. El RFC 1912 dice "PTR records must point back to a valid A record, not a alias defined by a CNAME." (Los registros PTR deben apuntar a un registro A válido, no a un alias definido con un CNAME.)
• Solo la primera IP tiene nombre. Si el servidor envía desde varias IPs, o desde IPv6 además de IPv4, cada dirección necesita su propio par que coincida. El RFC 1912 dice lo mismo para los hosts con varias interfaces.

En resumen

1. Un PTR asocia tu IP de envío con un nombre de host; ese nombre de host debe resolver de vuelta a la misma IP.
2. Gmail y Yahoo lo exigen a todos los remitentes. Yahoo además quiere un nombre no genérico que refleje tu dominio.
3. Revísalo con dig -x <ip> +short y luego con dig +short A <hostname>.
4. Lo cambias a través de quien es dueño de la IP, no en el DNS de tu dominio.
5. Si envías con Google, Microsoft o un ESP, esto ya está resuelto. Dedica ese tiempo a SPF, DKIM y DMARC, que puedes revisar con la auditoría de entregabilidad.