Nova Uptime
Gestión de dominiosdomain-healthdomain-auditdns-check

Comprobación de salud de dominio: auditoría completa gratis (DNS + SSL + email + uptime)

Audita la salud de tu dominio en 5 minutos: DNS, SSL, autenticación de email (SPF/DKIM/DMARC), blacklists y uptime. Checklist paso a paso incluida.

SN
Sumit Nova Uptime
29 de abril de 2026 · 15 min read
Share:

Por qué importa la salud del dominio#

Cuando la mayoría de equipos dicen "el dominio está sano", lo que normalmente quieren decir es "la web devolvió un 200 la última vez que alguien lo comprobó". Esa es una señal de al menos cinco — y cuatro de las otras cuatro causan más caídas, más pérdida de ingresos y más daño a la confianza del cliente que la única que todo el mundo vigila.

Un dominio está sano cuando es alcanzable, seguro, autenticado, reputado y observable. El SEO depende de eso (Google penaliza el contenido mixto, los certs caducados y un TTFB lento). La entregabilidad depende de eso (Gmail y Yahoo ahora rechazan correo de dominios mal alineados para envíos masivos). La seguridad depende de eso (un CNAME colgante es un secuestro de subdominio esperando a ocurrir). Y la confianza del cliente depende de eso (un aviso del navegador en el momento en que se introduce una tarjeta de crédito es una conversión muerta y un reembolso disparado).

Esta guía es una auditoría de 5 minutos. Al terminar sabrás exactamente cuál de los cinco pilares está fallando ahora mismo en tu dominio en silencio, qué comando ejecutar para confirmarlo y qué herramienta gratuita de Nova Uptime usar para arreglarlo. Sin paja, sin marketing — solo la auditoría que un SRE senior haría si le pasaras un dominio y le preguntaras: "¿esto está en buen estado?".

Los 5 pilares de la salud de un dominio#

Antes de ir pilar a pilar, aquí va el modelo mental. Cualquier dominio sano pasa los cinco checks. La mayoría de dominios en producción fallan al menos uno — y el equipo rara vez se entera hasta que el fallo se convierte en un ticket de cliente.

  • Pilar 1: configuración DNS — A, AAAA, MX, CNAME, TXT, DNSSEC. ¿Están todos los registros presentes, correctos y apuntando donde deben?
  • Pilar 2: certificados SSL/TLS — ventana de validez, integridad de la cadena, cobertura de SAN, fortaleza de cipher, HSTS. ¿Todos los navegadores van a confiar en el cert hoy y dentro de 60 días?
  • Pilar 3: autenticación de email — SPF, DKIM, DMARC, alineación. ¿Pueden los atacantes suplantar tu dominio? ¿Llegan los emails legítimos a la bandeja o a spam?
  • Pilar 4: reputación — listados DNSBL en Spamhaus, Barracuda, SORBS, SpamCop. ¿Tu IP de envío o tu dominio está en una blacklist que está machacando tu deliverability en silencio?
  • Pilar 5: uptime y rendimiento — código HTTP, percentiles de tiempo de respuesta, alcanzabilidad multi-región, caducidad del dominio, antigüedad del registro. ¿El sitio está realmente arriba, rápido y no a punto de caducar el martes que viene?

Cada pilar tiene un check de 30 segundos que puedes ejecutar desde una terminal, una inspección más profunda con una herramienta gratuita de Nova Uptime y un monitor continuo que puedes configurar para que te avisen antes del próximo fallo.

Pilar 1: configuración DNS#

DNS es la base. Si el DNS está mal, ninguno de los otros cuatro pilares importa — la petición nunca llega a tu servidor.

Los registros que importan#

  • Registros A mapean un hostname a una dirección IPv4. Cada dominio necesita al menos uno para el apex y otro para www.
  • Registros AAAA mapean un hostname a una dirección IPv6. La mayoría de equipos los saltan. No deberían. El tráfico IPv6 ahora supone rutinariamente el 30–40 % del tráfico móvil en mercados grandes, y un AAAA ausente fuerza al fallback a IPv4 — añadiendo latencia y, en redes de operador mal configuradas, fallos ocasionales.
  • Registros MX definen el enrutamiento del correo. Múltiples MX usan valores de prioridad (menor = preferido). El bug más común que vemos es un registro MX con prioridad 0 apuntando al apex cuando el apex no tiene listener SMTP — el correo rebota en silencio.
  • Registros CNAME son alias. El peligro son los CNAMEs colgantes: un CNAME apuntando a un servicio que ya no usas (un bucket S3 deprecado, una app de Heroku vieja, una instancia de Zendesk descatalogada). Un atacante que reclame ese recurso en el proveedor upstream se queda con tu subdominio.
  • Registros TXT llevan verificaciones, SPF, DMARC, tokens de propiedad de dominio. Hay que auditarlos periódicamente — verificaciones viejas de servicios que ya no usas atascan la zona y aumentan el conteo de lookups SPF.
  • DNSSEC añade una cadena de confianza criptográfica a las respuestas DNS. Previene el envenenamiento de caché y el secuestro DNS. No es estrictamente requerido, pero para cualquier dominio que maneje dinero, credenciales o datos sanitarios es recomendable.

Comprobaciones rápidas#

dig +short A tudominio.com
dig +short AAAA tudominio.com
dig +short MX tudominio.com
dig +short TXT tudominio.com
dig DNSKEY tudominio.com +short

Para validación específica de MX, ejecuta el comprobador de salud de email de Nova Uptime — confirma los registros MX, las prioridades y resuelve cada hostname MX a su IP.

Pilar 2: certificados SSL/TLS#

Un cert que funciona no es suficiente. Hay seis cosas independientes que pueden estar mal en un certificado SSL, y la mayoría de herramientas de monitorización comprueban exactamente una de ellas — la fecha de caducidad.

Qué verificar#

  • notBefore y notAfter definen la ventana de validez. Con el ciclo de 90 días de Let's Encrypt y el empuje del sector hacia certs de 47 días en 2028, la caducidad llega rápido y en silencio. Necesitas saberlo a 30 días vista.
  • Integridad de la cadena del emisor. El cert que tu servidor presenta debe incluir los certificados intermedios que lo enlazan con una raíz de confianza. El cert valida bien en Chrome (que cachea intermedios) pero falla en Safari antiguo, en iOS o en herramientas headless que no cargan los intermedios ausentes. Es el bug SSL "pero funciona en mi navegador" más común.
  • Cobertura de SAN (Subject Alternative Name). El cert debe listar todos los hostnames a los que sirve: apex, www y cualquier subdominio que use el mismo cert. Un cert válido para www.tudominio.com pero no para el apex desnudo es una mala configuración habitual.
  • Cipher suites y versiones de protocolo. TLS 1.0 y 1.1 están deprecados. TLS 1.2 es el suelo; TLS 1.3 es el objetivo. Los ciphers débiles (RC4, 3DES, cualquier cosa con modo CBC en configuraciones antiguas) deberían estar deshabilitados.
  • Cabecera HSTS. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload le dice a los navegadores que rechacen HTTP para siempre. Sin HSTS, un atacante man-in-the-middle puede degradar la conexión en el primer contacto.
  • OCSP stapling. El servidor adjunta una prueba firmada de la validez del cert al handshake TLS, eliminando un round-trip al respondedor OCSP de la CA. Es más rápido y más privado. La mayoría de servidores web modernos lo soportan; pocos lo tienen activado.

Comprobación rápida#

echo | openssl s_client -servername tudominio.com -connect tudominio.com:443 2>/dev/null \
  | openssl x509 -noout -dates -issuer -subject

Para monitorización continua con alertas de caducidad a 30 días y validación de cadena, usa el comprobador de caducidad SSL de Nova Uptime.

Pilar 3: autenticación de email#

Este es el pilar donde 2026 cambió las reglas. La aplicación de Gmail y Yahoo para remitentes masivos significa que un registro DMARC ausente o mal alineado ahora te cuesta colocación en bandeja, no solo reputación.

SPF — quién puede enviar por tu dominio#

SPF es un registro DNS TXT que lista las IPs y dominios autorizados a enviar correo como tú. Las dos trampas:

  • El límite de 10 lookups DNS. Cada include: en tu registro SPF cuenta. Solo SendGrid son 3 lookups; añade Google Workspace (3), Mailchimp (1) y un proveedor transaccional (3), y ya estás por encima del límite. Los servidores receptores devuelven permerror y tu correo falla.
  • El cualificador +all (o ninguno). El cualificador del final (-all, ~all, ?all, +all) le dice al receptor qué hacer con el correo de fuentes no listadas. +all es "cualquiera puede enviar como yo" — no lo uses nunca.

Valida con el comprobador SPF de Nova Uptime.

DKIM — firma criptográfica#

DKIM firma cada mensaje saliente con una clave privada. El receptor recupera la clave pública desde selector._domainkey.tudominio.com y verifica la firma. Las dos trampas:

  • Confusión de selector. No hay wildcard para DKIM. Tienes que conocer el selector que usa tu servicio de envío (s1, google, mandrill, selector1, etc.). La clave está en {selector}._domainkey.tudominio.com.
  • Rotación de claves. Las claves DKIM deberían rotarse anualmente. La mayoría de equipos las configuran una vez y se olvidan durante cinco años.

Comprueba con el comprobador DKIM de Nova Uptime, que escanea automáticamente 50 selectores comunes.

DMARC — la capa de política#

DMARC le dice a los servidores receptores qué hacer cuando SPF y DKIM fallan. Tres políticas:

  • p=none — solo monitorizar, sin acción. Úsalo las primeras 2–4 semanas mientras recoges informes.
  • p=quarantine — manda el correo que falle a spam.
  • p=reject — rechaza el correo que falle directamente. Este es el objetivo.

La mayoría de dominios se quedan atascados en p=none para siempre porque nadie lee los informes agregados (rua). No seas la mayoría. Recorre nuestra guía de configuración de política DMARC y valida con el comprobador DMARC de Nova Uptime.

Alineación — la parte que todo el mundo se salta#

DMARC requiere que el dominio SPF o DKIM esté alineado con el dominio de la cabecera From. Un mensaje puede pasar SPF (para mailgun.org) y pasar DKIM (firmado por mandrillapp.com), pero si la cabecera From dice tu@tudominio.com, DMARC falla porque nada se alinea. Arréglalo configurando dominios de return-path personalizados y dominios de firma DKIM para cada servicio de envío.

Para los cuatro checks a la vez, usa el comprobador de salud de email de Nova Uptime — puntúa SPF, DKIM, DMARC y alineación juntos.

Pilar 4: reputación (blacklists)#

Incluso con autenticación perfecta, una mala reputación te lleva a spam. Las DNSBLs (blocklists basadas en DNS) son los marcadores públicos.

Qué rastrean las DNSBLs#

Algunas blocklists rastrean IPs (la dirección de tu servidor de correo de envío). Otras rastrean dominios (la URI en el cuerpo del mensaje). Cada blocklist tiene sus propios criterios de listado, pero los disparadores comunes son: enviar a spam traps, alta tasa de quejas, picos de volumen repentinos y estar en el mismo bloque IP que spammers conocidos.

Las listas que importan#

  • Spamhaus SBL/XBL/PBL/DBL — el patrón oro. Los grandes proveedores de buzón consultan Spamhaus directamente.
  • Barracuda Reputation Block List — muy usada por filtros enterprise.
  • SORBS — agrega varios feeds; puede ser agresiva.
  • SpamCop — alimentada por quejas de usuarios; periodos de listado relativamente cortos pero gran volumen.

Por qué podrías estar listado#

Las cuatro razones más comunes: (1) una cuenta comprometida en tu plataforma envió spam, (2) un cliente en una IP compartida lo hizo, (3) enviaste una campaña a una lista vieja sin verificar, (4) tus formularios permiten registro sin autenticar y los bots están usando tu plataforma para enviar.

Cómo comprobarlo#

Usa el comprobador de blacklists de Nova Uptime — consulta 60+ DNSBLs en paralelo y muestra exactamente qué listas han marcado tus IPs y dominios, con enlaces de delisting para cada una.

Si estás listado, primero arregla la causa raíz (cierra la cuenta comprometida, limpia la lista, arregla el formulario), luego envía solicitudes de delisting. Volver a aparecer una semana después con la misma causa raíz te conseguirá un baneo más largo.

Pilar 5: uptime y rendimiento#

Este es el pilar que todo el mundo vigila — y aun así, la mayoría de equipos vigilan solo una métrica.

Qué medir#

  • Código de estado HTTP. 200 es saludable. 4xx es problema tuyo. 5xx es problema de tu servidor. Las redirecciones 3xx deberían resolverse en un 200 en menos de 3 saltos.
  • Percentiles de tiempo de respuesta. La mediana (p50) es la historia oficial; p95 y p99 son la verdad. Un sitio con p50 de 200 ms y p99 de 9.000 ms tiene un problema serio que afecta a 1 de cada 100 peticiones — normalmente una query lenta de base de datos o caché fría.
  • Alcanzabilidad multi-región. La monitorización de una sola región pilla tus caídas. Se pierde las caídas de tus clientes — el flap de ruta BGP en Asia, el incidente regional de Cloudflare, la disputa de peering de un ISP que afecta al 10 % de tus usuarios.
  • Capturas de fallo. Cuando el sitio cae, captura la pantalla que ve el usuario. "Sitio inalcanzable" se ve idéntico desde un monitor tanto si es un 500, una página de challenge de Cloudflare, o un iframe de proveedor de pago fallando.
  • Caducidad del dominio. Los dominios caducan. La auto-renovación falla (tarjeta caducada, cuenta del registrador suspendida, email de facturación yendo al buzón de un ex-empleado). Sigue la fecha de caducidad del registrador — y la antigüedad del registro, que indica autoridad para SEO.

Para monitorización continua con intervalos de 59 segundos, checks multi-región, capturas y alertas por WhatsApp/email/webhook, regístrate en la página de precios de Nova Uptime. Para comprobaciones puntuales de antigüedad y caducidad de registro, usa el comprobador de caducidad de dominio y el comprobador de antigüedad de dominio.

Checklist de salud en 5 minutos#

Ejecútalas en orden. Cada paso tiene un pasa/falla claro.

  1. DNSdig +short A tudominio.com && dig +short AAAA tudominio.com && dig +short MX tudominio.com. Las tres deberían devolver valores. Si MX está vacío, el correo está roto.
  2. SSLecho | openssl s_client -servername tudominio.com -connect tudominio.com:443 2>/dev/null | openssl x509 -noout -dates. notAfter debería estar a más de 30 días.
  3. SPF — visita /tools/spf-checker, introduce tu dominio. La puntuación debería ser 90+.
  4. DKIM — visita /tools/dkim-checker, introduce tu dominio. El estado debería ser "Configurado".
  5. DMARC — visita /tools/dmarc-checker. La política debería ser quarantine o reject, no none.
  6. Salud de email (combinada)/tools/email-health da una nota A–F sobre todo lo anterior.
  7. Blacklists/tools/blacklist-checker. Cero listados es el objetivo.
  8. Comprobación SSL profunda/tools/ssl-expiry para validación de cadena y alertas a 30 días.
  9. Caducidad de dominio/tools/domain-expiry. Debería estar a más de 60 días; cuanto más, mejor para la autoridad SEO.
  10. Uptimecurl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://tudominio.com. Estado 200, tiempo bajo 1,5 s.

Si alguna falla, acabas de identificar tu prioridad principal.

Historias del mundo real#

Algunos ejemplos de los últimos seis meses ayudando a equipos a auditar sus dominios:

El DKIM mal alineado que se escondió seis meses. Una SaaS B2B enviaba correos transaccionales a través de un subdominio personalizado (mail.suweb.com) pero el tag d= de DKIM era el dominio del proveedor, no el suyo. El periodo de gracia de Gmail hizo que el correo aún llegase a bandeja a volúmenes bajos. Cuando lanzaron su primera campaña grande — 50.000 emails — las tasas de apertura fueron del 4 %. Los informes de rebote mostraban que Gmail llevaba meses degradando los mensajes en silencio. La solución fue un cambio DNS de 10 minutos. La lección fue que "la deliverability se ve bien" no es una medida.

El cert intermedio que solo Safari notó. Un e-commerce auto-renovó su cert SSL a través de su hosting. El nuevo cert se desplegó correctamente, pero el certificado intermedio faltaba en el bundle. Chrome y Firefox cachearon el intermedio de visitas previas y siguieron validando. Safari (que no cachea agresivamente los intermedios) mostraba un aviso de seguridad a página completa. Alrededor del 18 % de su tráfico de checkout era iOS Safari. Perdieron dos días de ingresos antes de que un ticket de soporte conectase los puntos.

El CNAME colgante que se convirtió en un secuestro. Una vieja landing de marketing en promo.sudominio.com era un CNAME a una app de Heroku que se había borrado tres años antes. Un atacante registró el mismo nombre de app en Heroku, y durante 12 horas ese subdominio sirvió HTML arbitrario — incluyendo un formulario de phishing imitando la página de login de la empresa. La solución fueron 30 segundos de limpieza de DNS. El descubrimiento fue cero — el equipo solo se enteró cuando un cliente reportó el intento de phishing. Una auditoría mensual de subdominios lo habría pillado.

Conclusión#

La salud de un dominio son cinco pilares, no uno. Ejecuta la checklist de 5 minutos de arriba. Arregla los fallos. Luego pon un monitor continuo en las cosas que derivan con el tiempo — los certs caducan, las blacklists cambian, los registros expiran y los registros SPF crecen hasta romper el límite de lookups. Los cinco pilares, gratis, en un solo dashboard en Nova Uptime.

Lecturas relacionadas#

Monitor Your Website Before It Goes Down

Get uptime monitoring, SSL tracking, domain expiry alerts, and email health checks. Free plan — no credit card required.

Start Monitoring Free

Artículos relacionados