Artículo de blog

Descripción general del registro DMARC :
_dmarc.yourdomain.com y requiere dos etiquetas: v=DMARC1 y p=Un registroDMARC indica a los servidores receptores qué hacer con los correos electrónicos que no superan la autenticación: si deben entregarlos, ponerlos en cuarentena o rechazarlos directamente. Sin él, cualquiera puede enviar correos electrónicos que parezcan proceder de tu dominio.
DMARC en SPF DKIM. Ambos deben estar configurados y funcionando correctamente antes de crear un DMARC . Si DKIM o no funcionan correctamente tanto SPF DKIM , pasar a la fase de aplicación interrumpirá la entrega de los correos electrónicos legítimos.
Esta guía aborda la sintaxis DMARC , las definiciones de las etiquetas, un ejemplo práctico y cómo publicar y verificar el registro. Si DMARC primera vez DMARC configuras DMARC , esta es la guía de referencia por la que debes empezar.
Una nota importante antes de empezar: al publicar un registro DMARC con p=none no impide la suplantación de identidad. Lo que hace es iniciar la supervisión. La protección llega más tarde, una vez que revises reporte y pases a p=reject.
Se ha publicado un registro DMARC en _dmarc.yourdomain.com – no el dominio raíz.
Aquí tienes un ejemplo mínimo que funciona:
| Host | Tipo | Valor |
|---|---|---|
_dmarc.yourdomain.com | TXT | v=DMARC1; p=reject; |
Todo registro DMARC válido incluye dos elementos:
v=DMARC1: El identificador de versiónp=: La política aplicada al dominio (ninguna, cuarentena o rechazo)Todo lo demás es opcional. Empieza por estos dos.
Entender la sintaxis DMARC marca la diferencia entre un registro que funciona y otro que interfiere en el correo electrónico legítimo. Cada etiqueta controla una función específica; a continuación te explicamos para qué sirven.
| Etiqueta | Propósito |
|---|---|
v=DMARC1 | Identificador de versión. Siempre es la primera etiqueta. No hay alternativas. |
p= | Política relativa al dominio. |
| Etiqueta | Propósito |
|---|---|
ruf= | Informes de «Destination for failure» (RUF). Se generan para cada mensaje que no supera la validación DMARC. |
sp= | Política de subdominios. Anulaciones p= para subdominios. Resulta útil cuando las fuentes de envío de los subdominios no se han asignado por completo. |
adkim= | Modo de DKIM . r (flexible, por defecto) o s (estricto). La opción «estricto» requiere una coincidencia exacta del dominio. |
aspf= | Modo de SPF . r (flexible, por defecto) o s (estricto). Tiene las mismas implicaciones que adkim=. |
fo= | reporte forenses. Determina qué fallos generan informes RUF. fo=1 genera un reporte DKIM SPF DKIM ; se recomienda esta opción en lugar de la predeterminada fo=0. |
Acerca de los modos de alineación: No utilizar alineación estricta (adkim=s o aspf=s) por defecto. La alineación estricta no admite coincidencias flexibles y rechazará o pondrá en cuarentena correos electrónicos legítimos procedentes de subdominios y remitentes externos. Se trata de una configuración avanzada adecuada para entornos específicos.
DMARC si SPF DKIM alineación; sin embargo, debes tener ambos configurados antes de pasar a la fase de aplicación. Un remitente que dependa de solo mecanismo no dispone de una alternativa en caso de que dicho mecanismo falle. Comprueba que SPF todas tus fuentes de envío y que DKIM los correos electrónicos salientes antes de crear el registro DMARC .
Empieza con p=none. Esto genera informes agregados sin afectar al envío de correos electrónicos. No comiences con p=quarantine ni p=reject antes de revisar reporte . Necesitas tener una visión clara de la situación antes de tomar medidas.
Configurar rua= a un buzón de correo que controles o a unreporte DMARC . Los informes agregados se reciben a diario y constituyen la herramienta principal para realizar un mapeo de tu infraestructura de envío: todas las fuentes que envían correo electrónico en nombre de tu dominio aparecerán en estos informes.
Combina las etiquetas necesarias en un único valor de registro TXT.
Para una nueva implementación:
| Host | Tipo | Valor |
|---|---|---|
_dmarc.yourdomain.com | TXT | v=DMARC1; p=reject; rua=mailto:[email protected]; |
Crea el registro DMARC en _dmarc.yourdomain.com en tu consola de gestión de DNS. Lo habitual es un TTL de 3.600 segundos (una hora).
Utiliza una herramienta de consulta de DNS para comprobar que el registro está activo y tiene el formato correcto.
DMARC si SPF DKIM válidos y están alineados con el dominio «From». Sin embargo, si ninguno de los dos está configurado correctamente, todos los mensajes fallan, y en el caso de p=quarantine o p=reject, eso significa que los correos legítimos van a parar a la carpeta de spam o se bloquean directamente.
Sin informes agregados, no se puede saber qué pasa la prueba y qué no. La fase de supervisión solo resulta solo si se toman medidas en función de los datos.
Una configuración demasiado estricta puede hacer que los correos electrónicos legítimos procedentes de subdominios y remitentes externos no superen DMARC. Empieza con la configuración «relaxed»: es la predeterminada por una razón.
Los subdominios que no tienen un sp= La etiqueta hereda la política de dominio de la organización. Los subdominios utilizados para el envío deben someterse a su propio proceso de verificación de autenticación.
La creación de un registro DMARC marca el inicio del proceso. No lo concluye. El registro genera datos, y esos datos deben revisarse, interpretarse y dar lugar a medidas concretas.
Los informes agregados son archivos XML legibles por máquina. En el caso de un único dominio con un volumen reducido, la revisión manual resulta factible. A medida que crecen las carteras de dominios y la infraestructura de envío, el volumen de reporte y el número de fuentes que hay que supervisar superan la capacidad de gestión de los equipos sin el uso de herramientas.
Para las empresas que gestionan varios dominios, entornos de envío distribuidos o deben cumplir con requisitos de cumplimiento normativo, DMARC manual DMARC genera lagunas: se pasan por alto algunas fuentes, se ignoran subdominios y la aplicación de las medidas se estanca porque nadie puede confirmar qué sigue fallando y por qué.
Los equipos que ya están al límite de su capacidad no pueden asumir esa carga de trabajo, y el registro de auditoría necesario para dar respuesta a los comités de riesgos y a los organismos reguladores no se genera por sí solo.
La visibilidad debe ser continua. Las configuraciones de autenticación cambian cuando se incorporan nuevas herramientas, se actualizan los registros DNS o los remitentes externos modifican su infraestructura. Un registro DMARC que era correcto en el momento de su puesta en marcha puede que ya no refleje la realidad seis meses después.
Un registro DMARC es el punto de partida. Al pasar de p=none a p=reject —y mantenerlo así— requiere una visibilidad continua de todas las fuentes de envío, dominios y subdominios.
DMARC de Sendmarc proporciona a los equipos de seguridad y de TI lo que necesitan para alcanzar y mantener una aplicación plena de las políticas:
Descubre cómo Sendmarc simplifica DMARC a gran escala.