DNS inverso y su servidor de envío

Módulo 5: Reputación y los grandes proveedores · Tiempo de lectura: 9 minutos

Objetivo de aprendizaje: Después de esta lección podrá explicar por qué la dirección IP del servidor que envía su correo debe tener una reverse DNS correcta, determinar cuál es ese servidor en su caso y comprobar si la ida y la vuelta coinciden.

Conceptos clave: servidor de envío, registro PTR, forward-confirmed reverse DNS (FCrDNS), nombre HELO/EHLO, nombre genérico, hosting compartido, servidor propio (VPS), propietario del bloque de IP

¿Qué servidor envía realmente su correo?

En el módulo 4 se trató su dominio: SPF, DKIM y DMARC están en el DNS de example.com. En este módulo nos fijamos en otra cosa: el servidor que entrega su correo al destinatario. Ese servidor tiene una dirección IP, y los destinatarios evalúan esa dirección de forma independiente a su dominio.

Cuál es ese servidor depende de cómo envíe su correo:

La dirección IP del servidor de envío la encuentra en las cabeceras de un correo que se haya enviado a sí mismo o a otra dirección (lección 1.5). Fíjese en la línea Received: superior que añadió el servidor receptor. Allí encontrará algo como:

Received: from smtp.hosting.example (smtp.hosting.example [192.0.2.25])
        by mx.example.net with ESMTPS id 4f2a...

La dirección entre corchetes, 192.0.2.25, es la dirección IP con la que se conectó el servidor emisor. El nombre que la precede (smtp.hosting.example) es el nombre que el destinatario encontró para esa dirección mediante reverse DNS.

Reverse DNS en resumen

La reverse DNS vincula una dirección IP de vuelta con un nombre, mediante un registro PTR. Los fundamentos los aprendió en el curso de DNS (lección 4.6): el registro no está en la zona de su dominio sino en la zona inversa de la dirección IP, que pertenece a la entidad que gestiona ese bloque de IP.

Para el correo electrónico son importantes tres cosas:

1. Existe una PTR. Una dirección IP sin reverse DNS parece una máquina aleatoria de internet. Gmail rechaza ese correo con el mensaje 550 5.7.25 ... the sending IP address doesn't have a PTR record.
2. El nombre apunta de vuelta a la misma dirección. La dirección IP 192.0.2.25 tiene la PTR smtp.hosting.example, y smtp.hosting.example tiene el registro A 192.0.2.25. Esto se llama forward-confirmed reverse DNS (FCrDNS). Gmail, Yahoo y T-Online lo mencionan expresamente en sus requisitos.
3. El nombre parece el de un servidor de correo. Un nombre como 192-0-2-25.dsl.provider.example o host25.dynamic.provider.example delata una conexión doméstica o de cliente. Los filtros antispam penalizan esto, o rechazan la conexión directamente.

Para IPv6 se aplica todo de nuevo. Si un servidor envía por IPv6, la dirección IPv6 también debe tener una PTR y apuntar de vuelta con un registro AAAA. Un servidor que está correcto por IPv4 pero no por IPv6 tendrá problemas sobre todo con Gmail: Google menciona una PTR de IPv6 ausente como causa de un "IPv6 authorization error".

El nombre HELO

Cuando un servidor se conecta, se presenta con EHLO (o el más antiguo HELO) y un nombre (lección 1.2). La RFC 5321 indica que ese debería ser el nombre completo del servidor. En la práctica, los destinatarios comprueban si ese nombre:

• es un nombre real, existente (no localhost, no direcciones IP desnudas, no un nombre que no esté en el DNS);
• coincide con la reverse DNS, o al menos pertenece al mismo dominio.

En un paquete de hosting o servicio de correo, esto lo gestiona el administrador. Si usted mismo gestiona un servidor de correo, configura el nombre HELO en su software de correo (en Postfix se llama myhostname) y se asegura de que ese nombre, la PTR y el registro A coincidan todos.

Hosting compartido: la PTR no tiene por qué ser su dominio

Una pregunta frecuente: "¿No debería la reverse DNS ser mail.example.com, ya que ese es mi dominio?" No. En el hosting compartido y en los grandes servicios de correo, un único servidor envía correo para cientos o miles de dominios. La dirección IP solo puede tener una PTR, que por tanto contiene el nombre del propio servidor, por ejemplo server12.hosting.example.

Esto es correcto así. Los destinatarios comprueban si la PTR existe, apunta de vuelta y no es genérica. No comprueban si aparece el nombre de su propio dominio. El vínculo entre su dominio y el servidor lo establece con SPF (el servidor figura en su SPF) y DKIM (el servidor firma en nombre de su dominio).

En WebOké, por ejemplo, esto está organizado así: los servidores de un paquete de hosting tienen una reverse DNS con el nombre del propio servidor, bajo webawere.nl, que a su vez apunta de vuelta correctamente. En otros proveedores de hosting y servicios de correo funciona de la misma manera, con sus propios nombres de servidor.

Un servidor propio: ¿qué debe gestionar usted?

Si envía correo directamente desde un servidor propio, por ejemplo un VPS con una tienda online o un servidor de correo propio, usted mismo es el remitente y debe gestionar más cosas:

1. Elija un nombre, por ejemplo mail.example.com.
2. Cree el registro A (y el registro AAAA) de ese nombre apuntando a la dirección IP del servidor, en el DNS de su dominio.
3. Solicite la PTR al proveedor del servidor. Normalmente el panel de cliente tiene un campo "Reverse DNS" o "rDNS". Allí introduce el mismo nombre.
4. Configure el nombre HELO de su software de correo con ese mismo nombre.
5. Incluya la dirección IP en su SPF (ip4: y ip6:) y active DKIM en su software de correo.
6. Compruebe si el puerto 25 saliente está abierto. Muchos proveedores lo cierran por defecto para evitar abusos; en ese caso debe pedir que se lo abran, o enviar a través de un relay de su proveedor o un servicio de envío.

Un servidor de correo en una conexión a internet doméstica normal o de oficina casi siempre es mala idea. Esas direcciones suelen aparecer en listas de "direcciones de usuario final" (como la Policy Block List de Spamhaus, lección 5.2), normalmente no puede elegir la PTR usted mismo, y T-Online establece literalmente que esos sistemas deben enviar a través de un relay de un proveedor adecuado.

Comprobar

Con una ventana de comandos (curso de DNS, lección 8.2):

dig -x 192.0.2.25 +short
smtp.hosting.example.

dig A smtp.hosting.example +short
192.0.2.25

Si en la segunda consulta obtiene la misma dirección de vuelta, el FCrDNS es correcto. Para IPv6 haga lo mismo con dig -x 2001:db8::25 y dig AAAA.

También puede comprobar cómo lo vio un destinatario. En las cabeceras, el servidor receptor escribe el nombre que encontró entre paréntesis después de from. Si allí aparece unknown, no encontró ninguna PTR. Algunos servidores añaden también su propia comprobación, como iprev=pass en la línea Authentication-Results: (RFC 8601).

Resumen

• El servidor de envío es el servidor que entrega su correo al destinatario. Los destinatarios evalúan su dirección IP de forma independiente a su dominio.
• Esa dirección IP necesita una PTR que apunte de vuelta a la misma dirección (FCrDNS), tanto para IPv4 como para IPv6, con un nombre que no sea genérico.
• El nombre HELO debe ser un nombre existente que coincida con la PTR.
• En el hosting compartido y los servicios de correo, el nombre del servidor figura en la PTR, no su dominio. Eso es correcto.
• Con un servidor propio, usted mismo gestiona el nombre, el A/AAAA, la PTR (a través de su proveedor), el HELO, el SPF y el DKIM.

Cuestionario

Ejercicio

Ejercicio Z5.1: El servidor de envío de su propio dominio. Envíe un correo desde su propia dirección a otra dirección suya (por ejemplo una dirección de Gmail u Outlook.com) y abra las cabeceras. Busque la dirección IP del servidor que entregó el correo, el nombre PTR de esa dirección, y determine si el nombre apunta de vuelta a la misma dirección (sí/no). Si no tiene dominio propio, use la dirección IP del servidor de correo mx00.t-online.de. El programa consulta la PTR y el registro A/AAAA en tiempo real y los compara.

Para saber más

Los pasos de estos artículos son válidos para los paneles de WebOké; en otros proveedores funciona de forma similar.

• Enviar correo desde su VPS y configurar el DNS inverso
• Curso gratuito de DNS 4.6: Reverse DNS (PTR): del número de vuelta al nombre
• Cómo funciona el envío de correos (SMTP)
• RFC 5321 (SMTP), apartado 4.1.1.1 sobre el nombre EHLO; RFC 8601 sobre la cabecera Authentication-Results