← RFC Reference

DMARC — Autenticación, Informes y Conformidad Basados en Dominio

Por qué Existe Este RFC

SPF y DKIM son potentes, pero cada uno tiene una brecha crítica. SPF valida el dominio del remitente de la envoltura, que los usuarios nunca ven. DKIM valida cualquier dominio que el firmante haya elegido, que puede ser el dominio de un ESP en lugar del remitente visible. Ninguno de los dos, solo, impide que un atacante suplante el encabezado From: que los usuarios realmente leen.

DMARC cierra esta brecha introduciendo dos conceptos:

1. Alineación de identificadores: Al menos uno de SPF o DKIM debe pasar y su dominio autenticado debe alinearse con el dominio del encabezado From:.
2. Política del propietario del dominio: El propietario del dominio publica un registro DNS declarando qué deben hacer los receptores cuando la alineación falla: monitorear (p=none), cuarentena (p=quarantine), o rechazar (p=reject).

DMARC también define un mecanismo de informes agregados, permitiendo que los propietarios de dominios reciban informes XML diarios mostrando cómo su dominio está siendo utilizado (y abusado) en toda la internet.

Cómo Funciona

El Flujo de Evaluación DMARC

1. Un mensaje llega con From: user@example.com.
2. El receptor verifica SPF contra el dominio del remitente de la envoltura. Si SPF pasa y el dominio de la envoltura coincide con example.com (o un subdominio, dependiendo del modo de alineación), SPF está "alineado".
3. El receptor verifica DKIM. Si una firma válida tiene d=example.com (o un subdominio), DKIM está "alineado".
4. Si al menos uno de SPF o DKIM está pasando y alineado, DMARC pasa.
5. Si DMARC falla, el receptor consulta _dmarc.example.com por la política y la aplica.

Registro DNS DMARC

Alineación en la Práctica

Detalles Técnicos Clave

Etiquetas de Política

Modos de Alineación

Alineación relajada (por defecto, adkim=r / aspf=r): El dominio autenticado y el dominio From: comparten el mismo dominio organizacional. Por ejemplo, mail.example.com se alinea con example.com.

Alineación estricta (adkim=s / aspf=s): El dominio autenticado debe coincidir exactamente con el dominio From:. mail.example.com no se alinea con example.com.

Informes Agregados (rua)

Los receptores que soportan DMARC envían informes agregados diarios en formato XML a la dirección rua. Estos informes contienen:

• Las direcciones IP de envío que utilizaron su dominio
• Resultados de paso/fallo de SPF y DKIM para cada fuente
• La política DMARC aplicada y la disposición (ninguna, cuarentena, rechazo)
• Conteos de mensajes por dirección IP de origen

Estos informes son invaluables para descubrir remitentes no autorizados, identificar fuentes legítimas mal configuradas y construir confianza antes de endurecer su política de none a reject.

Verificación de Destino Externo

Si su dirección rua o ruf está en un dominio diferente (por ejemplo, rua=mailto:reports@analytics.com), el dominio receptor debe publicar un registro DNS autorizándolo:

Sin este registro, los remitentes de informes no entregarán informes a la dirección externa, como protección contra el uso de informes DMARC como vector de denegación de servicio.

Errores Comunes

• Pasar directamente a p=reject: Implementar una política de rechazo sin primero monitorear con p=none puede bloquear silenciosamente correo legítimo de fuentes olvidadas (plataformas de marketing, sistemas CRM, aplicaciones SaaS que envían en su nombre). Siempre comience con p=none, analice informes, corrija problemas de alineación, luego aumente.
• Olvidar política de subdominio: Sin sp=, los subdominios heredan la política del dominio. Si establece p=reject pero tiene un subdominio enviando correo sin autenticación adecuada, esos mensajes serán rechazados. Use sp= para controlar la política de subdominios independientemente.
• No configurar rua: DMARC sin informes agregados es volar a ciegas. Los informes le dicen quién está enviando correo como su dominio y si la autenticación está funcionando. Siempre configure rua.
• Malinterpretar alineación: Un error común es pensar que tener SPF y DKIM pasando es suficiente. También deben alinearse con el dominio del encabezado From:. Si su ESP usa bounce@esp.com como el remitente de envoltura y firma DKIM como d=esp.com, ninguno se alinea con su encabezado From:, y DMARC falla.
• Usar pct=0 como "solo monitoreo": Si bien pct=0 técnicamente significa "aplicar la política al 0% de fallos," algunos receptores lo interpretan diferentemente. Use p=none para monitoreo, no pct=0 con una política más estricta.
• Ruptura de lista de correo: Las listas de correo tradicionales reescriben el remitente de envoltura pero preservan el encabezado From:, rompiendo la alineación SPF e incluso DKIM (si la lista modifica el mensaje). Este es un problema conocido; ARC fue creado para abordarlo.

Impacto en Entrega

• Obligatorio para remitentes masivos: Desde febrero de 2024, Gmail requiere que los dominios que envían 5,000+ mensajes por día tengan una política DMARC (como mínimo p=none). Yahoo tiene requisitos similares. Esto hace que DMARC sea no opcional para cualquier remitente serio.
• Protección de marca: Una política p=reject impide que atacantes suplantan su dominio en campañas de phishing. Esto protege a sus clientes y la reputación de su dominio.
• Mejor colocación en bandeja de entrada: Los dominios con políticas DMARC fuertes (cuarentena o rechazo) demuestran madurez de autenticación. Muchos receptores factorizan esto en la puntuación de reputación.
• Elegibilidad BIMI: Brand Indicators for Message Identification (BIMI) requiere una política DMARC de p=quarantine o p=reject. BIMI muestra el logo de su marca al lado de mensajes en clientes de correo compatibles.
• Visibilidad en su ecosistema de correo: Los informes agregados revelan cada IP enviando correo como su dominio. Esta visibilidad sola hace que DMARC valga la pena implementar, incluso en p=none.

Related RFCs