Mejores herramientas de validación de registros DMARC

DMARC significa Domain-based Message Authentication, Reporting, and Conformance. Es un registro TXT de DNS publicado en `_dmarc.yourdomain.com` que indica a los servidores de correo receptores qué hacer cuando un correo que dice venir de tu dominio no supera las comprobaciones de autenticación. Sin DMARC, cualquiera puede enviar correos que parecen venir de tu dominio - una técnica llamada suplantación de dominio que se utiliza en ataques de phishing y de compromiso de correo empresarial (BEC).

Un registro DMARC hace dos cosas: establece una política (qué acción tomar con los mensajes que fallan) y configura los informes (dónde enviar resúmenes de los resultados de autenticación). La política puede ser `none` (monitorizar sin actuar), `quarantine` (entregar en spam) o `reject` (bloquear el mensaje por completo). Las etiquetas de informes especifican las direcciones de correo que reciben informes agregados XML diarios de los principales proveedores de correo.

La estructura del registro DMARC

# Registro solo de monitorización (punto de partida seguro)
v=DMARC1; p=none; rua=mailto:[email protected]

# Cuarentena con aplicación parcial e informes forenses
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=r; aspf=r

# Rechazo completo - úsalo solo tras confirmar que todos los remitentes pasan
v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:[email protected]; adkim=s; aspf=s

• v=DMARC1: Etiqueta de versión - obligatoria, debe ir primera, exactamente como está escrita.
• p=: Política aplicada al dominio - `none`, `quarantine` o `reject`.
• sp=: Política de subdominios - anula p= para subdominios si se establece.
• rua=: Destino del informe agregado - un URI mailto: (o URI de un servicio de informes).
• ruf=: Destino del informe forense - informes individuales de fallos (menos común, con implicaciones de privacidad).
• pct=: Porcentaje de mensajes a los que aplicar la política - útil para un despliegue gradual (1-100).
• adkim=: Modo de alineación DKIM - `r` (relajado) o `s` (estricto).
• aspf=: Modo de alineación SPF - `r` (relajado) o `s` (estricto).

DMARC no autentica el correo por sí mismo - es una capa de orquestación que se apoya en SPF y DKIM. Cuando un servidor de correo receptor recibe un correo que dice venir de tu dominio, comprueba dos cosas: ¿el mensaje pasó SPF o DKIM, y el dominio autenticado se alinea con el dominio de la cabecera From? Si al menos uno de los dos pasa y se alinea, DMARC pasa. Si ninguno pasa con alineación, el servidor receptor aplica la política de tu registro DMARC.

Autenticación y alineación SPF

SPF (Sender Policy Framework) autoriza qué servidores de correo pueden enviar correo en nombre de tu dominio. La comprobación se hace contra el remitente del sobre SMTP (la dirección `MAIL FROM`), no contra la cabecera From visible. Para la alineación DMARC, el dominio del `MAIL FROM` debe coincidir (o ser un subdominio, en modo relajado) con el dominio de la cabecera From. Cuando envías a través de un servicio de terceros como Mailchimp o SendGrid, su dominio de return-path suele ser `mailchimp.com` - esto rompe la alineación SPF a menos que configures un subdominio de return-path personalizado. Usa el Validador de registros SPF para comprobar tu registro SPF en busca de errores de sintaxis y violaciones del límite de lookups antes de confiar en él para la alineación DMARC.

Autenticación y alineación DKIM

DKIM (DomainKeys Identified Mail) añade una firma criptográfica a los correos salientes. La firma incluye una etiqueta `d=` que especifica el dominio firmante. Para la alineación DMARC, el dominio `d=` debe coincidir (o ser un subdominio, en modo relajado) con el dominio de la cabecera From. La alineación DKIM es más robusta para remitentes de terceros porque puedes configurarlos para firmar con tu propio dominio en lugar del suyo. El Validador de registros DKIM comprueba que el registro DNS de la clave pública para un selector dado esté correctamente formateado y accesible.

Para superar la autenticación DMARC, los mensajes deben ser autenticados por SPF o DKIM, y el dominio autenticador debe alinearse con el dominio de la cabecera From.

Validar un registro DMARC requiere comprobar tres cosas: que el registro DNS existe y es accesible, que la sintaxis es correcta y que SPF y DKIM están configurados para soportar la alineación de la que depende DMARC. Cada paso puede hacerse rápidamente con las herramientas adecuadas.

La mayoría de los problemas de validación de DMARC caen en categorías predecibles. Muchos son simples errores de sintaxis que un validador detecta de inmediato; otros son problemas de configuración más sutiles que requieren entender la alineación para diagnosticarlos correctamente.

Errores de sintaxis y de etiquetas

• v=DMARC1 ausente como primera etiqueta: La etiqueta de versión debe ser el primer campo. Si cualquier otra etiqueta la precede, el registro no es válido.
• Etiqueta p= ausente: La etiqueta de política es obligatoria. Un registro sin p= está mal formado y la mayoría de los servidores de correo lo ignoran.
• Valor de p= no válido: Solo `none`, `quarantine` y `reject` son válidos. Cualquier otro valor (p. ej. `monitor`) hace que el registro sea rechazado.
• Puntos y coma ausentes entre etiquetas: Las etiquetas deben separarse con puntos y coma. Un separador ausente hace que el analizador fusione dos etiquetas en una etiqueta no válida.
• Espacios alrededor de los signos =: `p = none` (con espacios) no es válido en algunos analizadores. Usa `p=none` sin espacios.
• Formato de URI rua= no válido: El valor de rua= debe ser un URI `mailto:` válido. Una dirección de correo sin `mailto:` es un error de sintaxis.

Errores de alineación y autenticación

Los errores de alineación son más difíciles de diagnosticar que los errores de sintaxis porque requieren entender las cabeceras del correo. El escenario más habitual: configuraste SPF correctamente para los envíos directos desde tu propio servidor de correo, pero cuando el correo se envía a través de una plataforma de marketing de terceros, el `MAIL FROM` usa el dominio de la plataforma - rompiendo la alineación SPF. La solución es configurar la firma DKIM con tu propio dominio en la plataforma de terceros, o establecer un subdominio de return-path personalizado que apunte a tu dominio.

El error más común en el despliegue de DMARC es establecer `p=reject` antes de confirmar que todos los flujos de correo legítimos se autentican correctamente. Los correos de servicios de envío olvidados - plataformas de correo transaccional, CRM, sistemas de tickets, integraciones de socios - se bloquean en silencio, y el remitente puede no darse cuenta hasta que recibe informes de quejas o hasta que los usuarios avisan de correos que faltan.

El despliegue en tres fases

Un despliegue seguro de DMARC sigue tres fases. En la Fase 1 (semanas 1-4), publica `p=none` con una dirección de informes `rua=` y revisa los informes agregados para identificar todos los orígenes de envío y sus tasas de aprobación. En la Fase 2 (semanas 5-10), pasa a `p=quarantine; pct=10` y aumenta `pct=` gradualmente a medida que los informes confirmen que las tasas de aprobación mejoran - empezar con el 10% significa que solo el 10% de los mensajes fallidos se ponen en cuarentena, limitando el radio de impacto. En la Fase 3 (semana 11 en adelante), pasa a `p=reject` cuando todos los remitentes legítimos pasen de forma consistente y tus informes agregados muestren fallos de autenticación mínimos o nulos de fuentes legítimas.

Qué buscar en los informes agregados

Los informes agregados muestran cada origen que envió correo diciendo ser de tu dominio. Busca tus propios servidores de correo, tus proveedores de servicios de correo y cualquier remitente de terceros autorizado - todos deberían mostrar tasas de aprobación altas tanto para SPF como para DKIM. Cualquier origen con volumen significativo y tasas de aprobación bajas necesita investigación: o es un remitente legítimo que necesita corregir su autenticación, o es un remitente no autorizado que la aplicación debería bloquear. El DMARC Policy Rollout Planner te guía para interpretar estas señales y elegir el momento adecuado para cada transición de fase.

Los informes de DMARC son el circuito de retroalimentación que hace segura la aplicación. Sin informes agregados, vas a ciegas - no puedes saber qué orígenes pasan o fallan la autenticación, ni si un cambio reciente en la infraestructura de envío rompió algo. Configurar los informes correctamente es tan importante como configurar la política en sí.

Informes agregados (rua=)

La etiqueta `rua=` especifica un URI `mailto:` que recibe informes agregados XML diarios de cada proveedor de correo importante (Google, Microsoft, Yahoo, etc.) que gestiona correo de tu dominio. Cada informe es un archivo XML comprimido que muestra recuentos de mensajes, IP de origen, resultados SPF/DKIM/DMARC y disposición de la política. La dirección receptora debe estar en el mismo dominio que el registro DMARC, o ser un URI entre dominios con un registro de permiso publicado en el dominio del tercero. La mayoría de las organizaciones usan un servicio dedicado de informes DMARC en lugar de una bandeja de entrada directa, porque los informes XML brutos requieren herramientas de análisis para ser útiles.

Informes forenses (ruf=)

La etiqueta `ruf=` configura los informes forenses (de fallo) - copias individuales de los mensajes que fallan DMARC. Contienen más detalle que los informes agregados pero tienen implicaciones de privacidad: pueden incluir cabeceras de correo, y algunos proveedores dejaron de enviarlos por consideraciones de GDPR. La mayoría de los especialistas en DMARC usan solo `rua=` para los datos agregados y omiten `ruf=` salvo que se necesite un análisis forense de casos de fallo concretos.

Servicios de informes DMARC de terceros

• Google Postmaster Tools: Panel gratuito que muestra la reputación de tu dominio y las tasas de aprobación de autenticación de correo desde la perspectiva de Gmail.
• Postmark DMARC: Analizador gratuito de informes agregados con un panel visual - bueno para empezar sin un servicio de pago.
• Dmarcian: Plataforma de pago completa con análisis por origen, alertas de problemas de autenticación y guía de despliegue.
• Valimail: Plataforma DMARC de nivel empresarial con recomendaciones automatizadas de aplicación basadas en el análisis de informes.
• EasyDMARC: Plataforma de monitorización y gestión DMARC para el mercado medio con información accionable por origen de envío.

Seguir estas prácticas garantiza que tu despliegue de DMARC proporcione protección real sin interrumpir el correo legítimo, y que tu configuración siga siendo correcta a medida que evoluciona tu infraestructura de envío.

Valida siempre la pila completa de autenticación de correo

Un registro DMARC solo es tan eficaz como los registros SPF y DKIM que lo soportan. Valida los tres juntos: usa el DMARC Record Validator para el registro de política, el Validador de registros SPF para comprobar la sintaxis de los mecanismos y el límite de 10 lookups, y el Validador de registros DKIM para confirmar que tu clave pública está correctamente publicada para cada selector en uso. Revalida los tres tras cualquier cambio en la infraestructura de correo - un nuevo servicio de envío, una migración de dominio o la renovación de un certificado SSL pueden afectar a la publicación de las claves DKIM.

Usa alineación relajada durante la transición

El modo de alineación predeterminado tanto para SPF como para DKIM es el relajado (`adkim=r; aspf=r`), que permite que los subdominios satisfagan la alineación para el dominio padre. Es el ajuste correcto durante un despliegue porque muchos remitentes legítimos usan subdominios de tu dominio para autenticarse. Cambia a alineación estricta (`adkim=s; aspf=s`) solo si tienes un requisito de seguridad específico y has confirmado que todos los remitentes usan coincidencia exacta de dominio - la alineación estricta con un solo remitente mal configurado rompe DMARC para cada mensaje que ese remitente transmita.

• Empieza con p=none, nunca con p=reject: Gana confianza en tus tasas de aprobación de autenticación antes de aplicar la aplicación.
• Configura rua= antes que nada: No puedes tomar decisiones de política informadas sin los datos de los informes agregados.
• Consulta el asistente de planificación de selectores DKIM: Usa el DKIM Selector Planning Helper al rotar claves DKIM para evitar errores de solapamiento.
• Usa pct= para una aplicación gradual: Empieza en pct=10 al pasar a quarantine o reject - esto limita el impacto si algo está mal configurado.
• Revalida tras cada cambio de plataforma de correo: Añadir una nueva herramienta de marketing, CRM o sistema de tickets suele requerir actualizar SPF y configurar DKIM.
• Monitoriza la propagación DNS: Tras publicar o cambiar un registro DMARC, usa el DNS Propagation ETA Estimator para saber cuándo el cambio será visible globalmente.