Por qué cada dominio necesita DMARC
En el panorama actual de la seguridad del correo electrónico, no tener un registro DMARC equivale a dejar la puerta abierta a los atacantes. Google, Yahoo y Apple hicieron obligatoria la autenticación del correo para remitentes masivos en 2024, pero incluso para dominios con volúmenes reducidos, DMARC se ha convertido en un requisito fundamental para la capacidad de entrega. Sin DMARC, los correos enviados desde tu dominio son tratados con mayor sospecha por los servidores receptores, aumentando la probabilidad de que terminen en spam.
Nuestro DMARC Generator simplifica la creación del registro eliminando la necesidad de memorizar la sintaxis. Basta con seleccionar las opciones deseadas — política, correo para los informes, parámetros de alineación — y la herramienta genera el registro TXT listo para copiar y pegar en el panel DNS. Pero antes de generar el registro, es fundamental comprender cada parámetro y sus implicaciones.
Parámetros DMARC explicados
El parámetro pct es particularmente útil durante el despliegue: permite aplicar la política solo a un porcentaje de los correos. Con pct=25, solo el 25% de los correos no autenticados se trata según la política (quarantine o reject), mientras que el 75% se trata como si fuera p=none. Esto permite un despliegue gradual y seguro: comienzas con pct=10, monitorizas los informes, aumentas a 25, 50, 75 y finalmente 100.
Flujo de trabajo para implementar DMARC
Antes de generar el registro DMARC, verifica que las bases sean sólidas. Usa SPF Lookup para confirmar que el registro SPF sea válido y cubra todos los servicios que envían correo en tu nombre. Comprueba DKIM para cada servicio que lo soporte. Solo después de confirmar que la autenticación funciona puedes proceder con DMARC.
El flujo de trabajo recomendado contempla cuatro fases: Semana 1-2, genera un registro con p=none y rua para comenzar a recopilar datos. Semana 3-4, analiza los informes y corrige cualquier problema de autenticación. Mes 2, pasa a p=quarantine con pct=25 y aumenta gradualmente. Mes 3+, cuando los informes confirmen que todos los correos legítimos pasan la autenticación, activa p=reject con pct=100.
Errores comunes en la configuración DMARC
El error más frecuente es saltarse la fase de monitoreo y activar directamente p=reject. Esto puede bloquear correos legítimos de servicios de terceros (CRM, newsletter, facturación) que no están cubiertos por SPF o DKIM. Otro error es no especificar rua: sin informes agregados, navegas a ciegas y no puedes saber si los correos legítimos están siendo bloqueados por tu política.
Ten cuidado también con la alineación: con aspf=s (strict), el dominio en el Return-Path debe coincidir exactamente con el dominio en el From. Los servicios de terceros que usan su propio dominio en el Return-Path fallarán la alineación estricta. Usa relaxed (r) a menos que tengas requisitos de seguridad específicos que exijan strict. Lo mismo aplica para adkim: relaxed permite que los subdominios se alineen, strict requiere coincidencia exacta.
Un error técnico común es insertar el registro TXT con el nombre de host incorrecto. El registro DMARC debe estar exactamente en _dmarc.tudominio.com, no en la raíz del dominio ni en dmarc.tudominio.com (sin guion bajo). Verifica con nuestro DMARC Lookup que el registro sea visible y sintácticamente correcto después del despliegue. La propagación DNS tarda típicamente de unos minutos a unas horas.