Test de Salud del Dominio

Qué cubre de verdad la "salud del dominio"

La salud del dominio no es una sola cosa. Son tres capas apiladas, y un problema en cualquiera aparece como un síntoma distinto. La capa de abajo es la resolución: ¿el mundo puede convertir tu nombre en una dirección? La del medio es la autenticación de correo: cuando tu dominio envía un mensaje, ¿el servidor que recibe puede probar que fuiste tú? La de arriba es la seguridad de transporte: ¿el certificado TLS está bien para que el navegador no reclame?

La mayoría de los casos de "el sitio anda pero los correos van a spam" viven en la capa del medio, y es justo donde nadie mira, porque el sitio carga sin problemas. El test existe para mostrar las tres a la vez, así no depuras un registro mientras el culpable es otro.

DNS: si el nombre resuelve, y hacia dónde

El escaneo toma tus registros A (las direcciones IPv4 a las que apunta el dominio) y tus registros NS (los servidores de nombres que responden por la zona). Sin registro A el dominio no resuelve — nada más importa hasta arreglar eso. Un solo servidor de nombres es un punto único de falla: si se cae, todo el dominio queda a oscuras, por eso la práctica del RFC 1034 y los registradores esperan al menos dos, en infraestructura separada.

El DNS también lleva un TTL en cada registro — los segundos que los resolvers pueden cachearlo. Un TTL alto (86400, un día entero) hace que un cambio de hoy no se vea en todos lados hasta mañana. Ese retraso es la "propagación", y por eso un registro puede verse correcto en el panel del registrador y aún así resolver al valor viejo por horas.

Autenticación de correo: SPF, DKIM, DMARC

Estos tres registros son lo que el servidor que recibe usa para decidir si tu correo es legítimo. El SPF es un registro TXT que lista qué servidores pueden enviar por tu dominio. Tiene un límite que tumba a mucha gente: un máximo de 10 consultas DNS durante la evaluación (RFC 7208 §4.6.4). Encadena demasiados include: — efecto común de ir sumando cada proveedor SaaS — y el SPF devuelve permerror, que muchos receptores tratan como falla.

El DKIM firma cada mensaje con una clave privada; quien recibe busca la clave pública en tu DNS y verifica la firma, probando que el cuerpo no fue alterado en el camino. El DMARC amarra SPF y DKIM y le dice al receptor qué hacer cuando un mensaje falla en ambos: p=none es "no hagas nada, solo repórtame", p=quarantine es "mándalo a spam", p=reject es "recházalo". Un dominio parado en p=none publica una política que no protege a nadie — es solo monitoreo.

Desde febrero de 2024, Google y Yahoo exigen a quien envía en volumen (a grandes rasgos, 5.000+ mensajes por día a sus usuarios) tener SPF, DKIM y un registro DMARC, o el correo se limita o se rechaza. Ese solo cambio convirtió la autenticación de "estaría bueno tenerla" en un requisito duro, y es la razón de que un dominio que enviaba bien el año pasado vea la entrega desplomarse de golpe.

TLS: el certificado y su reloj

El escaneo conecta al puerto 443 y lee el certificado como lo haría un navegador: si es válido para ese hostname, quién lo emitió y cuántos días faltan para que venza. Un certificado vencido es la falla más ruidosa de la lista — el navegador reemplaza tu página con una advertencia a pantalla completa, y los servidores de correo que negocian STARTTLS pueden rechazar la conexión.

La trampa clásica es la automatización que se detiene en silencio. Los certificados de Let's Encrypt duran 90 días y deberían renovarse solos; cuando el cron de renovación muere, nadie se entera hasta que se acaban los 90 días. Por eso el test muestra los días exactos que quedan, no un simple válido/inválido — un certificado con 6 días de vida es técnicamente válido y está a punto de volverse una caída.