Guía de política DMARC: Una guía completa para la implementación, configuración y supervisión

Nota sobre la fuente y la precisión

Esta guía se basa principalmente en las especificaciones del protocolo: RFC 7489, RFC 7208, RFC 6376, RFC 8301, RFC 8463, RFC 8601, RFC 8617, RFC 8461, RFC 8460, RFC 7960, así como RFC 8553 y RFC 8616, donde actualizan o afectan a la RFC 7489, complementadas con la documentación operativa actual de Microsoft, Google y Yahoo, y por el trabajo activo en el grupo de trabajo DMARC de la IETF, DMARCbis. DMARC es un protocolo de asesoramiento de políticas: expresa la preferencia del propietario del dominio, pero el sistema de recepción de correo decide qué hacer con un mensaje fallido. El comportamiento del proveedor puede cambiar, a veces sin previo aviso. Los ejemplos de DNS en este artículo utilizan nombres de marcador de estilo de ejemplo reservados. Reemplace cada dominio de política, dominio de informe, selector y registro de autorización externo con valores controlados por su organización o procesador de informes. Antes de aplicar cualquier configuración descrita aquí a un dominio de producción, valídela mediante una implementación gradual, normalmente p=none con informes agregados, y nunca publique p=reject hasta que los informes agregados confirmen que sus fuentes de correo legítimas están alineadas.

Introducción: ¿por qué SMTP permite el «spoofing»?

SMTP, definido originalmente en RFC 821 (1982) y modernizado en RFC 5321, fue diseñado para una pequeña red de investigación de confianza mutua. No realiza ninguna autenticación del remitente a nivel de protocolo. Un servidor de correo que se conecta puede presentar cualquier valor y cualquier dirección que desee en el comando MAIL FROM y en el encabezado From:. El MTA receptor no tiene ninguna forma incorporada de verificar ninguno de los dos.

De hecho, el correo electrónico tiene tres identidades «desde», y confundirlas es la raíz de la mayoría de los «spoofing»:

• El remitente del sobre (también conocido como MAIL FROM, Return-Path o RFC 5321.MailFrom). Esta es la dirección utilizada durante la transacción SMTP y donde se envían los mensajes rechazados. El destinatario normalmente nunca la ve.
• Encabezado: Desde (RFC 5322.De). Esto es el campo visible. From: la línea que los clientes de correo muestran al usuario.
• El dominio de firma DKIM (la d= etiqueta dentro del encabezado DKIM-Signature). Este es el dominio cuyo certificado firmó el mensaje, y puede ser diferente tanto de las direcciones anteriores como de las direcciones mencionadas.

Un mensaje de phishing puede poner billing@bank.example.com visible From: al utilizar bounce@attacker.example.net como el remitente de la sobre. SPF, en la evaluación habitual de MAIL FROM relevante para DMARC, valida al remitente de la sobre, en lugar del remitente visible. SPF también puede evaluar HELO/EHLO, pero eso no es la identidad visible para el usuario. DKIM, por sí solo, solo valida el dominio que haya firmado el mensaje. Ninguno protege la identidad que el usuario realmente ve en su cliente de correo electrónico, a menos que la identidad autenticada coincida con el dominio visible bajo DMARC.

DMARC fue definido en la RFC 7489 en marzo de 2015 con estado informativo, publicado a través del flujo de envío independiente del RFC Editor, en lugar de como resultado de un grupo de trabajo de la IETF. DMARCbis es la revisión del protocolo de la IETF DMARC Working Group que cumple con los estándares, que es la primera especificación de DMARC del flujo de la IETF, y no una «promoción» de un documento existente de la IETF. DMARC vincula los resultados de SPF y DKIM al dominio visible «From» a través de un concepto llamado alineación, y permite al propietario del dominio publicar una política en DNS que indique a los destinatarios qué hacer cuando ninguno de los mecanismos de alineación funciona. DMARC no es una capa anti-phishing mágica: no hace nada con dominios similares, ataques con caracteres homófonos, ni mensajes enviados desde cuentas comprometidas que autentican normalmente, y no garantiza que los mensajes lleguen a la bandeja de entrada. Lo que DMARC proporciona es la validación de que el uso del dominio «From» visible fue autorizado para un mensaje que funciona, además de un canal de retroalimentación para que los propietarios de los dominios puedan ver quién está enviando correos en su nombre. No es un veredicto sobre si el contenido del mensaje, la intención del remitente o la cuenta de correo electrónico son de confianza.

Roles de SPF, DKIM y DMARC

Los tres protocolos están relacionados pero son independientes. Cada uno responde a una pregunta diferente.

SPF puede evaluar tanto las identidades HELO/EHLO como MAIL FROM. DMARC utiliza el resultado de SPF para la identidad RFC5321.MailFrom. Cuando MAIL FROM está vacía, SPF define la identidad MAIL FROM verificada como una derivada de HELO. postmaster@<helo-domain> identidad; este es el caso del mensaje de «bounce», y no el uso independiente de DMARC con resultados HELO arbitrarios.

DKIM normalmente protege las cabeceras firmadas y el hash del cuerpo, pero el alcance exacto depende de la firma. La etiqueta DKIM l= de longitud de cuerpo, que se utiliza raramente, puede firmar intencionalmente solo la primera parte del cuerpo, por lo que la redacción operativa más segura es inspeccionar la cabecera real DKIM-Signature y la decisión del destinatario, en lugar de asumir que cada byte de un mensaje entregado ha sido firmado.

Un mensaje puede pasar SPF y aún así fallar en DMARC. Si el remitente del sobre es bounce.esp-mailer.example pero el «From» visible es noreply@example.com, SPF autentifica la identidad incorrecta desde la perspectiva de DMARC. Lo mismo se aplica a DKIM: una firma con d=esp-mailer.example verifica criptográficamente, pero el dominio de firma no coincide con el dominio visible de «From», por lo que DKIM falla.

La cabecera Authentication-Results, definida en RFC 8601, es la herramienta principal para la resolución de problemas. Los servidores de correo que realizan la autenticación suelen incluir una de estas cabeceras en el mensaje entregado, resumiendo los resultados de SPF, DKIM y DMARC, así como las identidades utilizadas para calcularlos. Cuando un mensaje llega a la carpeta de correo no deseado o es rechazado, esta cabecera suele contener la respuesta. Al solucionar problemas, confíe únicamente en la cabecera Authentication-Results añadida por su propio MTA de borde o por el sistema receptor final que está analizando: las cabeceras Authentication-Results de saltos upstream no confiables pueden ser falsas o obsoletas, y RFC 8601 §5 describe por qué los sistemas de borde deben eliminar o ignorar los campos Authentication-Results upstream no autenticados.

Cómo funciona DMARC paso a paso

En lenguaje sencillo: el destinatario busca el dominio «From» visible en DNS, encuentra una política DMARC si existe, comprueba si SPF o DKIM han pasado de una manera que se relaciona con el dominio «From» visible, y luego aplica la política publicada si ninguno de los mecanismos alineados ha pasado.

La evaluación técnica, según RFC 7489 §6, procede aproximadamente de la siguiente manera:

1. El destinatario extrae el dominio del encabezado RFC 5322.From.
2. El destinatario consulta _dmarc.<domain> para un registro TXT. Si no se encuentra ninguno, consulta el mismo nombre en el dominio de la organización (derivado en RFC 7489 utilizando la Public Suffix List). Bajo DMARCbis, el fallo de la Public Suffix List se reemplaza por un recorrido DNS limitado; el comportamiento de la Public Suffix List de RFC 7489 sigue siendo la realidad implementada en muchos destinatarios hasta que se publique y adopte DMARCbis.
3. El destinatario evalúa SPF en el remitente del sobre del mensaje y registra el resultado.
4. El receptor evalúa cada firma DKIM del mensaje y registra cada resultado.
5. El receptor prueba la alineación de SPF: ¿coincide el dominio del remitente del sobre con el dominio «From», según el modo aspf de la política?
6. El receptor prueba la alineación de DKIM: ¿coincide el valor de la firma d= de cualquier firma verificada con el dominio «From», según el modo adkim de la política?
7. DMARC se considera exitoso si tanto la alineación de SPF como la alineación de DKIM son correctas.
8. Si DMARC falla, el receptor consulta la política publicada (p= o sp= para subdominios).
9. El receptor puede aplicar none, quarantine o reject, opcionalmente muestreando con pct.
10. La política local en el receptor – sistemas de reputación, listas blancas, confianza ARC, filtrado de contenido – pueden anular o complementar el manejo solicitado.

El paso 10 es esencial y suele malinterpretarse. La política DMARC es una solicitud, no una orden. El receptor puede respetarla, ignorarla, enviar el mensaje a spam de todos modos o aplicar puntuaciones adicionales basadas en aprendizaje automático. Microsoft 365, Google Workspace y los grandes proveedores de correo para particulares aplican sus propias políticas locales por encima de DMARC. DMARCbis §5.4 refuerza este enfoque al indicar que los receptores de correo NO DEBERÍAN (SHOULD NOT) rechazar mensajes entrantes únicamente por una política p=reject publicada. Los apartados posteriores sobre el tratamiento por parte del receptor y la conformidad utilizan una regla más estricta: los receptores de correo NO DEBEN (MUST NOT) rechazar mensajes entrantes únicamente por una política p=reject publicada. En ausencia de otros datos y análisis, se espera que traten los mensajes que no superen la comprobación como si se aplicara p=quarantine.

Alineación relajada vs estricta

La alineación es lo que diferencia a DMARC de SPF y DKIM. Existen dos modos, controlados por separado para SPF (aspf) y DKIM (adkim). La configuración predeterminada para ambos es relajada.

• La alineación relajada requiere que los dos dominios compartan el mismo dominio organizacional. mail.example.com se alinea con example.com.
• Un ajuste preciso requiere una coincidencia exacta del dominio. mail.example.com no se ajustaexample.com.

Considere un mensaje con From: billing@example.com y estas posibles identidades de autenticación:

El alineamiento estricto puede ser apropiado ocasionalmente para dominios de transacciones de alto valor (correo electrónico de ejecutivos, notificaciones de pago), pero comúnmente interfiere con el correo electrónico legítimo cuando un proveedor de servicios de correo electrónico (ESP) o un reenvío se autentican con un subdominio o su propio dominio. Comience con la configuración flexible y solo restríguela después de que los informes demuestren que su infraestructura de envío puede soportarla.

Escenarios de éxito y fallo de DMARC

DMARC requiere al menos un paso de autenticación compatible. SPF y DKIM no necesitan pasar por sí mismos bajo el protocolo DMARC, pero un paso no compatible no ayuda a DMARC. Los requisitos específicos del proveedor pueden ser más estrictos; los requisitos de Microsoft para el envío de correo electrónico a gran escala a consumidores, que se discuten a continuación, requieren que tanto SPF como DKIM pasen, y al menos un mecanismo compatible para la validación de DMARC.

Lectura de los encabezados Authentication-Results

Al solucionar problemas, lea el encabezado del receptor: Authentication-Results. Un mensaje exitoso podría verse así:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce.example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Un mensaje que pasa la verificación SPF pero falla en DMARC, porque la verificación SPF no está alineada, podría verse así:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=esp-mailer.example;
  dkim=fail header.d=example.com;
  dmarc=fail header.from=example.com

La sintaxis exacta varía según el receptor, pero la pregunta operativa suele ser la misma: ¿qué dominio ha superado la verificación, y ¿está alineado con el dominio «From» visible?

Políticas de DMARC

La etiqueta `p=` declara lo que el propietario del dominio quiere que los receptores hagan con los correos electrónicos que fallan en la verificación de DMARC. Se definen tres valores en RFC 7489:

• `p=none — Solo supervisar. El propietario del dominio no solicita la aplicación de DMARC; los receptores siguen aplicando sus propios filtros de spam, abuso, reputación y políticas. Si se establece `rua`, los receptores participantes pueden enviar informes agregados.
• p=quarantine — destinatarios debería Consider los correos electrónicos fallidos como sospechosos. En la práctica, esto generalmente significa enviarlos a la carpeta de correo no deseado o de spam, pero el manejo exacto está definido por el receptor.
• `p=reject — El propietario del dominio solicita que se rechacen los correos electrónicos que fallan, normalmente durante la transacción SMTP. El manejo final aún depende de la política del receptor.

Dos etiquetas adicionales definen la política:

• pct= controla el muestreo para la aplicación de la política: especifica a qué porcentaje de los mensajes que no superan la comprobación se aplica la política solicitada. Según RFC 7489 §6.6.4, los mensajes que quedan fuera de ese porcentaje se tratan conforme a la política inmediatamente menos restrictiva: p=reject pasa a p=quarantine, p=quarantine pasa a p=none y p=none permanece igual. Por tanto, p=reject; pct=10 significa «aplicar reject al 10% de los mensajes que no superan la comprobación y tratar el 90% restante como si se aplicara p=quarantine». Para p=quarantine; pct<100, RFC 7489 §6.6.4 indica que el receptor debe clasificar normalmente los mensajes no seleccionados según sus reglas locales; en la práctica, DMARC no impone un tratamiento distinto. Siguen aplicándose los filtros habituales de spam, reputación y contenido del receptor. Los informes agregados abarcan el tráfico evaluado independientemente de pct; pct no establece un muestreo de informes.
• `sp= establece la política para subdominios que no publican su propio registro de DMARC. Si no está presente, los subdominios heredan el valor del dominio padre `p`.

La política del receptor local puede anular cualquiera de estas. Los receptores aún pueden utilizar sistemas de reputación, lógica de remitentes de confianza, listas blancas, listas negras, filtrado de contenido y modelos de detección de abuso antes de tomar la decisión final de entrega. La política publicada es la preferencia de manejo expresada por el propietario del dominio, y no garantiza el comportamiento universal de los receptores.

Progresión segura de la política

Dirigirse directamente a p=reject en un dominio de producción es una forma de alto riesgo de interrumpir el correo legítimo. El despliegue seguro es metódico:

1. Publicar p=none con rua que apunte a una bandeja de entrada o servicio de análisis. No modificar nada más.
2. Recopilar informes agregados durante al menos dos a cuatro semanas. Identificar todas las direcciones IP y plataformas que envían en nombre de usted. Para los dominios de correo de usuario que aún podrían considerarse para p=reject, DMARCbis recomienda al menos un mes con p=none, seguido de un período igualmente largo con p=quarantine, antes de comparar los resultados y decidir si p=reject es tolerable.
3. Inventariar los remitentes legítimos. Comparar con los datos del informe. Cualquier remitente legítimo que no cumpla con los requisitos debe ser corregido antes de la aplicación.
4. Corregir los registros SPF, configurar DKIM en cada plataforma que lo admita y asegurarse de que el dominio de firma o la dirección de retorno produzcan una coincidencia con su «From» visible.
5. Pasar a p=quarantine con un pct bajo (10-25%). Vigilar los informes.
6. Aumentar el pct gradualmente a medida que los fallos de fuentes legítimas se mantengan estables.
7. Pasar a p=reject solo cuando los informes agregados muestren que esencialmente todo el volumen legítimo está alineado y funcionando correctamente, y solo si el caso de uso del dominio puede tolerar el riesgo restante de reenvío y listas de correo.
8. Continuar monitoreando permanentemente. Las nuevas herramientas SaaS, los cambios de proveedores y la tecnología «shadow IT» introducirán nuevas fuentes de envío con el tiempo.

No asumir que Microsoft 365, Google Workspace, su proveedor de servicios de correo electrónico (ESP), su CRM, su plataforma de facturación o su servicio de atención al cliente están automáticamente alineados. No lo están. Cada uno debe configurarse para firmar o enviar de una manera que produzca una alineación con el dominio «From» que pretende utilizar.

Para los dominios de transacción, facturación, alertas de seguridad y «parked», p=reject suele ser el estado final maduro adecuado una vez que los informes están limpios. Para los dominios de correo de usuario de uso general, donde los empleados publican en listas de correo o dependen de las rutas de reenvío, p=quarantine puede ser la política final más segura. Trate p=reject como una decisión de riesgo, no como una insignia universal de madurez.

Según la evaluación actual de RFC 7489, un mensaje puede pasar la verificación de DMARC utilizando tanto SPF alineado como DKIM alineado. Sin embargo, para los dominios que eligen p=reject, la propuesta DMARCbis añade una guía más estricta: estos dominios NO deben basarse únicamente en SPF para pasar la verificación de DMARC y DEBEN aplicar firmas DKIM válidas, ya que SPF es vulnerable en los flujos de correo electrónico y de reenvío. Hasta que DMARCbis se publique y se adopte de forma significativa por los receptores, trate esto como una guía operativa basada en el borrador, en lugar de un cambio en el comportamiento de RFC 7489 implementado.

Lo que DMARC no resuelve

DMARC es eficaz contra la falsificación directa del dominio «From» visible, pero no es un control de seguridad de correo electrónico completo. No resuelve:

• Cuentas de usuario comprometidas que envían correo autenticado desde una infraestructura legítima.
• Dominios similares o relacionados, como examp1e.com o example-billing.com.
• Falsificación del nombre de visualización, donde el atacante utiliza un dominio diferente pero un nombre de remitente engañoso.
• Archivos adjuntos o URLs maliciosos en los mensajes que autentican correctamente.
• Colocación en la bandeja de entrada, reputación del remitente, quejas de spam o filtrado de contenido.
• Compromiso de correo electrónico empresarial desde dominios legítimos operados por atacantes.

Lista de verificación de preparación práctica antes de crear un registro DMARC

• Inventar todos los sistemas que envían correo utilizando su dominio: plataforma de correo principal, ESP de marketing, CRM, ERP, servicio de atención al cliente, API transaccional, plataforma de facturación, alertas de monitoreo y cualquier servidor de aplicaciones que emita notificaciones.
• Validar la sintaxis actual del registro SPF y confirmar que el número de búsquedas DNS está muy por debajo del límite de 10 búsquedas establecido en RFC 7208.
• Verifique que haya exactamente un registro SPF TXT por dominio. Tener múltiples registros SPF TXT con el mismo nombre hace que el resultado de SPF sea permerror, lo que impide que SPF contribuya a un paso de DMARC. Un mensaje aún puede pasar la verificación de DMARC si el DKIM está correctamente configurado.
• Verifique que la firma DKIM esté habilitada en todas las plataformas que lo admiten, y verifique que los registros de clave pública resuelvan correctamente.
• Verifique la alineación en los mensajes de prueba de cada plataforma de envío utilizando una herramienta que exponga el encabezado Authentication-Results.
• Revise las rutas de reenvío (listas de correo, reenvío de cuentas de rol, gateways de terceros) para evaluar el impacto discutido a continuación.
• Decida dónde se almacenarán los informes agregados: una bandeja de entrada interna puede ser suficiente para uno o dos dominios, pero la mayoría de los equipos operativos utilizan un servicio de análisis.
• Verifique el acceso a DNS y un TTL apropiado (300 a 3600 segundos es razonable durante la implementación).
• Prepare un plan de reversión: conserve el valor anterior del registro TXT documentado para poder revertir rápidamente.
• Documente todos los cambios en un sistema de gestión de la configuración o en un manual de operaciones para auditoría y continuidad.

Creación del registro _dmarc TXT

El registro DMARC es un registro TXT publicado en el nombre de host especial _dmarc.<your-domain>. No se coloca en la raíz del dominio. El valor del registro es una secuencia de etiquetas separadas por punto y coma que comienzan con v=DMARC1.

Para un dominio que envía correo electrónico de producción y nunca ha aplicado DMARC, el modo de supervisión es el punto de partida normal:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Lo mismo en modo de supervisión, pero dirigiendo los informes a un proveedor de análisis externo. El segundo registro debe ser publicado por el dominio de destino de los informes para autorizar la recepción de informes para example.com:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example-dmarc-vendor.example"
example.com._report._dmarc.example-dmarc-vendor.example. 3600 IN TXT "v=DMARC1"

Una etapa intermedia, aplicando cuarentena a un cuarto de los correos electrónicos fallidos con una alineación explícitamente relajada:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

Una configuración de rechazo estricta para un dominio dedicado a transacciones, alertas de seguridad, en espera u otros fines, cuyo remitente legítimo es conocido, está firmado con DKIM y está alineado, y cuyos propietarios han aceptado el riesgo de reenvío y listas de correo:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Con adkim=s o aspf=s, solo las coincidencias exactas de dominio se alinean. Un mensaje que utilice From: billing@example.com no obtendrá una alineación SPF estricta de MAIL FROM bounce.example.com, ni una alineación DKIM estricta de d=mail.example.com. Utilice la alineación estricta solo después de que los encabezados del destinatario real y los informes agregados confirmen que las identidades exactas del dominio coinciden.

Cuarentena en el dominio principal con una configuración predeterminada de subdominio más estricta (útil cuando no se espera que los subdominios envíen correos electrónicos):

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc-reports@example.com"

Supervisión con múltiples destinos de informes agregados. Cada dominio organizacional externo necesita su propio registro de autorización:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com,mailto:dmarc-vendor@example.net"
example.com._report._dmarc.example.net. 3600 IN TXT "v=DMARC1"

Restricciones e advertencias importantes:

• Si el destino del informe se encuentra en un dominio organizacional diferente de la política, el dominio de destino debe publicar un registro de verificación externa . Para los informes enviados desde dmarc@vendor.example a example.com, el registro es example.com._report._dmarc.vendor.example con valor v=DMARC1. Los servicios de análisis DMARC reputados gestionan esto automáticamente, pero verifíquenlo después de la incorporación.
• La etiqueta ri es un intervalo de informe opcional solicitado según RFC 7489. Los destinatarios pueden ignorarlo, y muchos generan informes agregados aproximadamente una vez cada 24 horas de todos modos. Los ejemplos omiten ri y rf porque son opcionales y no se respetan en la práctica, no porque DMARCbis ya esté implementado universalmente. Mantenga los registros de producción compatibles con RFC 7489 hasta que DMARCbis se publique y se adopte materialmente por los destinatarios.
• Los informes forenses (ruf) no están ampliamente soportados y tienen importantes implicaciones de privacidad porque pueden contener el contenido completo del mensaje. Trátelos como opcionales e inconfiables para las operaciones.
• Nunca publique más de un registro TXT de DMARC con el mismo nombre. Según la política de descubrimiento de RFC 7489, si quedan más de un registro de política de DMARC después del análisis, el descubrimiento de la política de DMARC se detiene y el destinatario trata el mensaje como si no se hubiera encontrado ningún registro de política de DMARC.
• Nunca coloque el registro en la raíz (example.com). Debe estar en _dmarc.example.com.

Propagación DNS, TTL y verificación

El TTL de DNS determina durante cuánto tiempo un resolvedor recursivo almacena un registro. Un TTL de 3600 (una hora) es razonable para un registro DMARC en estado estable; durante la implementación activa, reducir el TTL a 300 le permite deshacer un cambio rápidamente. El TTL es la duración del almacenamiento en caché, no una garantía de propagación: los almacenes que ya contienen el registro antiguo continuarán utilizándolo hasta que su copia caduque.

Comandos de verificación:

dig TXT _dmarc.example.com

nslookup -type=TXT _dmarc.example.com

Para obtener una imagen completa, normalmente desea confirmar SPF y DKIM al mismo tiempo. Verifique el registro SPF en el dominio real RFC5321.MailFrom utilizado por cada flujo de envío, no solo en el dominio «From» visible, y verifique cada par de selectores/dominios DKIM utilizados por sus plataformas de correo electrónico:

dig TXT example.com
dig TXT bounce.example.com
dig TXT selector1._domainkey.example.com
dig TXT selector2._domainkey.mail.example.com

Validadores de terceros, como Google Admin Toolbox, MxToolbox, dmarcian, EasyDMARC, entre otros, son útiles para la comprobación de sintaxis y la visualización, pero son herramientas de diagnóstico, no autoridades de protocolo. En caso de un problema de entrega a un destinatario específico, el encabezado propio del destinatario, Authentication-Results, suele ser la evidencia más relevante, siempre y cuando esté leyendo un encabezado insertado por ese destinatario y no por un intermediario no confiable.

Desglose completo de la sintaxis de DMARC

Errores comunes que vale la pena mencionar: omitir la etiqueta v=DMARC1 como la primera, utilizar una sintaxis de etiqueta incorrecta, insertar el registro en la parte superior en lugar de debajo de _dmarc, publicar múltiples registros TXT con el mismo nombre, y depender de ruf para la visibilidad cuando muchos destinatarios no enviarán informes forenses en absoluto.

Informes agregados frente a informes forenses

Los informes agregados (RUA) son informes XML, que se entregan comúnmente como archivos adjuntos comprimidos, como archivos gzip o zip. Son el principal mecanismo operativo para comprender lo que está sucediendo con el correo que utiliza su dominio. Un único informe contiene un envoltorio de metadatos del informe, un resumen de la política que se aplicó y uno o más bloques <record>. Cada <record> describe el tráfico de una única dirección IP de origen, incluyendo:

• La dirección IP de origen y el número de mensajes para el período de informe.
• La acción que ha aplicado el destinatario (none, quarantine o reject).
• Resultados de autenticación DKIM y SPF.
• El dominio «From» que se evaluó.
• Resultados de autenticación DKIM y SPF pasados/fallidos después del procesamiento de alineación, así como resultados de autenticación brutos, según se informen.

En el XML que se muestra a continuación, los valores bajo policy_evaluated reflejan la evaluación del mecanismo de alineación de DMARC para esa fila; los valores bajo auth_results reflejan los resultados de autenticación SPF/DKIM brutos informados por el destinatario. Por lo tanto, un SPF que pasa sin alineación puede aparecer legítimamente como <spf>fail</spf> bajo policy_evaluated, mientras que aparece como <result>pass</result> bajo auth_results.

Un registro agregado, ilustrativo:

<feedback>
  <report_metadata>
    <org_name>receiver.example</org_name>
    <email>dmarc-noreply@receiver.example</email>
    <report_id>20260512-abc123</report_id>
    <date_range>
      <begin>1778544000</begin>
      <end>1778630400</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <pct>25</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.45</source_ip>
      <count>127</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounce.esp.example</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Los datos anteriores son ilustrativos y no describen ninguna organización real.

La cobertura de RUA es útil, pero no es global. Solo los destinatarios participantes envían informes agregados; algunos destinatarios suprimen o agregan detalles de forma diferente, y la entrega de informes también puede fallar. Trate RUA como la principal fuente de telemetría operativa para DMARC, no como un censo completo de todos los mensajes enviados con su dominio.

El análisis manual de informes agregados funciona para un único dominio con un pequeño número de remitentes. Más allá de eso, dirija los informes a un analizador, un servicio de informes DMARC gestionado o una canalización SIEM que pueda normalizar el XML y preservar las tendencias históricas. Puede configurar alertas para señales como:

• Una nueva dirección IP de origen que excede un umbral de volumen.
• Un aumento repentino en los fallos de DMARC provenientes de una fuente previamente alineada: normalmente, una señal temprana de una configuración incorrecta después de un cambio de proveedor.
• Una nueva header_from subdominio que nunca ha aparecido antes.
• Un cambio en los recuentos de destino después de un cambio de DNS o de plataforma.

Los informes de fallos (RUF) son independientes, por mensaje y contienen datos del mensaje, incluyendo potencialmente los encabezados completos. Muchos destinatarios no los envían. Algunos sí, requieren una autorización adicional. Pueden ser útiles en escenarios de investigación específicos, pero no deben ser la base de una estrategia de supervisión.

Consideraciones para Microsoft 365 y Google Workspace

Ambas plataformas alojan grandes cantidades de correo electrónico empresarial, pero ninguna le proporciona automáticamente una postura DMARC funcional. Cada una requiere una configuración explícita para cada dominio personalizado.

Microsoft 365. Microsoft Documentación oficial de configuración de DMARC describe el flujo de trabajo: SPF se publica en su registrador de dominio (normalmente incluyendo spf.protection.outlook.com); DKIM está habilitado por dominio a través de la página de DKIM de Microsoft Defender, que proporciona registros de selector basados en CNAME que publica en su proveedor de DNS; el registro TXT de DMARC se crea en _dmarc.<domain>. Según las reglas de descubrimiento de políticas definidas en la RFC 7489, un registro DMARC del dominio padre se aplica a los subdominios que no publican su propio registro DMARC, y Microsoft documenta este comportamiento de herencia para los dominios de Microsoft 365. Tenga en cuenta el tratamiento especial para el inquilino. *.onmicrosoft.com tanto para el dominio como para los dominios «en espera»: ambos deben estar protegidos con sus propios registros DMARC que apunten a una dirección de destino real, incluso si no se envían correos electrónicos desde ellos, para que sea visible la falsificación de esos dominios.

Microsoft 365 por sí solo no representa una postura de seguridad de correo electrónico completa. La configuración de administrador de Microsoft 365, las reglas de flujo de correo, las políticas de buzón y Defender para Office 365 cubren los aspectos de recepción y políticas; el alineamiento de DMARC para el correo saliente aún depende de lo que su dominio publica en DNS y de cómo está configurado cada remitente de terceros.

Microsoft también ha anunciado requisitos específicos para quienes envían correo a sus servicios de buzones para particulares (Outlook.com, Hotmail.com, Live.com y msn.com). Según su anuncio de 2025 y la documentación de Microsoft sobre el NDR 550 5.7.515, los dominios que envían 5.000 o más mensajes diarios a esos servicios deben publicar registros SPF y DKIM, superar ambas comprobaciones, publicar DMARC con al menos p=none y disponer de al menos un mecanismo de autenticación alineado con DMARC. Este criterio es más estricto que el de DMARC básico, para el cual basta con superar una comprobación de autenticación alineada. Los mensajes masivos que no cumplan estos requisitos pueden recibir rechazos SMTP del tipo 550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.

Google Workspace. La documentación de configuración de DMARC y las directrices para remitentes de correo de Google explican cómo activar DKIM en la consola de administración —que genera un registro TXT que debe publicarse en el selector—, autorizar Google Workspace en SPF mediante include:_spf.google.com y publicar un registro DMARC en _dmarc. Hay que recordar que la alineación de SPF sigue dependiendo de que el dominio del remitente del sobre esté alineado con el dominio visible en From. Los requisitos de Google para remitentes masivos se aplican específicamente a quienes envían mensajes a cuentas personales de Gmail: los remitentes que alcanzan aproximadamente 5.000 o más mensajes en 24 horas a esas cuentas se consideran remitentes masivos y deben autenticar y alinear sus mensajes, publicar DMARC, permitir la cancelación de suscripción con un clic en los correos de marketing y promocionales, y mantener tasas aceptables de spam. Google ha indicado que el umbral se calcula para un mismo dominio principal, incluidos sus subdominios. Se trata de una regla de clasificación del proveedor Google, no del algoritmo de DMARC para determinar el dominio organizativo; además, la clasificación como remitente masivo no caduca automáticamente una vez asignada. El mero hecho de enviar desde Workspace no satisface estos requisitos: hay que configurar el dominio.

Yahoo. De Yahoo Mejores prácticas para remitentes describir expectativas similares: implementar SPF y DKIM, publicar una política DMARC válida con al menos p=none, y asegúrese de que el dominio de origen coincida con el dominio de SPF o DKIM. Yahoo y Google anunciaron requisitos comunes para remitentes masivos en 2024; consulte directamente la documentación de Yahoo para conocer los umbrales y las reglas actuales, en lugar de basarse en resúmenes de terceros. Yahoo también ha descrito su clasificación de remitentes masivos como basada en patrones, en lugar de estar vinculada a un único número diario de mensajes públicos. Preguntas frecuentes del remitente agrega una advertencia específica del proveedor para DKIM: cuando un mensaje contiene múltiples firmas DKIM alineadas con DMARC y no todas pasan, Yahoo no garantiza que el mensaje pasará la verificación DMARC.

Para cualquiera de estas plataformas, los dominios y subdominios personalizados deben registrarse individualmente. Los dominios para el envío masivo (marketing, facturación, transaccional) deben inventariarse y autenticarse por separado de la correspondencia de los usuarios corporativos. DMARC tampoco reemplaza la seguridad de la bandeja de entrada: MFA (idealmente MFA resistente al phishing como FIDO2 o las claves de acceso WebAuthn), Acceso Condicional, retención de registros para investigaciones forenses, supervisión de reglas de reenvío de la bandeja de entrada creadas por atacantes, y un proceso de respuesta a incidentes para cuentas comprometidas, son todos controles complementarios que DMARC no sustituye.

Problemas comunes de DMARC y soluciones

Reenvío de correo electrónico

El reenvío es el principal problema de DMARC. Cuando un destinatario reenvía un mensaje (a través de un reenvío del lado del servidor, una lista de correo electrónico o una cuenta de rol), la dirección IP de conexión en el siguiente paso es la del remitente, no la del remitente autorizado. SPF, que se evalúa en esta nueva transacción SMTP, falla. DKIM puede sobrevivir si el remitente no modifica el cuerpo del mensaje o los encabezados firmados; a menudo falla si el mensaje se modifica (por ejemplo, inyección de pie de página por una lista de correo electrónico).

Existen dos posibles soluciones. El Esquema de Reescribir el Remitente (SRS) reescribe el remitente del sobre para que SPF pueda pasar en el intermediario; el SRS no tiene ningún efecto en DKIM y no aborda la alineación de DMARC para el campo «From» visible. La Cadena de Recepción Autenticada (ARC), definida en RFC 8617, permite que cada intermediario atestigüe criptográficamente los resultados de autenticación originales, de modo que el destinatario final pueda confiar en la decisión del intermediario, incluso si SPF y DKIM ya no pasan directamente.

La RFC 8617 es experimental, no pertenece a la línea de estándares. También existe un debate activo en el IETF sobre el estado a largo plazo de ARC, concretamente draft-ietf-dmarc-arc-to-historic («Reclasificación de ARC como Histórico»), que reemplazó las versiones anteriores individuales draft-adams-arc-experiment-conclusion. El borrador actual del grupo de trabajo recomienda que ARC ya no se utilice ni dependa entre remitentes y destinatarios diferentes. El soporte del destinatario es desigual, la confianza es por sellador, y ARC no debe considerarse como una solución general para el correo reenviado arbitrario. La RFC 7960 describe detalladamente los problemas de reenviado e interoperabilidad.

Proveedores de servicios de correo electrónico (ESPs)

La mayoría de los ESPs utilizan de forma predeterminada la firma de correo saliente con su propio dominio y el uso de una ruta de retorno compartida. Ambos fallan en la alineación de DMARC con su campo «From». Para solucionar esto, debe:

• Configurar una ruta de retorno personalizada (dominio de devolución) en un subdominio que controle, con los datos de SPF o CNAME proporcionados por el ESP.
• Configure un dominio personalizado para la firma DKIM, de modo que el ESP firme con d= un dominio que coincida con la dirección de correo electrónico utilizada por su organización.
• Opcionalmente, configurar un dominio de seguimiento con marca.
• Envíe campañas de prueba y verifique la cabecera «Authentication-Results» en el receptor antes de aplicar las reglas.

Una práctica común es mantener el correo de marketing en un subdominio dedicado (news.example.com, marketing.example.com) para aislar su reputación del correo corporativo.

Plataformas CRM, ERP, facturación, gestión de tickets y helpdesk

Estas plataformas son el «materia oscura» de la autenticación de correo electrónico. A menudo envían notificaciones transaccionales, facturas y respuestas de los clientes utilizando su dominio en el campo «From» visible, a veces a través de su propia infraestructura, a veces a través de servidores SMTP, o desde direcciones IP compartidas. Para cada una de ellas:

• Verificar los pasos de configuración documentados del remitente para la inclusión de SPF y la firma de DKIM.
• Evalúe el impacto en el número de búsquedas de su SPF antes de agregar las opciones — cada una. include: Esta directiva puede consumir recursivamente el presupuesto de 10 búsquedas.
• Verifique que los mensajes de salida reales produzcan un SPF o DKIM alineado.
• Si un proveedor no puede firmar con su dominio, dirija su tráfico a través de un subdominio para que un fallo en este no ponga en peligro la reputación de su dominio principal.

Subdominios

El dominio de la organización es el dominio registrado justo debajo de un sufijo público (según la Lista de Sufijos Públicos según RFC 7489; DMARCbis introduce un mecanismo diferente: la «caminata en árbol DNS», que se describe a continuación). Cada subdominio hereda la política DMARC de su dominio padre, a menos que publique la suya propia. sp= le permite establecer una política predeterminada diferente para los subdominios. Un patrón común:

• example.com — correo electrónico de usuarios corporativos, normalmente p=quarantine o p=reject, dependiendo de la configuración de reenvío y la exposición a listas de correo.
• marketing.example.com — tráfico de ESP con su propio registro DMARC que coincida con las capacidades de alineación del ESP.
• billing.example.com — correo electrónico transaccional, p=reject una vez que esté estable.
• support.example.com — respuestas del servicio de atención al cliente, configuradas para alinearse con el proveedor del servicio de atención al cliente.

Dividir el tráfico de esta manera evita daños a la reputación y le brinda independencia de políticas según el caso de uso.

Dominios sin utilizar y sin actividad

Cada dominio que una organización posee pero no utiliza para el envío de correo electrónico es un objetivo de suplantación. Bloquear estos dominios es una de las victorias de seguridad más económicas, pero debe hacerse de forma deliberada: los registros a continuación solo se aplican a un dominio que realmente no envía ni y que no recibe correo electrónico. No aplique estos registros ciegamente a un dominio que realmente maneja correo electrónico.

Para un dominio realmente sin uso, publique tres registros:

• Un registro SPF nulo que declare que ningún host está autorizado para enviar en nombre del dominio.
• Un registro MX nulo (según RFC 7505) que declare que el dominio no acepta correo electrónico.
• Un registro DMARC estricto en _dmarc con p=reject y un destino rua real para que los intentos de suplantación sean visibles. Si el dominio publica un MX nulo, no dirija rua a ese mismo dominio: los informes deben llegar a un buzón que realmente pueda recibir correo.

Ejemplo de DNS para un dominio sin uso:

example.com.                         3600 IN TXT "v=spf1 -all"
example.com.                         3600 IN MX  0 .
_dmarc.example.com.                  3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.org"
example.com._report._dmarc.example.org. 3600 IN TXT "v=DMARC1"

Si el dominio recibe correos electrónicos pero no los envía, omita el registro MX nulo y mantenga el registro SPF nulo y el DMARC estricto, apuntando rua a una bandeja de entrada activa en ese dominio o a un procesador de informes externo autorizado. Si el dominio envía correos electrónicos, el modelo «dominio sin uso» no se aplica: siga en su lugar el proceso de implementación gradual. Apuntar rua a un destino real que acepte correos electrónicos es lo que convierte el bloqueo en un monitoreo activo: sin un destino de informe, los intentos de suplantación contra sus dominios «en espera» permanecerán invisibles. En el ejemplo anterior, example.org representa un dominio de informes separado, por lo que se incluye el registro de verificación del destino externo.

Múltiples registros SPF

RFC 7208 §3.2 es explícito: un dominio DEBE tener exactamente un registro SPF. Si existen varios registros TXT con el mismo nombre y cada uno comienza por v=spf1, el resultado es permerror: la comprobación SPF falla y, por tanto, tampoco se cumple la alineación SPF en DMARC. Reúna todos los remitentes autorizados en un solo registro SPF y respete el límite de 10 consultas DNS. El aplanamiento de SPF —sustituir los mecanismos include: por rangos de direcciones IP explícitos generados por un servicio del proveedor— es una opción, pero introduce una dependencia operativa: cuando cambien las IP del proveedor, deberá regenerar el registro aplanado; de lo contrario, el correo empezará a fallar en las comprobaciones sin que resulte evidente.

DKIM defectuoso

Los modos de fallo comunes de DKIM son: la ausencia o el registro de clave pública incorrecto en el selector; modificaciones en la puerta de enlace de correo electrónico (pie de nota antivirus, reescritura de enlaces, reescritura de contenido) que invalidan la firma; el dominio de firma incorrecto (por lo que el mensaje técnicamente tiene una firma válida pero no se alinea); claves rotadas que no se propagan a DNS; y claves caducadas o revocadas.

DKIM está especificado en la RFC 6376, con RFC 8301 (Rastreo de Estándares) actualizando su base criptográfica: rsa-sha1 está prohibido, el tamaño mínimo de la clave de firma RSA es de 1024 bits, y se recomienda RSA de 2048 bits para claves de larga duración. RFC 8463 también registra ed25519-sha256 como un algoritmo DKIM compatible. Antes de utilizar Ed25519, verifique la compatibilidad en su plataforma de envío, puertas de enlace intermedias y destinatarios objetivo. Una clave pública RSA de 2048 bits excede el límite de 255 octetos en una sola cadena de caracteres DNS y debe publicarse como múltiples cadenas entre comillas dentro de un único registro TXT; los verificadores concatenan las cadenas antes de analizarlas. Pruebe después de cualquier cambio en el flujo de correo electrónico: particularmente después de introducir una nueva puerta de enlace, un producto antivirus o una configuración híbrida de Exchange.

Cuentas comprometidas

DMARC no hace nada para impedir que el correo electrónico legítimo y autenticado desde una bandeja de entrada comprometida se envíe. Si un atacante tiene las credenciales del usuario y envía desde Microsoft 365 o Google Workspace a través del canal normal de salida, el mensaje se alineará correctamente con SPF y DKIM. DMARC no es el control adecuado para esta amenaza. Los controles adecuados son la autenticación multifactor (MFA) resistente al phishing, las políticas de acceso condicional que restringen dónde y cómo los usuarios pueden autenticarse, la asignación de roles con el mínimo privilegio, la revisión periódica de las reglas de reenvío de la bandeja de entrada y las reglas de la bandeja de entrada (un mecanismo frecuente de persistencia para los atacantes), la retención de registros con alertas sobre patrones de envío anómalos, y un proceso documentado de respuesta a incidentes.

DMARC como parte de un conjunto más amplio de controles de ciberseguridad

DMARC es un control dentro de un programa de seguridad de correo electrónico en capas, que no es suficiente por sí solo ni es un sustituto de los controles de la bandeja de entrada, los dispositivos, la red y la respuesta a incidentes. Desde una perspectiva de gobierno y auditoría, los informes agregados de DMARC pueden proporcionar evidencia útil sobre la cobertura de la autenticación de correo electrónico, el inventario de remitentes de terceros y la supervisión continua de los sistemas que envían utilizando su dominio. No exagere esta evidencia: los informes de DMARC muestran las evaluaciones de autenticación de los destinatarios participantes, no un censo completo de toda la actividad de correo electrónico.

Esta perspectiva es útil para justificar el trabajo ante un interesado no técnico, pero no debe exagerarse. DMARC no proporciona protección de datos en tránsito (utilice TLS, MTA-STS y TLS-RPT para ello), no detecta malware, no previene la suplantación de cuentas y no bloquea el phishing con dominios similares. Combínelo con la remediación de vulnerabilidades, la disciplina de gestión de la configuración en la pila de correo electrónico, la supervisión continua de los fallos de autenticación y la formación de los usuarios en el reconocimiento del phishing.

Escenario hipotético

El escenario a continuación es hipotético y utiliza números ilustrativos. No se basa en ninguna organización real específica.

Estado inicial. Una empresa mediana utiliza Microsoft 365 para el correo electrónico corporativo en example.com. Existe SPF, pero incluye nueve proveedores; DKIM solo está habilitado en el dominio predeterminado onmicrosoft.com; no existe ningún registro de DMARC. El correo electrónico transaccional para los clientes proviene de una plataforma de facturación SaaS que envía como example.com; las campañas de marketing pasan por un proveedor de servicios de correo electrónico (ESP) que envía como example.com; el servicio de atención al cliente responde a través de una herramienta de gestión de tickets que envía como example.com.

Fase 1, semanas 1–2. El equipo de ingeniería habilita la firma DKIM para el dominio personalizado en Microsoft 365 (se publican los registros CNAME, se activa la firma una vez que los registros se resuelven). Publican v=DMARC1; p=none; rua=mailto:dmarc@example.com y dirigen los informes a un servicio de análisis de DMARC. Los primeros informes revelan quince rangos de direcciones IP de envío distintos. La mayoría son esperadas (Microsoft 365, el ESP, la plataforma de facturación, la herramienta de gestión de tickets). Tres no lo son: dos son servidores en el sitio que nadie ha documentado, y uno es un entorno de prueba para desarrolladores.

Fase 2, semanas 3–6. Se revisan los remitentes no documentados. Los servidores locales pasan a retransmitir el correo a través de Microsoft 365 con la autenticación de conector adecuada; el entorno aislado de pruebas se traslada del dominio de producción a un subdominio de pruebas. Se reconfigura el ESP con un return-path personalizado y un dominio propio para la firma DKIM; la proporción de tráfico de marketing alineado pasa del 0% a casi la totalidad. La plataforma de facturación se reconfigura para usar DKIM con una identidad de firma alineada con el dominio. Se configura de forma similar la herramienta de gestión de tickets. Se revisa SPF y se eliminan dos inclusiones de proveedores que ya no se utilizan, reduciendo a siete el número de consultas.

Fase 3, semanas 7-10. La política se traslada a v=DMARC1; p=quarantine; pct=10; rua=.... Los informes consolidados siguen siendo revisados semanalmente. Después de dos semanas sin incidencias, pct pasa a 25, luego a 50 y finalmente a 100.

Fase 4, semana 11+. Con informes que muestran que prácticamente todo el volumen legítimo se alinea con al menos un mecanismo, y después de confirmar que el riesgo asociado al reenvío de dominios y a las listas de correo es aceptable, la política se traslada a p=reject. El tráfico de marketing se desvía a news.example.com, que cuenta con su propio registro DMARC, para evitar que cualquier cambio futuro en las herramientas de marketing afecte a la correspondencia corporativa. El seguimiento continuo continúa; el equipo añade una alerta para cualquier nueva dirección IP que supere un umbral diario.

Lecciones. Los mayores riesgos no eran técnicos, sino los sistemas no documentados que solo se hicieron visibles gracias a los informes agregados. Sin la fase de supervisión, la transición hacia la aplicación de las normas habría interrumpido silenciosamente esos flujos. Ninguno de los porcentajes o recuentos en este escenario debe interpretarse como garantías de resultados; son plausibles desde una perspectiva operativa, pero específicos para esta configuración hipotética.

Tendencias y estándares relacionados para 2025–2026

Existen varios desarrollos que vale la pena seguir a partir de mayo de 2026.

DMARCbis. A partir del 13 de mayo de 2026, borrador: IETF – DMARC y DMARCBIS – 41 está listado en IETF Datatracker con el estado de IESG RFC Ed Queue y el editor de RFC AUTH48, con estado deseado Proposed Standard. Hasta que se asigne un número de RFC y se publique el documento, considéralo como un «borrador» en transición y consulte Datatracker para verificar su estado actual. El borrador tiene como objetivo reemplazar las RFC 7489 y 9091 si es aprobado. El cambio principal es que DMARCbis reemplaza la «Lista de Sufijos Públicos» como mecanismo para determinar el dominio de la organización mediante un «paseo» por el árbol DNS, eliminando la dependencia de una lista externa que debe ser mantenida manualmente.

Borradores complementarios para DMARCbis. DMARCbis divide el trabajo del protocolo en tres documentos: la especificación principal de DMARCbis, informes agregados y informes de fallos. A partir del 13 de mayo de 2026, la versión principal de DMARCbis está listada por IETF Datatracker con el estado IESG RFC Ed Queue y el estado RFC Editor AUTH48. Los borradores de informes agregados y de informes de fallos también se encuentran en el camino de RFC Editor como documentos separados del Grupo de Trabajo DMARC de IETF (draft-ietf-dmarc-aggregate-reporting y draft-ietf-dmarc-failure-reporting), ambos con el estado IESG RFC Ed Queue y el estado RFC Editor RFC-EDITOR. Hasta que se asignen los números de RFC y se publiquen los documentos, trate a los tres como borradores en transición. No se espera ningún cambio inmediato en el analizador únicamente porque los informes agregados se dividieron en un documento complementario, pero los operadores que consumen informes deben seguir el RFC de informes agregados final antes de considerar que el comportamiento del analizador está «congelado».

Cambios en las etiquetas DMARCbis. DMARCbis también retira tres etiquetas de RFC 7489 e introduce tres nuevas. pct se reemplaza por una bandera de prueba binaria t=: t=y solicita que los receptores apliquen la política un nivel por debajo del valor especificado p / sp / np (por lo que p=reject; t=y se trata como quarantine y p=quarantine; t=y como none); t=n (el valor predeterminado) solicita la política especificada tal como es. La experiencia operativa demostró que los valores intermedios pct se implementaban de forma inconsistente en los receptores: en la práctica, solo pct=0 y pct=100 eran fiables, por lo que el grupo de trabajo eliminó la muestreo basada en porcentaje en favor de una señal de prueba clara: encendido/apagado. ri y rf también se eliminan, por razones similares (los receptores ignoraban ri y solo se definía un valor rf). En cuanto a las adiciones, np= declara una política para subdominios inexistentes (respuestas NXDOMAIN), cerrando una brecha que permite a los atacantes falsificar subdominios aleatorios; psd= formaliza el marcador de Dominio Sufijo Público, originalmente introducido experimentalmente en RFC 9091, para que los registros como gov.uk puedan publicar políticas significativas. Los registros existentes v=DMARC1 siguen siendo válidos: los receptores de DMARCbis ignoran las etiquetas desconocidas, y los receptores de RFC 7489 ignoran las nuevas, pero las implementaciones de producción deben permanecer compatibles con RFC 7489 hasta que DMARCbis se publique y sea adoptado de forma significativa por los receptores. Trate a t=, np= y psd= como elementos de transición para supervisar y probar, no como el comportamiento universal de los receptores en la actualidad.

Requisitos para remitentes de Gmail, Yahoo y Outlook. Los requisitos de Google para remitentes masivos se aplican a quienes envían alrededor de 5.000 o más mensajes en 24 horas a cuentas personales de Gmail. Las preguntas frecuentes sobre las directrices para remitentes de Google indican que los mensajes enviados desde un mismo dominio principal, incluidos sus subdominios, cuentan para ese umbral y que la clasificación como remitente masivo no caduca automáticamente. Google exige a estos remitentes autenticar el correo con SPF y DKIM, publicar una política DMARC, cumplir los requisitos de alineación, permitir la cancelación de suscripción con un clic para los correos de marketing y promocionales y mantener tasas aceptables de spam. Yahoo publica recomendaciones similares: implementar SPF y DKIM, publicar una política DMARC válida con al menos p=none y garantizar que el dominio del campo From esté alineado con el dominio SPF o DKIM. Microsoft anunció en 2025 requisitos para los remitentes de correo a los buzones de particulares de Outlook.com, Hotmail.com, Live.com y msn.com: los dominios que envían 5.000 o más mensajes diarios a esos servicios deben publicar SPF y DKIM, superar ambas comprobaciones, publicar DMARC y alinear SPF y/o DKIM para la validación de DMARC. Los mensajes que no cumplan estos requisitos pueden recibir rechazos SMTP 550 5.7.515.

BIMI. Los Indicadores de Marca para la Identificación de Mensajes (BMID) son actualmente Proyecto de Internet de la IETF, no es un RFC. No refuerza la autenticación por sí solo, sino que se basa en SPF, DKIM y DMARC existentes. La versión actual requiere una política de DMARC sólida tanto para el dominio de la organización como para el dominio «From»: p=reject, o p=quarantine con una eficacia demostrada pct=100, y cualquier política de subdominio (sp) NO debe none. Cómo BIMI tratará a DMARCbis t=y bandera de prueba en lugar de pct=0 aún no está implementado en el borrador de BIMI. Los proveedores de correo electrónico deciden si y cómo mostrar el indicador, así como el logotipo de la empresa, y que varios proveedores importantes también requieren un Certificado de Marca Verificada (VMC) o un Certificado de Marca Común (CMC), lo que implica un coste y un proceso adicionales distintos de la configuración del DNS.

MTA-STS y TLS-RPT. RFC 8461 (MTA-STS) y RFC 8460 (Informes TLS de SMTP) protegen el correo en tránsito entre MTAs aplicando TLS y reportando los fallos. Son independientes de DMARC, pero se implementan comúnmente junto con él como parte de una postura de seguridad de correo electrónico completa.

Lista de verificación de implementación

• Identifique a todos los remitentes legítimos que utilizan su dominio en el campo «De».
• Valide la sintaxis de su registro SPF y el número de búsquedas DNS; elimine cualquier registro TXT SPF duplicado.
• Habilite DKIM en todas las plataformas compatibles, con un dominio de firma que se alinee con su «De».
• Confirme la alineación de SPF y la alineación de DKIM para mensajes representativos de cada plataforma.
• Publicar _dmarc.<domain> con p=none y una solución real rua destino.
• Bloquee los dominios parkeados y no utilizados con SPF nulo, MX nulo (si no reciben correo) y p=reject DMARC que apunte a un destino de informe real.
• Recopile informes agregados durante varias semanas. Incorpórelos en un analizador o servicio.
• Investigue cada dirección IP de envío que aparezca en los informes. Resuelva las incógnitas antes de cualquier cambio de política.
• Realice pruebas de correo electrónico transaccional de principio a fin desde Microsoft 365 o Google Workspace, proveedores de servicios de correo electrónico (ESP), CRM, facturación, servicio de atención al cliente y cualquier otro sistema.
• Migre a p=quarantine con un pct bajo; monitorea; aumenta gradualmente.
• Solo se debe cambiar a p=reject cuando los informes confirmen que el tráfico legítimo es seguro y que el riesgo asociado al reenvío/lista de correo del dominio es aceptable; en caso contrario, se debe documentar p=quarantine como la política final para ese dominio.
• Continúe monitoreando permanentemente. Revise periódicamente SPF, DKIM y DMARC después de cualquier cambio en el flujo de correo, cambio de proveedor o adición de dominio.
• Documente la postura de DMARC como parte de la evaluación de seguridad y la evidencia de cumplimiento.

Conclusión

DMARC no es una simple modificación en el DNS. Es una práctica operativa iterativa: inventario, implementación con monitoreo, corrección de los problemas que surjan, aplicación gradual y seguimiento continuo. El punto de partida es p=none con el monitoreo; el objetivo final depende de la función del dominio. Los dominios transaccionales y de «correo electrónico de reserva» suelen estar en p=reject, mientras que los dominios de correo electrónico generales pueden seguir siendo más seguros en p=quarantine cuando se utilizan listas de correo o el envío de correos electrónicos. Saltar este paso es lo que causa interrupciones legítimas en el envío de correos electrónicos.

Si se implementa de esta manera, DMARC es un control de alto valor. Reduce la falsificación directa del dominio «From», proporciona visibilidad continua de las evaluaciones de los destinatarios sobre el uso de su dominio y produce pruebas de respaldo útiles de cobertura de autenticación, sujeto a la participación de los destinatarios y los límites de entrega de informes. Combinado con SPF, DKIM, MFA, Conditional Access, MTA-STS, TLS-RPT, retención de registros, capacitación de usuarios, respuesta a incidentes y monitoreo continuo, forma parte de un programa de seguridad de correo electrónico defensivo. Por sí solo, no lo es. Configurelo en consecuencia.

Fuentes

• RFC 7489 — Autenticación, informes y conformidad basadas en el dominio (DMARC), Información
• RFC 7208 — Framework de políticas de remitente (SPF)
• RFC 6376 — Firmas de correo electrónico identificadas por claves (DKIM)
• RFC 8301 — Actualización de algoritmos y uso de claves para correo electrónico identificado por claves (DKIM)
• RFC 8463 — Un nuevo método de firma criptográfica para correo electrónico identificado por claves (DKIM)
• RFC 8601 — Campo de encabezado de mensaje para indicar el estado de autenticación del mensaje
• RFC 8617 — Protocolo de Cadena Recibida Autenticada (ARC), Experimental
• RFC 8461 — Seguridad de Transporte Estricta (MTA-STS) para MTA de SMTP
• RFC 8460 — Informe de TLS para SMTP
• RFC 7960 — Problemas de interoperabilidad entre DMARC y flujos de correo indirectos (listas de correo, remitentes, gateways, intermediarios)
• RFC 7505 — Registro de «MX Nulo» sin recurso para dominios que no aceptan correo
• RFC 8553 — Cambios en Attrleaf de DNS: Corrección de especificaciones mediante el uso de nombres de nodos con guiones
• RFC 8616 — Autenticación de correo electrónico para correo electrónico internacionalizado
• RFC 9091 — Extensión experimental de DMARC para dominios de sufijo público
• IETF Datatracker — draft-ietf-dmarc-dmarcbis (DMARCbis, Internet-Draft)
• IETF Datatracker — draft-ietf-dmarc-aggregate-reporting
• IETF Datatracker — draft-ietf-dmarc-failure-reporting
• IETF Datatracker — propuesta-ietf-dmarc-arc-a-historic
• IETF Datatracker — propuesta-adams-arc-experiment-conclusion
• IETF Datatracker — Indicadores de Marca para la Identificación de Mensajes (BIMI), Propuesta de Internet
• Microsoft Learn — Utilice DMARC para validar correos electrónicos, pasos de configuración
• Microsoft Learn — Informes de DMARC para MOERA y dominios anclados
• Microsoft Tech Community — Requisitos de Outlook para remitentes de alto volumen
• Microsoft Support — Solucione el error NDR 550 5.7.515 en Outlook.com
• Ayuda de Google Workspace — Ayude a prevenir el phishing y el spam con DMARC
• Ayuda de Google Workspace — Directrices para remitentes de correo electrónico
• Ayuda de Google Workspace — Preguntas frecuentes sobre directrices para remitentes de correo electrónico
• Yahoo Sender Hub — Mejores prácticas y requisitos para remitentes
• Yahoo Sender Hub — Preguntas frecuentes para remitentes