Tu Correo Pasa SPF, DKIM y DMARC y Aun Así Va a Spam

Tienes SPF, DKIM y DMARC bien configurados. Las herramientas de diagnóstico te dan todo en verde. Los informes que te mandan Google y Microsoft dicen que tus correos pasan. Y aun así, cuando haces una prueba a una cuenta de Gmail, el mensaje aparece en correo no deseado.

Es de los casos más frustrantes del correo, porque todo lo que sabes mirar dice que está bien. Y hay una comprobación que casi nadie hace, porque no forma parte de esas tres siglas: el nombre de la IP que envía el correo.

Lo vimos hace poco en un campus de formación. Los avisos a los alumnos caían en spam, el dominio ya estaba bien acreditado, los informes salían aprobados, y el problema estaba en una línea de configuración que ninguno de esos informes enseña. Te contamos qué es, por qué se rompe con facilidad y cómo se comprueba en dos minutos.

La idea en una frase

Cada IP que envía correo debe tener un nombre, y ese nombre debe apuntar de vuelta a la misma IP. Si el viaje de ida y vuelta no cuadra, Gmail y Outlook desconfían del servidor, aunque el mensaje venga perfectamente firmado.

Es como un remitente que firma la carta con su nombre real pero pone un remite que no corresponde a ninguna casa. La firma es buena. El sobre, sospechoso.

Qué es el PTR y qué es la ida y vuelta

En internet, lo normal es ir de un nombre a una IP: escribes avantys.com y el DNS te dice en qué dirección está. Eso es un registro A.

El PTR, también llamado DNS inverso, hace el camino contrario: le das una IP y te dice qué nombre tiene. Los servidores de correo que reciben un mensaje hacen las dos consultas seguidas:

1. De la IP al nombre. "Me está conectando la IP 203.0.113.25. ¿Cómo se llama?" El PTR responde, por ejemplo, correo.tuempresa.com.
2. Del nombre a la IP. "¿Y correo.tuempresa.com en qué IP está?" El registro A tiene que responder 203.0.113.25, la misma de antes.

Si las dos respuestas cuadran, el servidor está bien identificado. En la jerga se llama FCrDNS (DNS inverso confirmado en los dos sentidos). Si no cuadran, o si la IP no tiene nombre, el servidor queda marcado como mal configurado. Y un servidor mal configurado es exactamente lo que parece un equipo infectado mandando spam.

El tercer dato que se compara: el saludo del servidor

Hay una pieza más. Cuando tu servidor conecta con Gmail para entregar un mensaje, lo primero que hace es presentarse con un nombre. Ese saludo se llama HELO (o EHLO) y lo ves luego en las cabeceras del mensaje recibido.

Lo sano es que los tres datos cuenten la misma historia:

Dato	De dónde sale	Qué debe decir
La IP que conecta	La red, no se puede falsear	203.0.113.25
El nombre de esa IP (PTR)	Lo configura quien controla la IP	correo.tuempresa.com
El saludo del servidor (HELO)	La configuración del servidor de correo	correo.tuempresa.com
La IP de ese nombre (registro A)	El DNS del dominio	203.0.113.25

Si un servidor saluda con un nombre que resuelve a otra IP, o su IP se llama de una forma y él se presenta de otra, las piezas no encajan. Gmail no suele rechazar por esto solo, pero lo suma a la puntuación del mensaje, y con un remitente que aún no tiene buena reputación basta para acabar en spam.

Por qué los informes de DMARC no te lo avisan

Aquí está el motivo de que este fallo sobreviva tanto tiempo sin que nadie lo vea.

DMARC solo mira dos cosas: si el mensaje pasa SPF y si pasa DKIM, y si esos dominios coinciden con el del remitente. Nada más.

• SPF comprueba que la IP está autorizada a enviar en nombre de tu dominio. No le importa cómo se llame esa IP.
• DKIM comprueba la firma del mensaje. No le importa desde qué IP salió.
• DMARC junta los dos resultados. Tampoco pregunta por el nombre.

Así que puedes tener los informes DMARC de Google y de Microsoft al cien por cien aprobados y, a la vez, un PTR que no cuadra. Las dos cosas son ciertas a la vez. En el campus que te contábamos, los informes de una semana entera daban todos los envíos como aprobados mientras la IP estaba mal identificada. Si te guías solo por esos informes, no lo vas a encontrar nunca.

Si todavía no tienes esas tres piezas en orden, empieza por ahí: lo explicamos paso a paso en SPF, DKIM y DMARC para el correo de Moodle, y vale para cualquier servidor.

Cómo se rompe sin que nadie toque nada raro

Lo traicionero de este fallo es que casi nunca nace de un error evidente. Nace de un cambio razonable que deja una pieza atrás:

• Añadir una IP nueva para el correo. Es el caso más típico. Alguien decide separar el correo en una IP propia para "empezar con reputación limpia", la configura, el correo sale por ella, y el PTR de esa IP nueva se queda apuntando al nombre del servidor, que resuelve a la IP antigua. La ida funciona. La vuelta, no. Justo lo que pasó en el campus.
• Cambiar el nombre del servidor. Se renombra la máquina, el servidor de correo empieza a saludar con el nombre nuevo, y el PTR sigue con el viejo.
• Migrar a otro servidor. La IP cambia, el registro A se actualiza, y nadie se acuerda de pedir el PTR de la IP nueva.
• La IPv6 que nadie miró. Muchos servidores tienen también dirección IPv6, y si el correo sale por ella, necesita su propio PTR y estar en el SPF. Es frecuente que no tenga ninguna de las dos cosas. Cuando se cambia la configuración de salida del correo, hay que confirmar por cuál de las dos sale.
• El nombre genérico del proveedor. Algunas IP vienen con un PTR del tipo vps-12345.proveedor.net. Suele cuadrar en los dos sentidos, pero es un nombre que no dice nada de ti y que comparte patrón con miles de máquinas. Funciona, aunque es mejor uno propio.

La idea de fondo: cada vez que cambia la IP por la que sale el correo, hay que volver a comprobar el nombre. No basta con que estuviera bien antes.

Cómo comprobarlo tú en dos minutos

No hace falta acceso al servidor. Basta con un correo recibido y un terminal (o una herramienta web de consultas DNS).

1. Averigua por qué IP sale tu correo. Envíate un mensaje a una cuenta de Gmail y ábrelo con "Mostrar original". Busca la primera cabecera Received que menciona tu servidor. Tiene este aspecto:

Received: from correo.tuempresa.com (correo.tuempresa.com. [203.0.113.25])

Ahí tienes el saludo del servidor (correo.tuempresa.com) y la IP real (203.0.113.25). Usa esa IP, no la que creas que usa. Nosotros encontramos el fallo precisamente porque la IP de salida ya no era la de siempre.

2. Pregunta el nombre de esa IP:

dig -x 203.0.113.25 +short

Debe devolver un nombre, por ejemplo correo.tuempresa.com.. Si no devuelve nada, la IP no tiene PTR, y ese es tu problema.

3. Pregunta la IP de ese nombre:

dig correo.tuempresa.com A +short

Debe devolver exactamente la misma IP del paso 1. Si devuelve otra, la vuelta no cuadra.

4. Compara con el saludo. El nombre que aparecía en la cabecera Received debería ser el mismo del paso 2, o al menos uno que también resuelva a esa IP.

Si los cuatro datos encajan, el nombre de tu IP está bien y el problema de spam está en otra parte. Si alguno no encaja, ya sabes qué arreglar.

Cómo se arregla

Aquí hay una trampa que despista a mucha gente: el PTR no se configura en el DNS de tu dominio. Lo controla quien es dueño de la IP, que casi siempre es el proveedor del servidor. Se cambia desde su panel o pidiéndoselo a su soporte. En cambio, el registro A del nombre sí está en el DNS de tu dominio. Son dos sitios distintos y hay que tocar los dos.

Tienes dos caminos:

1. Arreglar la IP nueva. Eliges un nombre propio (por ejemplo correo.tuempresa.com), creas su registro A apuntando a la IP de salida, pides al proveedor que el PTR de esa IP apunte a ese nombre y configuras el servidor de correo para que salude con él. Si la IP es nueva, además tendrás que darle tiempo y volumen para que gane reputación.
2. Volver a salir por la IP que ya estaba bien. Si la IP principal del servidor tiene el nombre bien configurado y años de envíos limpios, muchas veces lo sensato es devolver el correo a ella. Fue lo que hicimos en el campus: los envíos pasaron a salir por la IP principal, con su nombre en regla, y dejaron de fallar las validaciones.

Después, repite las cuatro comprobaciones. Y ya que estás, confirma que el correo no se escapa por IPv6: una prueba de envío y la cabecera Received lo dejan claro.

Por qué una IP nueva no es la solución mágica

Este fallo suele aparecer justo después de intentar arreglar el spam cambiando de IP. Tiene lógica: si Gmail desconfía de tu servidor, parece razonable empezar de cero en otra dirección. Pero una IP nueva llega con dos problemas:

• No tiene historial. Gmail no la conoce, así que no confía en ella. Si envías pocos correos al día, nunca acumulará el historial que la haría fiable.
• Hay que volver a configurarlo todo. El nombre, el saludo, el SPF y la IPv6. Cada pieza que se quede atrás es una razón más para acabar en spam.

En el campus que te contábamos, el mismo cliente tenía un segundo campus con la misma configuración de Moodle, que enviaba cinco veces más correo por la IP de siempre y no tenía ningún problema. La IP nueva no aportaba nada, y además venía con el nombre mal puesto. Lo desarrollamos en IP dedicada o compartida: cuál necesitas.

Y si todo está bien identificado y el correo sigue cayendo en spam, el siguiente sospechoso es la reputación del propio dominio. Ahí ayuda el tiempo, un volumen estable y, en algunos casos, enviar a través de una plataforma especializada. Lo contamos en Enviar el correo de Moodle por una plataforma externa.

Primero, descarta que no te estén rechazando

Antes de ponerte con el PTR, asegúrate de que el correo llega de verdad a la carpeta de spam. A veces lo que parece spam es un rechazo: el mensaje no llega a ninguna carpeta porque Gmail lo devuelve. Se arregla de otra forma, y lo explicamos en Tus correos de Moodle no llegan a spam: te los rechazan.

En resumen

• SPF, DKIM y DMARC en verde no garantizan la bandeja de entrada.
• Cada IP que envía correo necesita un nombre (PTR) que apunte de vuelta a esa misma IP, y el servidor debe saludar con ese nombre.
• Los informes de DMARC no miran esta pieza, así que puedes tenerla rota con todo aprobado.
• Se rompe al añadir una IP, al migrar, al renombrar el servidor o cuando el correo sale por IPv6.
• Se comprueba con una cabecera de un correo recibido y dos consultas DNS.
• El PTR lo cambia el dueño de la IP (tu proveedor), no el DNS de tu dominio.

Preguntas frecuentes

¿Gmail rechaza el correo si el PTR no cuadra? Puede hacerlo: si la IP no tiene nombre o el nombre no vuelve a ella, Gmail tiene un código de rechazo específico para eso (550-5.7.25). Pero también es frecuente que lo acepte y lo mande a spam, que fue lo que vimos. Depende de cuánto confíe en el resto del mensaje.

¿Puedo cambiar el PTR yo mismo? Solo si tu proveedor te da esa opción en su panel, algo habitual en servidores virtuales y dedicados. En un alojamiento compartido no se puede: la IP es del proveedor y el nombre lo decide él.

¿Qué nombre pongo en el PTR? Uno que sea tuyo y que resuelva a esa IP, por ejemplo correo.tuempresa.com. No tiene que coincidir con el dominio desde el que envías, pero sí tiene que existir y volver a la misma IP.

He arreglado el PTR y sigo en spam. ¿Ahora qué? Los buzones que ya te tenían clasificado como spam tardan unos días en cambiar de opinión. Repite la prueba pasado ese tiempo. Si sigue igual, el siguiente paso es la reputación del dominio.

¿Esto afecta también al correo que envía mi web, no solo al de Moodle? Sí. Cualquier correo que salga de tu servidor pasa por la misma comprobación: formularios de contacto, avisos de una tienda o notificaciones de cualquier aplicación.

Si prefieres no pelearte con esto, es parte de lo que hacemos en administración de servidores: revisamos por dónde sale tu correo y que cada pieza esté en su sitio, también cuando cambia algo.