2.77 mil millones de dólares. Eso es lo que el FBI registró en pérdidas debido a Business Email Compromise solo en el año 2024, según el informe anual IC3. Una fracción de estos ataques tuvo éxito incluso cuando las organizaciones objetivo tenían DMARC en su lugar. No es una paradoja: DMARC solo protege contra una forma específica de suplantación, y los atacantes lo saben. Comprender sus límites exactos (los que el RFC 7489 documenta por sí mismo) es la condición para no sobreestimar su cobertura real.
Lo que DMARC hace (y nada más)
DMARC (Domain-based Message Authentication, Reporting and Conformance) es un protocolo que se basa en SPF y DKIM para dar instrucciones a los servidores de correo destinatarios: rechazar, poner en cuarentena o entregar los correos electrónicos cuya identidad de dominio no pueda ser verificada. Con una política p=reject, cualquier mensaje cuya cabecera From no coincida con una fuente SPF o DKIM autorizada será bloqueado. Esta protección es real. Pero su ámbito se limita estrictamente a la suplantación exacta del dominio. El RFC 7489 lo dice claramente: «DMARC no aborda el uso de nombres de dominio visualmente similares ni el abuso del nombre visible para los humanos». Cinco vectores de ataque comunes permanecen fuera de alcance.
El spoofing del display name le escapa por completo
Un correo electrónico cuya cabecera muestra «Servicio al Cliente Amazon <phishing@n0treal.com>» pasa DMARC sin problemas. DMARC solo verifica el dominio técnico del remitente, no el nombre mostrado en el cliente de correo. El atacante mantiene un nombre de remitente idéntico al de una marca de confianza mientras utiliza su propio dominio, correctamente autenticado. Para el usuario final, la línea «De:» muestra exactamente lo que el atacante ha decidido poner. Este vector no requiere ninguna infraestructura comprometida y elude todos los controles DMARC por definición: el dominio técnico no está suplantado, simplemente no está relacionado con el nombre mostrado.
Los dominios similares no están cubiertos
DMARC protege example.com. No dice nada sobre examp1e.com, example-support.com o example.fr. Estos dominios «similares» (typosquatting, dominios similares) pueden publicar su propio registro DMARC válido, con SPF y DKIM correctamente configurados, y enviar correos electrónicos perfectamente autenticados desde un dominio que se asemeja mucho al de una organización legítima. El problema está documentado por PowerDMARC: estos dominios «frecuentemente eluden el alcance de DMARC» porque el protocolo no tiene control sobre lo que no controla. La vigilancia de los dominios similares registrados es competencia de otras categorías de herramientas: monitoreo de marcas, vigilancia DNS, análisis de certificados SSL recientemente emitidos.
Una cuenta comprometida pasa DMARC sin alerta
Si un atacante accede a una cuenta de correo legítima mediante credential stuffing, phishing inicial o filtración de datos, todos sus mensajes salientes pasarán por SPF, DKIM y DMARC normalmente. El mensaje proviene del dominio correcto, firmado con la clave DKIM correcta, desde una IP autorizada. DMARC no distingue entre un empleado legítimo y un atacante que ha robado sus credenciales. Este es precisamente el modus operandi del BEC (Business Email Compromise): los 2.77 mil millones de dólares en pérdidas registradas por el FBI en 2024 se refieren a ataques donde la infraestructura de correo de las víctimas a menudo estaba correctamente configurada. DMARC no vio nada porque técnicamente no había nada que ver.
El reenvío de correos electrónicos puede romper la autenticación
Cuando un mensaje pasa por un servicio intermedio (alias de empresa, lista de correo como Mailman o Listserv, redirección automática), SPF casi siempre falla: la IP del relé no está listada en el registro SPF del dominio original. Si la lista de correo modifica el cuerpo del mensaje (pie de página añadido, descargo de responsabilidad insertado), DKIM también puede fallar. Correos electrónicos perfectamente legítimos terminan siendo rechazados o puestos en cuarentena. Según dmarcian, el 21 % de los fallos de DMARC observados en los informes agregados provienen de esta rotura de DKIM por modificación de contenido. La solución estándar es ARC (Authenticated Received Chain), pero requiere una configuración explícita del lado del relé. La mayoría de las listas de correo aún no lo han implementado.
Los subdominios pueden seguir siendo puntos ciegos
Un registro DMARC publicado en example.com no protege automáticamente todos sus subdominios. Por defecto, mail.example.com o newsletter.example.com heredan la política del dominio padre, a menos que exista un registro DMARC específico para ese subdominio, en cuyo caso prevalece, incluso si está en p=none. Un subdominio olvidado configurado para monitoreo anula la protección p=reject del dominio principal para ese ámbito. Valimail indica que más del 80 % de los dominios no tienen una política DMARC estricta; entre los que tienen una, la coherencia entre el dominio principal y los subdominios rara vez se verifica de manera sistemática. Los dominios «parking» no utilizados también siguen siendo superficies de suplantación disponibles.
DMARC en una estrategia realista
Estas cinco limitaciones no hacen que DMARC sea inútil. En noviembre de 2025, Gmail comenzó a rechazar los correos bulk no conformes, y Valimail estima que la aplicación de DMARC eliminó 265 mil millones de mensajes no autenticados en 2024. Es una base necesaria. Pero solo es una base. Una cobertura realista requiere además: una solución capaz de analizar el display name y detectar dominios similares, una protección contra el compromiso de cuentas (MFA obligatorio, detección de anomalías de comportamiento), una configuración ARC para los flujos legítimos de transferencia, y una auditoría regular de los subdominios incluyendo aquellos considerados como «inactivos». DMARC cierra una puerta. Antes de considerar el trabajo terminado, hay que contar las otras.
