La «deuda de seguridad del correo electrónico»: la métrica de ciberseguridad que nadie mide

Todo equipo de seguridad presenta unas cifras con total confianza: intentos de phishing bloqueados, detecciones de malware, intentos fallidos de inicio de sesión, credenciales expuestas, tiempo medio de respuesta. Lo que casi nadie menciona es el trabajo que se suponía que debía estar terminado hace meses y que no deja de posponerse al siguiente sprint.

Ese retraso tiene un nombre que vale la pena utilizar: deuda de seguridad del correo electrónico : los problemas sin resolver de autenticación, propiedad y configuración que se acumulan en toda tu infraestructura de correo electrónico y cuya resolución resulta cada vez más costosa a medida que tu organización crece en torno a ellos.

El correo electrónico es especialmente eficaz a la hora de acumularlos. Una nueva plataforma SaaS empieza a enviar mensajes en tu nombre. Se modifica un registro DNS durante una migración. Un subdominio «temporal» sigue activo. Un proveedor sigue enviando datos de acceso mucho después de que el proyecto haya finalizado. Por sí solo, cada uno de estos casos parece una solución de cinco minutos.

Cómo es realmente la «deuda de seguridad del correo electrónico»

El concepto se inspira en la «deuda técnica» del desarrollo de software. Se toma un atajo para resolver el problema actual y se le deja la factura del mantenimiento a tu yo futuro.

Los sistemas de correo electrónico acumulan rápidamente esos atajos, ya que la infraestructura de envío casi nunca pertenece a un único equipo. El departamento de marketing gestiona la plataforma de campañas. El departamento de RR. HH. se encarga de la herramienta de selección de personal. El departamento de asistencia técnica gestiona el sistema de tickets. Los desarrolladores conectan dos o tres API de correo electrónico transaccional. Al departamento de TI le queda la tarea de mantener los registros DNS que lo mantienen todo unido.

Síntomas típicos:

• Servicios de envío desconocidos que siguen utilizando tu dominio;
• Mecanismos del SPF que quedaron pendientes tras una migración que finalizó hace dos años;
• Claves DKIM que apuntan a servicios que ya nadie utiliza;
• Políticas DMARC en modo de supervisión sin un propietario claro;
• Subdominios temporales que nunca se volvieron a revisar;
• Proveedores externos que conservan el acceso para el envío de mensajes una vez finalizado su contrato.

Ninguno de ellos provoca un incidente el mismo día en que aparece. Precisamente por eso sobreviven.

La autenticación se vuelve cada vez más complicada con el paso del tiempo

Configurar SPF, DKIM y DMARC en un dominio nuevo es realmente sencillo. Lo difícil es mantener los tres correctamente configurados a lo largo de los años, a pesar de los cambios en la infraestructura.

Tomemos como ejemplo el SPF. Empiezas con Google Workspace y un proveedor de marketing. Luego, el departamento de ventas añade una plataforma, el de selección de personal cuenta con su propio sistema y el de ingeniería integra una API de correo electrónico. El registro crece, pero las entradas antiguas rara vez se eliminan al mismo ritmo, y así es como los dominios acaban alcanzando los límites de consultas, publicando registros SPF duplicadoso sufriendo fallos de SPF que nadie puede explicar. Conseguir la sintaxis del SPF correcta una vez es fácil; mantenerla correcta es cuestión de mantenimiento.

DKIM sigue el mismo ciclo de vida. Las claves pertenecen a remitentes específicos, y los remitentes cambian. Un selector publicado puede seguir siendo técnicamente válido mucho tiempo después de que el servicio al que corresponde haya dejado de formar parte de las operaciones diarias, y DKIM empieza a fallar por motivos que se remontan a un ticket de 2023.

Aquí es donde los informes DMARC cobran toda su importancia. Los informes agregados muestran qué sistemas están enviando realmente correo como si fueran tu dominio, y no cuáles crees tú que lo están haciendo. Al leer esos informes convierte las desviaciones invisibles en una lista que puedes revisar, y PowerDMARC te ofrece visibilidad de DMARC, SPF y DKIM en una sola vista, en lugar de obligar a tu equipo a tratar cada registro como una tarea aislada relacionada con el DNS.

Eso cambia el enfoque de la pregunta. «¿Está activado DMARC?» no es una pregunta útil. La pregunta útil es: «¿Conocemos todos los servicios que actualmente envían mensajes en nombre de nuestro dominio, y cada uno de ellos sigue perteneciendo a ese dominio?».

El problema del remitente olvidado

Existe cierta «deuda de seguridad» en el correo electrónico incluso cuando todos los registros son técnicamente correctos.

Imagina una plataforma de seminarios web autorizada hace dos años. El empleado que la configuró ya no trabaja en la empresa. No se ha accedido a la cuenta desde hace meses. Aún así, puede enviar correos electrónicos autenticados a través de tu dominio corporativo.

Desde el punto de vista de un atacante, «antiguo» no significa «inofensivo». Una cuenta olvidada es una vía de acceso fiable a tu entorno de correo electrónico que nadie vigila.

Una revisión adecuada del remitente responde a seis preguntas prácticas:

• ¿Qué sistema está enviando este correo?
• ¿A qué equipo pertenece la cuenta?
• ¿Qué dominio o subdominio utiliza?
• ¿Cumple con la validación de SPF y DKIM?
• ¿Cuándo se utilizó por última vez de forma legítima?
• ¿Quién tiene la autoridad para retirarlo?

Esa última pregunta suele provocar más retrasos que toda la investigación técnica en su conjunto. Identificar un remitente innecesario lleva unos minutos. Conseguir la autorización para desactivarlo puede llevar semanas.

La autenticación del correo electrónico no cubre todo el ataque

Se produce otro tipo de problema cuando una empresa espera que una medida de control resuelva un problema que queda fuera de su ámbito de competencia.

DMARC, cuando se aplica de forma estricta, dificulta enormemente la suplantación directa de dominios. No bloquea todos los mensajes de phishing. Los atacantes recurren a dominios similares, cuentas de terceros comprometidas, archivos adjuntos maliciosos y páginas convincentes para el robo de credenciales.

En ese momento, el problema ya va más allá de la autenticación del remitente. Una vez que un archivo o enlace malicioso llega al dispositivo de un usuario, hay que confiar en la detección en los puntos finales, la protección del navegador, el filtrado de URL o un solución antivirus de última generación para detectar lo que ha logrado colarse.

Esa división de responsabilidades es más importante de lo que normalmente se reconoce. Una organización puede aplicar estrictamente las políticas de DMARC y, aun así, dejar a los usuarios expuestos en el momento en que hacen clic. Otra puede realizar una importante inversión en herramientas para terminales, mientras que una docena de servicios olvidados siguen estando autorizados a enviar correo de confianza desde su dominio. La deuda de seguridad del correo electrónico suele residir en el vacío que existe entre ambos casos.

¿Por qué esto rara vez aparece en un panel de control?

No existe una unidad de medida estándar para la «deuda de seguridad» del correo electrónico, lo que hace que sea mucho más difícil cuantificarla que, por ejemplo, la tasa de clics en mensajes de phishing o la cifra del MTTR.

Una diapositiva trimestral podría mostrar que el 98 % del correo legítimo supera la autenticación. Es tranquilizador, pero no dice nada sobre las cuatro cuentas SaaS abandonadas que aún pueden enviar mensajes autenticados. Del mismo modo, al alcanzar p=rechazo en tu dominio principal no significa que el entorno en general esté limpio. Los subdominios, los remitentes de terceros y los fallos de DMARC sin resolver quedan todos fuera de esa cifra principal.

Un panel de control más honesto hace un seguimiento de los asuntos pendientes, no solo de los que se han resuelto con éxito:

• Remitentes no identificados;
• Servicios autorizados sin titular activo;
• Los fallos de autenticación siguen sin investigarse;
• Las plataformas inactivas siguen teniendo permiso para enviar;
• Dominios que permanecen en modo de supervisión más allá del plazo acordado.

La antigüedad también debe figurar en ese panel de control. Un remitente detectado ayer es motivo de investigación. El mismo remitente que sigue sin resolverse nueve meses después es una deuda.

Asigna un ciclo de vida a cada excepción

Los programas de seguridad del correo electrónico rara vez se atascan por motivos graves. Se atascan por excepciones temporales, hojas de cálculo obsoletas, incidencias abandonadas y registros que nadie quiere tocar porque no está claro a quién corresponden.

La solución no tiene nada de espectacular: cada remitente sin resolver o cada excepción de autenticación se asigna a un responsable, se le atribuye un motivo documentado y se le fija una fecha de revisión. Ese único cambio hace que la infraestructura descuidada vuelva a ser visible.

Puedes empezar por lo que ya está publicado. Comprueba tu configuración actual y analiza tu dominio con un analizador de dominiosy, a continuación, utiliza los informes DMARC para comparar lo que está autorizado con lo que realmente se está enviando.

Este indicador nunca será totalmente objetivo, ni es necesario que lo sea. Su valor es práctico. Los remitentes antiguos, los registros obsoletos, las implementaciones de DMARC a medias y las lagunas entre la protección del correo electrónico y la de los terminales dejan de ser solo «ruido de fondo» y pasan a ser tareas a las que puedes dar prioridad. Ese es precisamente el objetivo de definir la «deuda de seguridad del correo electrónico»: lo que se mide, se programa.

PREGUNTAS FRECUENTES

¿Qué es la deuda de seguridad del correo electrónico? La deuda de seguridad del correo electrónico es la acumulación de problemas sin resolver relacionados con la autenticación, la propiedad y la configuración en la infraestructura de correo electrónico de una organización: mecanismos SPF obsoletos, claves DKIM de servicios inactivos, políticas DMARC estancadas en modo de supervisión y remitentes de terceros de los que nadie se hace responsable ni revisa.

¿Cómo se mide la deuda de seguridad del correo electrónico? Haz un seguimiento de los elementos sin resolver, en lugar de los resueltos: remitentes no identificados, servicios autorizados sin propietario, fallos de autenticación no investigados, plataformas inactivas a las que aún se les permite enviar mensajes y dominios que permanecen en modo de supervisión más allá de un plazo acordado. Suma la antigüedad de cada elemento, ya que el tiempo que algo lleva sin resolverse es lo que distingue una investigación abierta de una deuda real.

¿Alcanzar el nivel «p=reject» en DMARC significa que no tienes ninguna deuda de seguridad en el correo electrónico? No. La aplicación de la política en tu dominio principal impide la suplantación directa de ese dominio, pero los subdominios, los servicios de envío de terceros y los fallos de autenticación sin resolver pueden seguir sin gestionarse, a pesar de que la métrica principal parezca correcta.

• Acerca de
• Últimas publicaciones

Ahona Rudra

Experto en seguridad de dominios y correo electrónico en PowerDMARC

Ahona es la Directora de Marketing de PowerDMARC, con más de 5 años de experiencia escribiendo sobre temas de ciberseguridad, especializada en seguridad de dominios y correo electrónico. Ahona tiene un posgrado en Periodismo y Comunicaciones, consolidando su carrera en el sector de la seguridad desde 2019.

Últimas publicaciones de Ahona Rudra (ver todas)

• Correos electrónicos de phishing generados por IA: cómo verificar los correos redactados por IA antes de confiar en ellos - 31 de agosto de 2026
• La deuda de seguridad del correo electrónico: la métrica de ciberseguridad que nadie mide - 31 de agosto de 2026
• PowerDMARC, nombrado líder en software DMARC por decimotercer trimestre consecutivo - 28 de agosto de 2026