¿El correo cae en spam? Revisa tres cosas de la IP de envío
PTR, el límite de consultas de SPF y el orden de DMARC: las tres comprobaciones que explican casi todos los fallos de entrega.
Cuando un correo transaccional deja de llegar, el primer impulso es reescribir el texto. Nueve de cada diez veces el receptor nunca llegó a leerlo: decidió antes de que el cuerpo importara, según quién se conectaba y desde dónde.
1. Lo primero que se consulta es el PTR
El servidor receptor resuelve inversamente tu IP y compara el resultado con el nombre que usaste en el saludo SMTP. En una instancia en la nube el puntero por defecto es algo como ec2-13-52-1-9.compute-1.amazonaws.com: no tiene relación con tu dominio, anuncia al proveedor y muchas reglas lo penalizan de inmediato. Ponlo en algo que controles —mail.example.com— y haz que la cadena HELO coincida exactamente. La discrepancia entre HELO y PTR es una de las señales más baratas que puede usar un filtro.
Ojo: normalmente no puedes fijar el PTR tú mismo. En un VPS es un ticket; en la nube es un ajuste de IP elástica. Si un proveedor se niega a configurarlo, eso te dice para qué espera que se use su espacio.
2. SPF tiene un límite duro de diez consultas
SPF se evalúa resolviendo cada include, a, mx y ptr, y el RFC 7208 limita el total a diez consultas DNS. Si lo superas, el resultado es permerror, que los receptores tratan como fallo, a menudo en silencio porque nadie vigila los permerror. Una pila típica de plataforma de marketing, helpdesk y CRM basta para llegar al tope sin que nadie añada un mecanismo a mano.
Cuenta las consultas antes de añadir otro include y aplana lo que puedas: si un proveedor publica un rango estable, lístalo con ip4: en lugar de anidar includes. Si estás al límite, la solución honesta es enviar desde menos proveedores, no subir el límite: no se puede.
3. Primero DKIM, después DMARC por etapas
DKIM firma el mensaje con una clave publicada como registro TXT; hoy lo estándar son 2048 bits. El error clásico es rotar el selector y borrar el registro antiguo el mismo día, lo que rompe todos los mensajes en tránsito: mantén el selector anterior publicado al menos una semana.
DMARC va encima y dice a los receptores qué hacer cuando ni SPF ni DKIM se alinean con el dominio del From. Empieza en p=none con una dirección rua, recoge informes dos o tres semanas y solo entonces pasa a quarantine y luego a reject. Saltarse la observación es descubrir, el día del cambio a reject, que el sistema de facturas lleva años enviando por un relé sin autenticar.
4. IP compartida o dedicada
- Los pools compartidos son baratos y ya están calientes, pero parte de tu reputación es la del vecino. Un WordPress comprometido en el pool afecta la entrega de todos.
- Una IP dedicada empieza sin reputación. Enviar mil mensajes el primer día te gana limitación; empieza con decenas al día y crece durante dos o tres semanas.
- El envío por IPv6 tiene su propia reputación. Un dominio con historial limpio en IPv4 seguirá siendo nuevo en una dirección IPv6 recién estrenada.
- Casi todos los VPS y nubes bloquean el puerto 25 por defecto. Si vas a enviar desde una instancia, abre un ticket antes de construir nada.
5. Mira las listas negras antes de depurar otra cosa
Consulta la IP en Spamhaus ZEN, Barracuda y AbuseIPDB, y consulta también el /24 alrededor: varias listas operan por rango completo porque quien envía spam rara vez compra una sola dirección. Una inclusión nueva suele tener formulario de retirada; úsalo y después averigua qué enviaba el correo, porque una retirada sin arreglo dura más o menos una semana.
ipbox.one incluye una herramienta de consulta DNS que resuelve A, AAAA, MX, TXT y NS sobre DNS-over-HTTPS, suficiente para leer tu SPF, tu selector DKIM y tu registro DMARC desde el navegador mientras recorres la lista.