Autenticación de correo explicada: SPF, DKIM y DMARC para defensores

El correo sigue siendo el vehículo de entrega número uno para phishing, compromiso de correo empresarial y malware, y casi todo depende de una sola debilidad: la dirección From: que ve el destinatario es trivial de falsificar salvo que publiques los registros de autenticación correctos. Este artículo está escrito para el blue team. Explica SPF, DKIM y DMARC desde un ángulo puramente defensivo: qué prueba cada control, cómo se entrelazan los tres, cómo leer la telemetría que producen y cómo llevar tu dominio a una política de aplicación sin romper el correo legítimo.

Por qué la suplantación de correo es tan fácil por defecto#

SMTP se diseñó en una era de confianza mutua y no tiene verificación de identidad incorporada. Cada mensaje tiene dos identidades de remitente: el remitente de sobre (el MAIL FROM usado en la transacción SMTP, también llamado Return-Path) y el From de cabecera que los clientes de correo realmente muestran. Un atacante puede fijar ambos a su antojo. Sin registros de autenticación, un servidor receptor no tiene base criptográfica ni de política para rechazar un mensaje que dice venir de tu dominio. Los tres estándares siguientes añaden esa base, cada uno cubriendo un hueco distinto.

SPF: autorizar la infraestructura de envío#

Sender Policy Framework (SPF) es un registro TXT de DNS que lista qué direcciones IP y hosts pueden enviar correo usando tu dominio en el remitente de sobre. Un receptor consulta v=spf1 ... para el dominio de sobre y comprueba si la IP conectante está autorizada. El registro termina con un mecanismo all: -all significa fallo duro (rechazar lo no listado), ~all fallo blando (aceptar pero marcar) y +all es peligroso y nunca debe usarse. SPF tiene dos límites importantes: valida el remitente de sobre, no el From visible, y se rompe al reenviar porque el reenviador se convierte en la nueva IP conectante. Además tiene un tope de diez consultas DNS, así que cadenas include: desmesuradas pueden llevar un registro a permerror en silencio.

DKIM: firmar el mensaje criptográficamente#

DomainKeys Identified Mail (DKIM) adjunta una firma digital a los mensajes salientes. Tu plataforma de correo firma cabeceras seleccionadas y el cuerpo con una clave privada; la clave pública correspondiente se publica en DNS en selector._domainkey.tudominio. Un receptor recalcula el hash y verifica la firma, probando que el contenido firmado no se alteró en tránsito y que lo firmó una clave que controla tu dominio. Como la firma viaja dentro del mensaje, DKIM sobrevive a la mayoría de reenvíos, a diferencia de SPF. Rota los selectores periódicamente, usa claves de al menos 2048 bits y retira los selectores antiguos para que una clave histórica filtrada no pueda abusarse.

DMARC: alineación, política e informes#

DMARC ata SPF y DKIM al From de cabecera que los usuarios realmente ven, mediante un concepto llamado alineación. Un mensaje pasa DMARC si pasa SPF y el dominio SPF se alinea con el From, o si pasa DKIM y el dominio DKIM se alinea: solo se requiere uno. La política DMARC es un registro TXT de DNS en _dmarc.tudominio con política p=none (solo monitorizar), p=quarantine (enviar a spam) o p=reject (rechazar). Es clave que DMARC también solicita informes: agregados XML vía rua= y, donde se ofrezcan, muestras forenses vía ruf=. Estos informes son tu telemetría principal de detección.

La superficie de ataque que estos controles abordan#

Entender contra qué te defiendes ayuda a afinar la política. La suplantación de dominio exacto falsifica tu propio dominio en el From y es precisamente lo que DMARC en aplicación detiene. Los dominios primos o parecidos (registrar un nombre visualmente similar) no están cubiertos por tu registro DMARC y requieren monitorización de marca y concienciación en su lugar. La suplantación de nombre visible mantiene una dirección legítima en el sobre pero fija un nombre engañoso, algo que la autenticación no puede atrapar y que necesita avisos en el cliente. Conocer estos límites evita una falsa sensación de seguridad una vez DMARC está en reject.

Detección: leer los informes agregados de DMARC#

Los informes agregados (RUA) llegan a diario como XML de cada receptor, resumiendo recuentos de mensajes agrupados por IP de origen, resultado SPF, resultado DKIM y disposición DMARC. Introdúcelos en un parser o panel gestionado en lugar de leer XML crudo. Vigila tres señales: IP de envío desconocidas que pasan o fallan por tu dominio (una herramienta de marketing que nadie mencionó, o un atacante), fuentes legítimas que fallan la alineación (un servicio que firma con el dominio equivocado) y picos de volumen hacia reject, que pueden indicar una campaña de suplantación activa. En tu gateway y SIEM, indexa la cabecera Authentication-Results para consultar dmarc=fail, dkim=fail y spf=softfail y alertar sobre suplantación de tus directivos.

Detección: señales de cabecera y de registros#

Más allá de los informes DMARC, los defensores deben establecer una línea base de los resultados normales de autenticación. En Microsoft 365, el seguimiento de mensajes y el valor compauth exponen decisiones de autenticación compuesta; en Google Workspace, los registros de correo en BigQuery y la Herramienta de Investigación de Seguridad muestran los veredictos SPF/DKIM/DMARC. Crea detecciones para correo entrante que falla DMARC pero dice venir de un dominio interno o socio, para la aparición súbita de un nuevo selector en tu propio DNS que no creaste, y para correo saliente de tu dominio que receptores externos reportan como fallido: lo último suele ser la primera señal de que un sistema de TI en la sombra o una cuenta comprometida envía en tu nombre.

Mitigación y endurecimiento: desplegar hasta la aplicación#

Despliega por fases para no descartar correo real. Primero, inventaría cada remitente legítimo: tu plataforma de correo, herramientas de marketing, sistemas de tickets, CRM y nóminas. Publica un registro SPF preciso terminado en -all, manteniéndote bajo el límite de diez consultas aplanando o eliminando includes sin uso. Habilita la firma DKIM en cada fuente con claves de 2048 bits y selectores únicos. Luego publica p=none con rua= y recoge informes unas semanas hasta que cada flujo legítimo muestre alineación exitosa. Pasa a p=quarantine con un pct bajo y sube hacia 100, y finalmente a p=reject. Fija sp=reject para subdominios y considera publicar un MX nulo y DMARC reject en dominios que no envían para que no puedan abusarse.

Controles complementarios: MTA-STS, TLS-RPT y BIMI#

La autenticación responde quién envió esto; la seguridad de transporte responde se entregó de forma privada. MTA-STS permite que tu dominio exija TLS para el SMTP entrante y resista ataques de degradación, y TLS-RPT reporta fallos de entrega. BIMI permite mostrar un logotipo de marca verificado, pero solo una vez estás en aplicación DMARC, lo que lo convierte en un incentivo útil para terminar el despliegue. Ninguno reemplaza a DMARC; endurecen las capas a su alrededor. Trátalos como la segunda ola tras estabilizar tu política de aplicación.

Errores comunes#

Los fallos más frecuentes son autoinfligidos. Publicar dos registros SPF causa un permerror e invalida SPF por completo: solo puedes tener uno. Exceder las diez consultas DNS rompe SPF en silencio para ecosistemas grandes. Saltar directo a p=reject sin periodo de monitorización descarta de forma fiable correo legítimo de un remitente olvidado. Olvidar la política de subdominio deja marketing.tudominio suplantable aunque el padre esté blindado. Y tratar ~all como equivalente a la aplicación es un error: fallo blando más p=none no detiene nada. Por último, no confíes en que los informes forenses ruf estén disponibles: muchos receptores ya no los envían por privacidad, así que construye tu detección sobre datos agregados.

Lista de endurecimiento#

Úsala como auditoría rápida. 1. Exactamente un registro SPF por dominio, terminado en -all, bajo diez consultas. 2. DKIM habilitado en cada fuente de envío, claves de 2048 bits, selectores rotados y antiguos retirados. 3. DMARC en p=reject con sp=reject y rua fluyendo a un buzón o plataforma monitorizados. 4. Dominios aparcados y sin envío bloqueados con SPF -all y DMARC reject. 5. El gateway de entrada indexa Authentication-Results y alerta sobre suplantación de directivos y fallos DMARC de dominio interno. 6. MTA-STS en modo enforce y TLS-RPT publicados. 7. Monitorización de dominios parecidos a la marca y formación de usuarios para ataques de nombre visible y parecidos que la autenticación no puede detener.

FAQ: ¿DMARC en reject detiene todo el phishing?#

No, y creerlo es peligroso. DMARC en reject impide que los atacantes falsifiquen tu dominio exacto en el From de cabecera, lo cual es una victoria grande y valiosa porque protege tu marca y a tus propios usuarios de suplantaciones de apariencia interna. No hace nada contra dominios parecidos, trucos de nombre visible, cuentas legítimas comprometidas o phishing desde dominios ajenos. Combina la aplicación con filtrado de entrada, protección de enlaces, reporte de usuarios y concienciación para que las técnicas restantes sigan siendo detectadas.

FAQ: ¿la aplicación romperá el reenvío y las listas de correo?#

Puede hacerlo, por eso importa DKIM. SPF se rompe con el reenvío simple porque el reenviador es una IP de origen nueva, pero una firma DKIM válida suele sobrevivir, así que un DKIM alineado mantiene el mensaje conforme a DMARC. Las listas que modifican el asunto o el cuerpo pueden romper DKIM; las listas bien configuradas lo mitigan con ARC (Authenticated Received Chain), que permite a un intermediario de confianza dar fe de la autenticación original. Monitoriza tus informes agregados en busca de fallos por reenvío durante el despliegue para incluir en lista blanca los intermediarios buenos conocidos antes de llegar a reject.

Conclusión#

SPF, DKIM y DMARC no son tres opciones que compiten; son tres capas que solo brindan protección cuando se combinan y se llevan a la aplicación. SPF autoriza infraestructura, DKIM prueba integridad y DMARC ata ambos al From visible y te da los informes que convierten la autenticación de correo en una capacidad de detección. El manual defensivo es directo: inventaría tus remitentes, publica registros precisos, monitoriza informes agregados hasta que cada flujo legítimo se alinee, y luego sube a reject con cobertura de subdominios. Haz eso, añade MTA-STS y monitorización encima, y cierras la puerta más fácil que usan los atacantes para suplantar a tu organización.