21 Oct 20267 minutes read
Waseem OsmanEspecialista en DMARCGestión de registros TXT para aplicar DMARC a escala empresarial
Resumen:
- Los registros demasiado estrictos hacen fallar el correo legítimo, y los demasiado amplios pueden dejar que el correo de fuentes que ya no controla supere DMARC.
- Varios registros SPF o más de 10 consultas DNS producen un permerror, de modo que el correo solo supera DMARC mediante un DKIM alineado.
- Asigne la propiedad de los registros DNS a un equipo por responsabilidad y mantenga un registro de remitentes con todos los remitentes autorizados.
Las grandes empresas publican SPF, DKIM y DMARC como registros DNS en decenas o cientos de dominios, a veces sin un responsable identificado para cada uno. Cuando esos registros se desvían, el correo legítimo puede fallar la autenticación, la exposición a la suplantación continúa y los auditores pueden encontrar registros que nadie sabe explicar.
Una buena gestión de registros TXT reduce esa exposición. Esta guía explica de qué registros DNS depende la aplicación de DMARC, dónde falla la gestión de registros TXT en los entornos empresariales y cómo asignar la propiedad de los registros DNS para que se mantengan exactos a medida que cambian los remitentes.
Compruebe su registro DMARC actual con el verificador de registros DMARC gratuito de Sendmarc para confirmar que está publicado antes de seguir con el resto de esta guía.
Por qué la gestión de registros TXT es un riesgo para el negocio
SPF, DKIM y DMARC dependen todos de registros DNS. Una política DMARC se publica como un registro TXT en _dmarc.example.com, y los servidores receptores la leen al decidir cómo tratar el correo que falla la autenticación.
Una política p=none significa que un dominio está en modo de monitorización. El propietario del dominio recibe reportes, pero no expresa ninguna preferencia sobre lo que hacen los receptores con el correo que falla. Pasar a p=quarantine o p=reject es aplicación, y funciona como se espera solo cuando los registros DNS subyacentes son exactos.
Los registros inexactos crean riesgo en ambas direcciones. Los registros demasiado estrictos hacen que el correo legítimo de sus propios remitentes falle DMARC. Los registros demasiado amplios pueden dejar que el correo de fuentes que ya no controla supere DMARC.
Ambos resultados pueden generar hallazgos de auditoría difíciles de explicar a un comité de riesgos.
Los entornos distribuidos lo complican más. Los equipos de marketing, RR. HH., finanzas y producto gestionan cada uno sus propias herramientas de envío. Cuando un equipo incorpora un proveedor, aprovisiona un subdominio o cambia de plataforma, los registros DNS relacionados deben cambiar. Sin una gestión clara de los registros TXT, esos cambios a menudo no se hacen y se acumulan registros DNS obsoletos.
De qué registros DNS depende la aplicación de DMARC
Registro SPF. Publique un único registro TXT de SPF por dominio. Enumera todas las direcciones IP y servicios de envío autorizados a enviar correo en nombre de ese dominio. Para DMARC, un SPF superado cuenta solo cuando el dominio del remitente del sobre se alinea con el dominio "From".
Registros DKIM. Cada clave de firma se publica en el DNS en selector._domainkey.example.com. Publique un registro por cada plataforma activa. Para superar DMARC basta una sola comprobación alineada de SPF o DKIM, pero la RFC 9989 establece que los dominios que publican p=reject no deben depender únicamente de SPF y deben aplicar firmas DKIM válidas.
Registro DMARC. Publique un único registro TXT en _dmarc.example.com. Establece la versión, la política, la dirección de los reportes agregados (rua) y la política de subdominios (sp). Si un receptor encuentra más de un registro DMARC, la RFC 9989 exige que los descarte todos.
Los dominios que no envían correo también necesitan registros DNS. En los dominios aparcados, y en los dominios heredados o adquiridos que ya no envían correo, publique un registro DMARC con p=reject y un registro SPF de v=spf1 -all.
Fallos habituales de gestión de registros TXT a escala empresarial
Varios registros SPF en un mismo dominio
La RFC 7208 exige que los receptores devuelvan un permerror cuando un dominio publica más de un registro SPF. SPF no produce entonces ningún resultado favorable para ese dominio. Reúna todos los remitentes autorizados en un único registro.
| Host | Tipo | Valor |
|---|---|---|
@ | TXT | v=spf1 include:_spf.vendor-a.example include:_spf.vendor-b.example ip4:192.0.2.10 ~all |
Los duplicados aparecen cuando los equipos publican su propio registro SPF al incorporar una herramienta nueva.
Superar el límite de 10 consultas DNS
La evaluación de SPF permite un máximo de 10 consultas DNS. Los mecanismos include, a, mx y exists y el modificador redirect cuentan todos, incluidas las consultas dentro de includes anidados. Superar el límite produce un permerror, de modo que SPF no puede aportar un resultado favorable a DMARC. El correo solo supera entonces DMARC si DKIM está alineado.
Los registros SPF empresariales pueden sobrepasar el límite a medida que se acumulan con el tiempo los includes de remitentes de terceros. Elimine primero los remitentes retirados y después consolide el resto. El aplanamiento de SPF sustituye las cadenas de include por direcciones IP resueltas, pero requiere mantenimiento continuo porque los proveedores cambian sus rangos de IP.
Registros DNS obsoletos
Los registros DNS obsoletos son registros de remitentes que ya no utiliza. Importan por distintos motivos:
- Un
includede SPF obsoleto sigue autorizando a la infraestructura de ese proveedor a enviar como su dominio. La RFC 9989 aconseja revisar periódicamente los registros SPF para confirmar que se ajustan a las necesidades actuales. - Un selector DKIM obsoleto mantiene publicada una clave pública válida de una plataforma que ya no controla. Elimínelo cuando confirme que la plataforma ya no firma para su dominio.
- Los registros DNS obsoletos dificultan las auditorías porque los revisores no pueden saber qué entradas son intencionadas.
Cuando una plataforma de envío rota sus claves de firma, normalmente empieza a firmar con un nuevo par de claves bajo un nuevo selector. La clave pública correspondiente debe publicarse en el DNS antes de que empiece la firma.
Ajustes de alineación que rompen el correo legítimo
DMARC usa por defecto la alineación relajada, que solo exige que el dominio autenticado y el dominio "From" compartan el mismo dominio organizativo. La alineación estricta (aspf=s, adkim=s) exige que coincidan exactamente. La RFC 9989 señala que casi todos los propietarios de dominios consideran suficiente la alineación relajada.
Propiedad de los registros DNS en equipos distribuidos
Distintos equipos son propietarios de distintas partes de sus registros DNS. Marketing es responsable de su plataforma de envío, TI del DNS, seguridad de la política DMARC, y las entidades regionales pueden controlar sus propios subdominios. La RFC 9989 reconoce que las grandes empresas suelen delegar la gestión del DNS en departamentos locales.
Sin una propiedad definida de los registros DNS, los cambios de DNS se saltan la revisión de seguridad, los proveedores entran en producción antes de que existan sus registros SPF y DKIM, y la política DMARC se queda en p=none porque nadie tiene la autoridad para avanzarla.
Asigne cada responsabilidad a un equipo:
- Cambios de DNS: infraestructura o seguridad de TI aplica todos los cambios en los registros SPF, DKIM y DMARC
- Incorporación de remitentes: el equipo solicitante aporta el valor
includede SPF antes de que el remitente entre en producción - Reportes DMARC: seguridad revisa los reportes agregados y aprueba cada cambio de política
- Registro de remitentes: una lista mantenida de todos los remitentes autorizados por dominio, con su
includede SPF, su selector DKIM y el equipo responsable
El registro de remitentes es el resultado clave. Muestra a los auditores por qué existe cada entrada y da a los responsables del DNS una lista fija con la que contrastar las solicitudes, lo que acorta los ciclos de aprobación.
Lista de verificación de gestión de registros TXT para aplicar DMARC
Use esta lista de verificación como guía de implementación en entornos con varios dominios y como registro de auditoría.
- Inventaríe todos los dominios y subdominios. Incluya los dominios aparcados, heredados y adquiridos. Anote si cada dominio envía correo, recibe correo, ambas cosas o ninguna.
- Audite los registros DNS existentes. Confirme que cada dominio tiene un único registro SPF y cuente sus consultas con el verificador de registros SPF de Sendmarc. Enumere todos los selectores DKIM publicados y asócielos a un remitente activo. Confirme que el buzón de
ruarecibe reportes. - Asigne la propiedad de los registros DNS. Designe a un responsable de cambios de DNS para cada dominio y exija una solicitud de cambio para cada actualización de SPF, DKIM o DMARC.
- Avance la política DMARC por etapas. Empiece en p=none con una dirección
ruay use los reportes agregados para identificar a todos los remitentes legítimos. Corrija los flujos de correo no alineados y luego pase a p=quarantine y p=reject. - Fije un calendario de revisión. Revise los registros SPF cada vez que se añada o retire un remitente. Revise las claves DKIM tras cada rotación y según un calendario fijo. Revise los reportes agregados con regularidad y audite todos los registros DNS en busca de entradas obsoletas al menos una vez al año.
Cómo puede ayudar Sendmarc
Los equipos de seguridad y TI que ya van justos no pueden auditar a mano los registros DNS de decenas de dominios, y las unidades de negocio siguen añadiendo remitentes que nadie aprobó.
Sendmarc identifica a los remitentes legítimos y no autorizados en todos los departamentos, incluida la TI en la sombra que rompe la autenticación, y detecta las configuraciones erróneas antes de que se conviertan en incidentes. La plataforma de Sendmarc centraliza la gestión de SPF, DKIM y DMARC entre departamentos, regiones y dominios.
Para los auditores y los consejos, los reportes listos para auditoría aportan evidencia verificable del estado de aplicación. Esto respalda la alineación con marcos como PCI DSS, GDPR, POPIA, ISO y NIST.
El equipo de implementación de Sendmarc lleva a los clientes de p=none a p=reject por etapas, con una aplicación de p=reject garantizada. La monitorización y la optimización continúan tras la aplicación, para que la protección siga al día a medida que cambia su entorno.
Explore la gestión de DMARC para ver cómo funcionan la visibilidad de remitentes y el mantenimiento de registros en todo su parque de dominios.
