Defaults.Exposed › Soluciones › DNS inverso (PTR)

Cómo arreglar DNS inverso (PTR)

El DNS inverso es la credencial del servidor que envía el correo de tu empresa. Cuando un proveedor receptor como Gmail o Microsoft 365 consulta quién hay detrás de la dirección emisora y obtiene un nombre que cuadra, tu correo parece legítimo. Cuando no hay credencial —o el nombre y el número no concuerdan—, tus facturas y presupuestos perfectamente reales se tratan como sospechosos y se mandan en silencio a la basura o se rechazan.

En resumen, para tu negocio: Tus facturas, presupuestos y respuestas a clientes caen en silencio en el spam o nunca llegan, así que los acuerdos se atascan, los pagos llegan tarde y los clientes creen que los ignoraste, nada de lo cual aparece como un error que notarías.

Lo que esto te puede costar

• Envías un presupuesto a un cliente prometedor, cae en su spam, y se va con el competidor que «sí respondió», y tú nunca llegaste a saber que el correo no aterrizó.
• Las facturas a clientes se desvanecen en la basura, los pagos llegan semanas tarde, y tu flujo de caja sufre el golpe porque nadie llegó a ver el correo.
• Un cliente se queja de que nunca le respondiste, pero sí lo hiciste; su proveedor de correo tiró tu respuesta en silencio porque tu servidor emisor no pudo demostrar quién era.
• Tu dominio supera la revisión de seguridad de un nuevo cliente en todo lo demás, y luego lo señalan porque tu servidor de correo no tiene una identidad adecuada: una pequeñez que te hace parecer descuidado.
• Te mudaste a un VPS barato o a una nueva aplicación para enviar tus boletines y facturas, y de la noche a la mañana tu tasa de entrega cae, porque ese nuevo servidor emisor no tiene credencial de DNS inverso y los grandes proveedores ya no confían en él.

Por qué importa. Todo proveedor de correo importante comprueba la identidad del servidor que envía tu correo, y la comprueba en cada mensaje. Si ese servidor no puede demostrar quién es —o si su nombre y su número se contradicen—, tu correo empresarial legítimo se gestiona como si pudiera ser spam. Pierdes respuestas, pagos y confianza, y como nada rebota, normalmente nunca averiguas por qué.

La versión corta

Cuando tu empresa envía un correo, este sale de un servidor de correo, y todo servidor de internet tiene una dirección numérica: su IP. El DNS inverso (un registro «PTR») es la credencial de ese servidor: permite a cualquiera que vea el número buscar el nombre adecuado que hay detrás, como mail.tuempresa.com.

Los grandes proveedores receptores —Gmail, Microsoft 365, Yahoo— comprueban esa credencial en cada mensaje que envías. Un servidor capaz de nombrarse a sí mismo, y donde el nombre y el número concuerdan entre sí, parece un servidor de correo legítimo. Un servidor sin credencial, o con una credencial que no coincide, se parece exactamente a las máquinas anónimas y desechables que usan los spammers. Así que tus facturas y presupuestos legítimos empiezan cada conversación bajo sospecha, y muchos de ellos pierden.

Lo frustrante es que nada te avisa de que está pasando. No hay rebote, no hay error. Tu correo simplemente rinde por debajo en silencio.

Lo que esto te puede costar

Estas son las formas cotidianas en que un registro de DNS inverso ausente o no coincidente se traduce en dinero y confianza que se van por la puerta. Nunca nombramos a una empresa real: son patrones que vemos en los datos.

• El presupuesto que nunca aterrizó. Envías por correo un presupuesto detallado a un cliente potencial que lo pidió esa misma mañana. Su proveedor no puede verificar tu servidor emisor, así que tira el mensaje al spam. No bucean en la basura. Por la tarde han aceptado el presupuesto del competidor, el que «sí apareció». Lo achacas a un contacto flojo; en realidad tu correo nunca se vio.
• La factura en el vacío. Facturas a un buen cliente. Aterriza en su carpeta de basura. Treinta días después estás persiguiendo un pago vencido sin que sea culpa suya, y ahora hay una conversación incómoda, una relación tensa y un hueco de tesorería que era totalmente evitable.
• «Nunca respondiste.» Un cliente está molesto porque ignoraste su pregunta. No lo hiciste: respondiste el mismo día. Su proveedor de correo tiró tu respuesta en silencio porque tu servidor emisor parecía poco fiable. Quedas poco profesional por algo que en realidad hiciste bien.
• El servidor casero que lo envenenó todo en silencio. Para ahorrar dinero, tu correo (o solo tus boletines y facturas automáticas) empezó a salir a través de un VPS barato o una nueva aplicación de envío. Ese servidor nunca obtuvo una credencial de DNS inverso. De la noche a la mañana, tu tasa de entrega se hundió en general, y como no hay mensaje de error, llevó meses siquiera sospechar la causa.
• La bandera en la revisión de seguridad. El equipo de informática de un cliente mayor hace una comprobación rutinaria de tu dominio durante la incorporación. Todo lo demás está bien, pero tu servidor de correo no tiene una identidad adecuada. Es un punto técnico menor, pero se lee como descuido, y ahora lo estás arreglando bajo presión de plazos, o dándole explicaciones, cuando el dominio de un competidor acaba de pasar sin problemas.

El hilo común a todos: el coste cae sobre ti, es invisible mientras ocurre, y la solución es gratis.

Qué es en realidad

El DNS normal convierte un nombre en un número: escribes tuempresa.com, y el DNS te devuelve la dirección IP a la que conectar. El DNS inverso hace lo opuesto: convierte un número de vuelta en un nombre. Dada la IP 203.0.113.10, una búsqueda inversa (un «registro PTR») responde mail.tuempresa.com.

Por qué les importa a los receptores: cuando tu servidor de correo conecta con Gmail para entregar un mensaje, Gmail ve la IP que conecta. Lo primero que hace un filtro de correo serio es preguntar «¿quién es esta máquina?» haciendo una búsqueda inversa de esa IP. Un servidor de correo empresarial real tiene una respuesta (mail.tuempresa.com). Una máquina de spam desechable normalmente no la tiene, o tiene un nombre genérico asignado por el proveedor como host-203-0-113-10.algunisp.net. Así que la presencia y la calidad de la credencial es una de las primerísimas señales de confianza que se aplican a tu correo, antes incluso de que SPF, DKIM o el contenido del mensaje se miren siquiera.

Comprueba el servidor de correo, no tu web. Esto despista a la gente. La dirección de tu web suele estar detrás de una CDN o un proxy (como Cloudflare) y nunca tendrá una credencial coincidente, y eso está bien, porque el DNS inverso para el correo trata sobre la IP del servidor de correo MX, una máquina completamente aparte. Esta comprobación busca correctamente el servidor de correo principal de tu dominio (el registro MX de menor prioridad), lo resuelve a su IP y comprueba la credencial de esa IP.

La mitad que la mayoría de las configuraciones hacen mal: tiene que coincidir en ambos sentidos. Tener un nombre no basta por sí solo. Gmail y los demás grandes filtros hacen algo más estricto, llamado DNS inverso confirmado en sentido directo (FCrDNS):

1. Busca la IP → obtén un nombre (por ejemplo, mail.tuempresa.com).
2. Ahora busca ese nombre de vuelta → debe resolverse a la misma IP desde la que empezaste.

Si las dos direcciones concuerdan, el servidor se confirma y se confía plenamente. Si hay un nombre pero apunta a otro sitio (o a ninguna parte), el servidor solo se confía a medias: una credencial que no aguanta un segundo vistazo se trata como más débil de lo que esperarías. Un PTR que apunta a un nombre de host controlado por un atacante, y que no resuelve de vuelta, es en cierto modo peor que no tener PTR.

Así es exactamente como esta comprobación lo puntúa:

• Confirmado en sentido directo (FCrDNS): la IP nombra un host, y ese host apunta de vuelta a la misma IP. Nota máxima: es la configuración correcta, y es lo que confían los receptores.
• La credencial existe pero no confirma: hay un registro PTR, pero el nombre no resuelve de vuelta a la IP del servidor de correo. Solo crédito parcial: parece configurado pero los grandes filtros no confiarán del todo en él.
• Sin credencial alguna: no hay registro PTR en la IP del servidor de correo. Sin crédito, y el coste de entregabilidad es real.

Una nota sobre el peso: en la metodología, esta es una comprobación puntuada de seguridad de correo (vale 25 puntos, un elemento de prioridad P2). No es la comprobación de correo de más peso —esa es SPF y DMARC, que detienen la suplantación directa—, pero es una parte genuina y calificada de tu posición en correo, y de las pocas que dependen de que tu proveedor haga algo bien en lugar de tú. Si envías solo a través de Google Workspace o Microsoft 365, casi con seguridad ya pasas; las empresas que suspenden son las que envían a través de su propio servidor o el de un tercero.

Cómo se ve lo «bueno»: la IP de tu servidor de correo principal tiene un registro PTR que apunta a un nombre de host real que posees, y ese nombre de host resuelve directamente de vuelta a la misma IP: las dos direcciones concuerdan (FCrDNS confirmado).

Cómo solucionarlo (gratis, ~10 minutos del tiempo de alguien)

Pasa esta sección a quien sea dueño de la dirección IP de tu servidor de correo —normalmente tu proveedor de correo o de hosting, o tu centro de datos para una máquina autoalojada— y ten en cuenta que la solución es gratis. Este es el único ajuste de correo que casi con seguridad no puedes cambiar tú mismo en tu panel de DNS normal, porque el DNS inverso lo controla quien sea dueño de la IP, no quien sea dueño del dominio. Nosotros solo cobramos por vigilar que se mantenga correcto, nunca por hacer el cambio.

Paso 1 — Encuentra la IP del servidor de correo emisor. Identifica el host MX principal del dominio (el servidor de correo con el número de prioridad más bajo) y resuélvelo a su dirección IP:

dig MX tuempresa.com        # encuentra el host MX principal (de menor prioridad)
dig A mail.tuempresa.com    # resuelve ese host a su IP

Esa IP es la que necesita la credencial. No uses la IP de la web: es una máquina distinta y a menudo está detrás de una CDN que nunca coincidirá.

Paso 2 — Pide al dueño de la IP que configure el registro PTR. El DNS inverso reside con quien controla el bloque de IP, así que la petición va a:

• Google Workspace / Gmail: gestionado automáticamente para los propios servidores de correo de Google; si un dominio que envía solo a través de Google de algún modo aparece como suspenso, plantéaselo al soporte de Google. (En la práctica, estos pasan.)
• Microsoft 365: igualmente gestionado automáticamente para los servidores de Microsoft.
• Un servidor de correo autoalojado o en VPS: abre un tique con tu proveedor de hosting o centro de datos pidiéndoles que configuren el PTR (DNS inverso) de tu IP a tu nombre de host de correo. La mayoría de los proveedores lo exponen en su panel de control bajo «DNS inverso», «rDNS» o «PTR». En las grandes nubes es un ajuste de un solo campo (por ejemplo, AWS requiere un breve formulario de solicitud para habilitar rDNS en una IP elástica; la mayoría de los VPS te dejan configurarlo al instante).
• Una aplicación de envío de terceros (boletines / facturación / CRM): si envía desde sus propios servidores compartidos, el proveedor gestiona el DNS inverso; no hay nada que configures, y puedes ignorar esto para ese tráfico. Si envía desde una IP dedicada que les compraste, pídeles que configuren el PTR en ella.

Diles el registro que quieres, por ejemplo: 203.0.113.10 → mail.tuempresa.com.

Paso 3 — Haz que confirme en sentido directo (este es el paso que la mayoría se salta). El nombre de host del PTR también debe resolver de vuelta a la misma IP mediante un registro A normal que tú controles en tu propio DNS. Así que:

• El PTR dice 203.0.113.10 → mail.tuempresa.com (lo configura tu proveedor).
• El registro A dice mail.tuempresa.com → 203.0.113.10 (lo configuras tú en tu DNS, por ejemplo Cloudflare → DNS → añade un registro A, Nombre mail, contenido 203.0.113.10).

Ambas direcciones deben apuntarse mutuamente. Solo entonces queda confirmado en sentido directo y plenamente confiado.

Paso 4 — Vuelve a comprobar tu dominio. Confirma que el servidor de correo muestra ahora DNS inverso confirmado en sentido directo y que la comprobación pasa. Los cambios de DNS se propagan en cuestión de minutos a unas pocas horas.

Errores habituales

• Poner la credencial en la IP de la web en vez de la del servidor de correo. El DNS inverso para el correo trata sobre el servidor MX. Poner un PTR en tu dirección de web/CDN no hace nada por la entregabilidad: la credencial va a la máquina equivocada.
• Quedarse en «el PTR existe». Un nombre por sí solo solo obtiene confianza parcial. Si no resuelve de vuelta a la misma IP, los filtros estrictos (Gmail, M365, Yahoo) no confiarán del todo en él. Completa siempre la confirmación en sentido directo (Paso 3).
• Olvidar el registro A después de que el proveedor configure el PTR. El proveedor configura la mitad inversa; tú debes configurar la mitad directa en tu propio DNS. La gente hace una y da por hecho que ha terminado.
• Pedírselo a la parte equivocada. Enviar la petición a tu registrador de dominio o proveedor de DNS en lugar de al dueño de la IP te lleva a un «no podemos hacer eso», porque de verdad no pueden. Tiene que ir a quien sea dueño de la IP.
• Nombres de host genéricos del proveedor. Un PTR como host-203-0-113-10.algunisp.net técnicamente existe pero no hace nada por tu marca ni tu confianza. Usa un nombre de host real en tu propio dominio que confirme en sentido directo.

Dónde encaja esto

El DNS inverso es la identidad del servidor; SPF, DKIM y DMARC son la capa de autorización y antisuplantación del dominio. Responden a preguntas distintas, y los grandes proveedores las comprueban todas. SPF enumera qué servicios pueden enviar en tu nombre; DKIM firma criptográficamente tus mensajes para que no puedan manipularse; DMARC une los dos y le dice a los receptores qué hacer con el correo que falla, y protege el nombre visible del campo «de» que ven realmente tus clientes. El DNS inverso se sitúa por debajo de todo eso, dando fe de que la máquina que envía es, en primer lugar, un servidor de correo real y con nombre. Pon bien SPF, DKIM y DMARC para la defensa más fuerte contra la suplantación; pon bien el DNS inverso para que un servidor emisor nuevo o autoalojado no quede silenciosamente desconfiado antes de que el resto tenga siquiera una oportunidad. Cada una de estas soluciones es gratis.

Preguntas frecuentes