Constructor de Registro DMARC

El Constructor de Registros DMARC crea registros DNS de Domain-based Message Authentication, Reporting, and Conformance (DMARC) a través de una interfaz interactiva que te guía por todos los tags de política disponibles. Selecciona una política como p=reject, configura direcciones de reportes y obtén un registro completo como v=DMARC1; p=reject; rua=mailto:[email protected] listo para publicar en _dmarc.tudominio.com.

Entendiendo DMARC

DMARC es la capa de política que une SPF y DKIM en un sistema coherente de autenticación de correo electrónico. Por sí solo, SPF verifica si el servidor de envío está autorizado. Por sí solo, DKIM verifica que el mensaje no fue alterado. Pero ninguno le dice a los servidores receptores qué hacer cuando las verificaciones fallan, y ninguno requiere que el dominio autenticado coincida con el dominio en el header From que los usuarios realmente ven. DMARC llena ambas brechas: define una política para manejar fallas y requiere alineación de dominio, haciendo mucho más difícil para los atacantes suplantar tu dominio en campañas de phishing.

Cuando publicas un registro DMARC, le estás diciendo a cada servidor de correo receptor en internet tres cosas: cómo manejar mensajes que fallan tanto las verificaciones SPF como DKIM (ignorarlos, ponerlos en cuarentena o rechazarlos), dónde enviar reportes sobre resultados de autenticación para que puedas monitorear lo que está pasando, y qué tan estrictamente los dominios autenticados deben coincidir con el dominio de tu header From. Sin DMARC, un phisher puede enviar un correo que falla SPF y DKIM para tu dominio, pero el servidor receptor no tiene una política que le diga rechazar el mensaje -- podría aceptarlo de todos modos y dejarlo llegar a la bandeja de entrada del destinatario.

El otro gran beneficio de DMARC es el reporte. Cuando estableces una dirección rua, los servidores receptores te envían reportes XML diarios que resumen cada mensaje que vieron reclamando provenir de tu dominio, junto con los resultados SPF y DKIM de cada uno. Estos reportes revelan remitentes no autorizados que no conocías -- ya sean phishers abusando de tu dominio, servicios legítimos que olvidaste agregar a tu registro SPF, o servidores de reenvío que rompen la autenticación. Esta visibilidad es esencial antes de endurecer tu política, porque pasar a p=reject sin entender tu ecosistema de correo casi con certeza bloqueará algún correo legítimo.

Cómo construir un registro DMARC

1. Elige tu política (p=): none para monitoreo, quarantine para carpeta de spam, o reject para bloquear fallas
2. Opcionalmente establece una política de subdominios (sp=) si los subdominios necesitan manejo diferente
3. Establece el porcentaje (pct=) para aplicar gradualmente la política (por ejemplo, comienza con 10%)
4. Ingresa la dirección de correo para reportes agregados (rua=) para recibir reportes XML diarios
5. Opcionalmente ingresa la dirección de correo para reportes forenses (ruf=) para reportes individuales de fallas
6. Configura los modos de alineación (aspf=, adkim=) para coincidencia estricta o relajada
7. Copia el registro generado y publícalo como registro TXT en _dmarc.tudominio.com

Ejemplos de registros DMARC

Referencia de tags DMARC

Cuándo usar el Constructor de Registros DMARC

• Iniciando autenticación de correo en un dominio sin política DMARC existente
• Despliegue progresivo de DMARC -- pasando de p=none a quarantine a reject a lo largo de semanas
• Configurando reportes DMARC para obtener visibilidad sobre quién está enviando correo como tu dominio
• Estableciendo políticas separadas de subdominios cuando los subdominios tienen diferentes requisitos de correo
• Auditando configuraciones de alineación para decidir entre coincidencia estricta y relajada para SPF y DKIM
• Cumpliendo requisitos de compliance que exigen aplicación de DMARC (PCI DSS, NIST, mandatos gubernamentales)

Cómo funciona la autenticación DMARC

El flujo de autenticación

Cuando un servidor receptor recibe un correo de tu dominio, evalúa DMARC en este orden:

1. Verificar SPF: ¿La IP de envío coincide con el registro SPF? ¿El dominio RFC5321.MailFrom se alinea con el dominio del header From?
2. Verificar DKIM: ¿Hay una firma DKIM válida? ¿El dominio de firma (d=) se alinea con el dominio del header From?
3. Aplicar DMARC: Si cualquiera de SPF o DKIM pasa y se alinea, DMARC pasa. Si ambos fallan o ninguno se alinea, se aplica la política DMARC.

Alineación relajada vs. estricta

• Relajada (aspf=r, adkim=r): El dominio autenticado y el dominio From deben compartir el mismo dominio organizacional. Ejemplo: mail.example.com se alinea con example.com.
• Estricta (aspf=s, adkim=s): El dominio autenticado debe coincidir exactamente con el dominio From. mail.example.com no se alinea con example.com.

La alineación relajada es la predeterminada y es apropiada para la mayoría de las organizaciones. La alineación estricta proporciona protección más fuerte pero puede romper flujos de correo legítimos desde subdominios.

Estrategia de despliegue recomendada

Semana 1-2:  v=DMARC1; p=none; rua=mailto:[email protected]
             -> Monitorear reportes, identificar todos los remitentes legítimos

Semana 3-4:  v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]
             -> Poner en cuarentena 10% de las fallas, vigilar falsos positivos

Semana 5-6:  v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]
             -> Aumentar a 50%

Semana 7-8:  v=DMARC1; p=reject; pct=25; rua=mailto:[email protected]
             -> Comenzar a rechazar 25% de las fallas

Semana 9+:   v=DMARC1; p=reject; rua=mailto:[email protected]
             -> Aplicación completa

Despliegue de DMARC en la práctica

El mayor riesgo en el despliegue de DMARC es pasar a p=reject demasiado rápido. Muchas organizaciones publican un registro DMARC con p=none, recolectan reportes por una o dos semanas, y luego saltan directamente a p=reject porque los reportes se ven limpios. El problema es que algunos flujos de correo legítimos solo ocurren periódicamente -- newsletters mensuales, notificaciones de facturación trimestrales, recordatorios anuales de renovación -- y pueden no aparecer en una ventana de reporte corta. El tag pct existe precisamente para este escenario: te permite aplicar tu política solo a un porcentaje de los mensajes que fallan, para que puedas detectar problemas a escala sin bloquear todo tu correo si algo sale mal.

Una sorpresa común durante el despliegue de DMARC es descubrir cuántos servicios envían correo en tu nombre. Marketing envía a través de Mailchimp, los tickets de soporte vienen de Zendesk, las facturas pasan por QuickBooks, los restablecimientos de contraseña vienen de Auth0 y las alertas del sistema se enrutan a través de PagerDuty. Cada uno de estos servicios necesita pasar SPF (siendo incluido en tu registro SPF) o pasar DKIM (firmando con una clave alineada a tu dominio). La fase de monitoreo con p=none es tu oportunidad de identificar todos estos servicios antes de que comience la aplicación. Usa los reportes agregados para construir un inventario completo de tus servicios de envío de correo.

La política de subdominios (sp=) merece consideración cuidadosa. Por defecto, los subdominios heredan la política del dominio principal. Si estableces p=reject en example.com, también se aplica a mail.example.com, app.example.com y cada otro subdominio. Si algunos subdominios envían correo a través de infraestructura diferente o aún no están configurados para DKIM, establece sp=none o sp=quarantine para darte espacio para trabajar en la autenticación de subdominios por separado del dominio principal.

Preguntas frecuentes

¿Dónde publico el registro DMARC en DNS?

Los registros DMARC siempre se publican como un registro TXT en _dmarc.tudominio.com. Por ejemplo, si tu dominio es example.com, el registro va en _dmarc.example.com. Esta es una ubicación fija definida por la especificación DMARC -- no hay flexibilidad en el nombre.

¿Cuál es la diferencia entre los reportes rua y ruf?

El tag rua especifica dónde se envían los reportes agregados -- estos son resúmenes XML diarios que muestran resultados de autenticación para todos los mensajes. El tag ruf especifica reportes forenses -- reportes detallados sobre mensajes individuales que fallaron la autenticación. Muchos proveedores solo soportan reportes agregados debido a preocupaciones de privacidad con datos forenses. Comienza solo con rua; agrega ruf si necesitas investigación detallada de fallas.

¿Puedo enviar reportes DMARC a una dirección de correo en un dominio diferente?

Sí, pero el dominio receptor debe publicar un registro de autorización DNS. Si tu dominio es example.com y los reportes van a [email protected], entonces monitor.com debe publicar un registro TXT en example.com._report._dmarc.monitor.com con el valor v=DMARC1. Esto previene abuso donde alguien publica un registro DMARC dirigiendo una avalancha de reportes a una dirección de correo arbitraria.

¿Qué significa pct=25 en la práctica?

Significa que solo el 25% de los mensajes que fallan DMARC tendrán la política aplicada. El otro 75% se trata como si la política fuera none (monitoreado pero sin acción). Los servidores receptores usan este porcentaje de forma probabilística. Esto te permite aumentar gradualmente la aplicación y observar el impacto antes de ir a aplicación completa con pct=100 (que es el valor predeterminado cuando pct se omite).

¿Cómo leo los reportes agregados DMARC?

Los reportes agregados DMARC son archivos XML comprimidos con gzip o zip. Contienen datos sobre cada mensaje recibido de tu dominio: IP de envío, resultado SPF, resultado DKIM y la disposición (none, quarantine o reject). Leer XML crudo es impráctico a escala. La mayoría de los administradores usan un servicio de reporte DMARC que analiza el XML y presenta dashboards mostrando tasas de aprobación/falla de autenticación, remitentes no autorizados y problemas de alineación.

¿DMARC afecta el reenvío de correo?

Sí. El reenvío de correo es uno de los mayores desafíos con la aplicación de DMARC. Cuando un mensaje es reenviado por un intermediario (como una lista de correo o una dirección de reenvío de alumni universitarios), la IP de envío cambia, lo que rompe SPF. Si el reenviador también modifica el mensaje (agregando un pie de página, cambiando el asunto), DKIM también se rompe. Con p=reject, el mensaje reenviado será rechazado por el servidor del destinatario final. Las soluciones incluyen ARC (Authenticated Received Chain), que algunos receptores soportan para preservar la autenticación a través del reenvío.

Herramientas relacionadas

• Constructor de Registros SPF - Construye registros SPF con sintaxis correcta
• Verificador de Longitud de Registro SPF - Verifica la longitud del registro SPF y los límites de búsqueda
• Formateador de Registros TXT DKIM - Formatea registros DKIM con entrecomillado correcto
• Deduplicador de Conjuntos de Registros DNS - Encuentra y elimina registros DNS duplicados
• Linter de Archivos de Zona - Verifica archivos de zona en busca de errores de sintaxis y duplicados