Un escaneo de 671.693 dominios muestra que más de la mitad carece de configuraciones DMARC aplicables, lo que deja a los agentes de correo electrónico impulsados por IA expuestos a daños de reputación y fallos en la entrega. Un solo dominio mal configurado puede empañar la reputación de envío compartida de toda una flota de agentes autónomos.
Lo que reveló el escaneo
El conjunto de datos muestra tres estados de DMARC distintos:
- Aplicación (p=quarantine o reject) – 49,31 % de los dominios
- Monitoreo (p=none con reportes) – 25,61 %
- Inerte (p=none sin reportes) – 25,04 %
Los registros inertes, más de 117.000 de ellos, son marcadores de posición: una cadena de veinte caracteres que cumple con un requisito de cumplimiento pero no proporciona protección real. Lo que es peor, 166.442 dominios publican una política DMARC pero listan una dirección de reporte (RUA) que no funciona, lo que equivale a volar a ciegas.
El mes anterior al escaneo se observó un aumento en el número total de registros DMARC; sin embargo, la proporción que realmente aplica una política disminuyó. Aproximadamente tres cuartas partes de las nuevas entradas son etiquetas “p=none” que no hacen nada más allá de registrar logs.
Por qué esto importa a los agentes de IA
Los agentes heredan cualquier reputación que posea el dominio de envío. Si se añade un agente a un dominio con un registro SPF débil o una política DMARC inerte, cada mensaje saliente de la flota se suma a un mismo fondo de reputación compartida. Un dominio mal configurado puede causar rebotes, limitación de velocidad (throttling) o incluso la inclusión en listas negras para cada agente que lo utilice.
Los costes ocultos
- La pérdida de reputación se propaga instantáneamente entre todos los agentes que comparten el mismo dominio.
- Las caídas en la entregabilidad aumentan los tickets de soporte y erosionan la confianza del usuario.
- El riesgo de cumplimiento aumenta cuando las organizaciones no pueden demostrar que están monitoreando los intentos de suplantación (spoofing); no tener una dirección RUA funcional significa no tener datos forenses.
Cómo solucionarlo
- Valida la dirección de reporte – Ejecuta una consulta DNS para confirmar que la dirección RUA se resuelve y puede recibir reportes agregados. Sin visibilidad, no puedes reaccionar ante el abuso.
- Consume reportes en bruto – Obtén los reportes XML o JSON directamente durante al menos dos semanas. Los paneles de control de los proveedores suelen ocultar fallos o agregar datos de formas que esconden tendencias críticas.
- Limpia los "includes" de SPF – Elimina cualquier mecanismo de "include" que no puedas identificar explícitamente. Un registro SPF demasiado amplio invita a los suplantadores e infla el recuento de consultas DNS, con el riesgo de provocar un fallo total de SPF.
- Aísla a los agentes en un subdominio – Implementa un subdominio dedicado para el correo generado por IA, genera su propia clave DKIM y aplica una política DMARC estricta (p=reject). Este aislamiento limita cualquier error a un único espacio de nombres en lugar de afectar a la raíz corporativa.
Un comando rápido dig contra tu dominio antes de la próxima reunión de despliegue puede revelar entradas MX, SPF o DMARC faltantes que, de otro modo, pasarían desapercibidas en las revisiones de código.
Contrapunto
Los datos sugieren que esta postura cautelosa se vuelve perjudicial a escala: la mayoría de los nuevos registros permanecen inertes y la falta de aplicación deja el dominio expuesto al abuso. La transición del monitoreo a la aplicación es una prueba incremental, no un salto binario.
Idea clave
Los agentes de IA que envían correos electrónicos heredan el eslabón más débil de la cadena de autenticación de su dominio. Un registro DMARC inerte o una dirección de reporte rota pueden paralizar la entregabilidad y la reputación de toda una flota. Verifica, limpia y aísla tu infraestructura de correo electrónico ahora; de lo contrario, estarás construyendo sobre arena que se derrumbará en el momento en que ocurra un intento de suplantación.