Monitoreo de la salud del dominio de correo: qué comprobar y cuándo

Tu dominio de correo es, en buena parte, un puñado de registros DNS. Estaban correctos el día en que los publicaste, y después alguien cambió de hosting, añadió una herramienta de envío, rotó una clave o limpió entradas TXT "sin uso". Nada anuncia el daño. El correo sigue fluyendo un tiempo, luego los rebotes y la colocación en spam van subiendo y nadie sabe decir cuándo empezó. Esta guía explica qué significa la salud del dominio de correo, qué registros abarca, qué se rompe sin hacer ruido y en qué se diferencia una comprobación puntual de un monitoreo que se ejecuta todos los días.

La respuesta breve#

La salud del dominio de correo es la pregunta "¿están presentes, son válidos y siguen sin cambios los registros DNS que permiten al mundo entregar correo a este dominio y confiar en el correo que sale de él?". En la práctica son seis cosas: MX (¿puede alguien entregarte correo?), SPF (¿qué servidores pueden enviar en tu nombre?), DKIM (¿está publicada tu clave de firma?), DMARC (¿qué deben hacer los receptores cuando fallan las comprobaciones?), además de MTA-STS y BIMI, que son extras opcionales. Una comprobación puntual te dice el estado de ahora mismo. El monitoreo repite la comprobación con una frecuencia fija y te avisa cuando algo cambia, algo importante porque la mayoría de los fallos son regresiones, no errores de configuración inicial. Ejecuta hoy la comprobación gratuita de salud del dominio para tener una línea base y después decide si vale la pena una vigilancia diaria para los dominios de los que dependes.

Qué cubre una comprobación de salud del dominio#

Cada registro de la tabla responde una pregunta distinta, y cada uno puede fallar por su cuenta.

Los cuatro primeros son los que deciden si tu correo se entrega y genera confianza. Configurar DMARC y la visión de conjunto de SPF, DKIM y DMARC juntos explican cómo escribirlos. MTA-STS y TLS-RPT y BIMI son refuerzos opcionales, así que la ausencia de uno de ellos es información, no una emergencia.

Ten presente que los proveedores de buzones ya lo exigen. Los requisitos de remitente de Google y Yahoo esperan SPF, DKIM y un registro DMARC para los remitentes masivos, con el dominio del From alineado con SPF o DKIM, y Microsoft aplica reglas parecidas a los remitentes de alto volumen hacia direcciones de Outlook.com. Un registro que desaparece sin avisar puede pasarte de cumplir a incumplir de la noche a la mañana.

Qué se rompe sin que nadie lo note#

Los fallos de autenticación rara vez parecen fallos. El correo sigue aceptándose, una parte cae en spam y la causa es un registro que nadie revisa desde hace meses. Estos son los que aparecen una y otra vez.

• Una migración de DNS pierde registros TXT. Cambias de proveedor de DNS, la herramienta de importación copia los registros A y CNAME, y las entradas TXT de SPF, DKIM y DMARC desaparecen o quedan alteradas. La historia completa está en cuando SPF, DKIM y DMARC dejan de funcionar.
• Aparece un segundo registro SPF. Una herramienta de marketing le dice a alguien "añade este registro TXT" y ahora el dominio tiene dos registros SPF. Los receptores lo tratan como un error permanente, así que SPF falla para todo.
• SPF supera las 10 consultas DNS. Cada herramienta nueva añade un include: y un día el registro cruza el límite. SPF: demasiadas consultas DNS explica cómo contarlas y cómo solucionarlo.
• Una clave DKIM se rota o se elimina. El proveedor pasa a un selector nuevo, o alguien borra la clave antigua mientras el correo aún se firma con ella. Cómo encontrar tu selector DKIM explica cómo saber qué clave usa realmente un remitente.
• DMARC se elimina o nunca recibe informes. O bien el registro ya no existe, o bien rua= apunta a un lugar inútil, así que no puedes ver quién envía en tu nombre.
• Una clave DKIM corta se queda ahí. Una clave de 1024 bits sigue funcionando, y precisamente por eso se queda durante años. El estándar dice que los firmantes deberían usar al menos 2048.

Nada de esto necesita un atacante. Es mantenimiento ordinario, y por eso una revisión humana periódica no lo detecta: nada parece roto hasta que se mueven las cifras.

Comprobación puntual o monitoreo diario#

Una comprobación puntual es la herramienta adecuada en tres situaciones: después de publicar o cambiar registros, cuando diagnosticas una queja concreta y cuando te haces cargo de un dominio que no configuraste tú. Es gratis, tarda segundos y te da una instantánea. Ejecuta la comprobación de salud del dominio para ver el cuadro completo, o el verificador de SPF, DKIM y DMARC cuando solo necesitas los registros de autenticación.

El monitoreo responde otra pregunta: ¿qué cambió desde ayer y a quién hay que avisar? Todos los fallos anteriores ocurren entre comprobaciones. Lo que importa es el tiempo que pasa desde "el registro se rompió" hasta "alguien se dio cuenta", y con un proceso manual ese tiempo es lo que tarden los rebotes en provocar una investigación. La comprobación diaria lo reduce a un día como máximo.

Una forma razonable de decidir:

1. Un dominio, pocos cambios, una herramienta de envío: probablemente basta con una comprobación puntual después de cada cambio.
2. Varios dominios, varios remitentes o más de una persona con acceso al DNS: una vigilancia diaria se paga sola la primera vez que alguien edite un registro sin avisarte.
3. Dominios aparcados o secundarios desde los que nunca envías: revísalos de vez en cuando, porque un registro DMARC ausente o laxo ahí es una invitación a la suplantación.

De qué conviene alertar#

Una alerta solo sirve si es poco frecuente y concreta. Los registros que justifican despertar a alguien son aquellos en los que un cambio significa que el correo está fallando ahora. Como regla práctica, los separaríamos así.

Actuar el mismo día:

• MX ausente o un host MX que ya no se resuelve.
• SPF ausente, SPF publicado dos veces, un error de sintaxis o más de 10 consultas.
• DMARC ausente o inválido, incluidos dos registros DMARC.
• Un selector DKIM del que dependes que ya no devuelve una clave (el producto solo puede informar de esto para los selectores que le hayas indicado).

Revisar esta semana:

• SPF con 9 o 10 consultas, a una adición de fallar.
• DMARC todavía en p=none, o sin dirección rua= para recibir informes.
• Una clave DKIM de 1024 bits, o una clave aún marcada como de prueba (t=y).
• Un calificador ?all, o el mecanismo desaconsejado ptr en SPF.

Informativo:

• Registros MTA-STS y BIMI que aparecen o desaparecen.

El monitoreo de salud del dominio de Qualisend traduce esto a dos niveles de gravedad: 20 códigos de problema entre MX, SPF, DKIM y DMARC, cada uno marcado como "bad" o "warn", y una calificación del dominio que es simplemente la peor gravedad presente. Todo lo de la primera lista es "bad" y todo lo de la segunda es "warn". Te envía un correo cuando aparece un problema y cuando desaparece. Los errores de DNS, como los timeouts, marcan la comprobación como "no se pudo comprobar" y nunca generan alerta, para que un problema del resolvedor no se convierta en una falsa alarma. Un problema se da por resuelto tras la segunda comprobación limpia, así que el aviso de que todo está en orden puede tardar hasta dos días si no vuelves a comprobar a mano.

Una línea base y una rutina#

No necesitas una plataforma para obtener la mayor parte del valor. Haz esto una vez por dominio.

1. Anota tus remitentes. Enumera cada sistema que envía como el dominio: proveedor de buzones, plataforma de marketing, servicio transaccional, CRM, helpdesk, facturación. Cada uno debería estar reflejado en SPF y firmar con DKIM.
2. Ejecuta una comprobación de línea base y guarda el resultado. Anota el número de consultas SPF, los selectores DKIM que existen y tu política DMARC.
3. Registra los selectores DKIM que usa cada remitente. Los nombres de selector se olvidan con facilidad y luego son difíciles de adivinar. Cómo encontrar un selector DKIM muestra dónde leerlos.
4. Publica una dirección de informes en DMARC para que los fallos dejen rastro. Leer los informes y monitoreo de DMARC explican qué hacer con ellos.
5. Vuelve a comprobar después de cada cambio de DNS y después de añadir o quitar cualquier herramienta de envío, y además una vez al mes pase lo que pase.

Si un dominio importa para los ingresos, ese último paso es el que la gente deja de hacer, y es el que sustituye el monitoreo.

Lo que el monitoreo no puede ver#

Ten claros los límites para no confiar en él para lo que no debe.

• Lee el DNS público. No envía correo de prueba, no observa tus mensajes salientes reales ni mide la colocación en la bandeja de entrada. Un registro SPF puede ser perfectamente válido y aun así omitir un remitente que olvidaste añadir. Para ver cómo se autentica un mensaje real y qué ve un servidor receptor, usa la prueba de entregabilidad del correo. Tampoco mide la colocación en la bandeja de entrada.
• DMARC se interpreta; MTA-STS y BIMI solo se comprueba su presencia. No descarga un archivo de política MTA-STS ni valida un logotipo o certificado BIMI.
• Vigila dominios, no IP de envío, y nunca modifica tu DNS. Los problemas los corriges en tu proveedor de DNS.
• Diario significa diario. Un cambio se detecta en 24 horas, no en tiempo real.
• No te dice quién envía como tu dominio. Para eso están los informes agregados de DMARC, y los informes DMARC son el producto aparte construido alrededor de ellos.

El precio es fijo por nivel, a tarifas estándar: 8,99 $ al mes por un dominio, 89 $ hasta 10 y 499 $ hasta 60, sin créditos de por medio y sin obligación de comprar nada más.

Una cosa más que conviene recordar: los estándares evolucionan. DMARC se definió en el RFC 7489, que el RFC 9989 dejó obsoleto en mayo de 2026, así que consulta el texto vigente si dependes de un comportamiento en casos límite.

Un DNS sano hace que tu correo inspire confianza, pero no limpia la lista que hay detrás. El plan gratuito de la página de precios incluye 100 créditos que ejecutan la verificación completa en una lista, porque un dominio bien monitoreado sigue necesitando una lista sana para ganarse la bandeja de entrada.