Guía de política DMARC: de None a Reject en 4 pasos

DMARC (Domain-based Message Authentication, Reporting, and Conformance) es la capa de política que une SPF y DKIM y le dice a los servidores receptores qué hacer cuando un mensaje no supera la autenticación. Sin DMARC, un proveedor de correo podría aceptar en silencio, poner en cuarentena o rechazar correo no autenticado según sus propias reglas internas. Con DMARC, defines explícitamente la política de gestión para tu dominio.

Esta guía te acompaña por todo el proceso de implementación de DMARC, desde la publicación de tu primer registro de solo monitorización hasta alcanzar el enforcement completo con una política reject.

Por qué DMARC es importante#

El spoofing de email sigue siendo uno de los vectores de ataque más comunes. Un atacante puede falsificar la cabecera "From" de un email para que parezca que el mensaje viene de tu dominio. Sin DMARC, los servidores receptores no tienen forma fiable de conocer tu intención sobre cómo gestionar esos mensajes.

DMARC resuelve tres problemas:

• Prevención del phishing: impide que los atacantes envíen emails que parecen venir de tu dominio.
• Protección de marca: evita que tu dominio se use en campañas fraudulentas que dañen tu reputación.
• Visibilidad: los reports DMARC te muestran exactamente quién está enviando email usando tu dominio, incluidos servicios legítimos que quizá hayas olvidado y remitentes no autorizados que no sabías que existían.

Los principales proveedores de correo, incluidos Google, Microsoft y Yahoo, ahora exigen DMARC para los remitentes masivos. Desde 2024, Google requiere que los dominios que envían más de 5.000 emails al día a direcciones de Gmail tengan una política DMARC publicada.

Cómo funciona DMARC con SPF y DKIM#

DMARC no realiza sus propias comprobaciones de autenticación. En su lugar, evalúa los resultados de SPF y DKIM y aplica un requisito adicional llamado alignment (alineación).

El requisito de alineación#

Para que DMARC supere la verificación, al menos una de las siguientes condiciones debe cumplirse:

1. SPF pasa Y el dominio autenticado por SPF está alineado con el dominio de la cabecera "From". SPF verifica el remitente del sobre (Return-Path). DMARC exige que ese dominio coincida (o sea un subdominio de) el dominio de la cabecera "From" visible.

2. DKIM pasa Y el dominio firmado por DKIM (tag d=) está alineado con el dominio de la cabecera "From". El dominio de la firma DKIM debe coincidir (o ser un subdominio de) el dominio de la cabecera "From".

La alineación puede ser strict (coincidencia exacta de dominio) o relaxed (se permiten subdominios). La alineación relaxed es la opción por defecto y funciona para la mayoría de las configuraciones.

Por qué importa la alineación#

Sin alineación, un atacante podría configurar SPF y DKIM para attacker.com, enviar un mensaje con From: ceo@yourcompany.com, y el email pasaría los controles SPF y DKIM (para attacker.com), pero el destinatario ve tu dominio. La alineación DMARC cierra esta brecha exigiendo que el dominio autenticado coincida con lo que el usuario ve.

Sintaxis del registro DMARC#

Un registro DMARC es un registro DNS TXT publicado en _dmarc.yourdomain.com. Aquí tienes un ejemplo completo:

v=DMARC1; p=reject; rua=mailto:dmarc-agg@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; aspf=r; adkim=r; fo=1;

Referencia de tags#

Tag	Obligatorio	Descripción	Valores
v	Sí	Versión del protocolo	Siempre DMARC1
p	Sí	Política para el dominio	none, quarantine, reject
rua	No*	Destinatarios de reports agregados	URI mailto:
ruf	No	Destinatarios de reports forenses	URI mailto:
pct	No	Porcentaje de mensajes a los que aplicar la política	1-100 (por defecto: 100)
aspf	No	Modo de alineación SPF	r (relaxed, por defecto) o s (strict)
adkim	No	Modo de alineación DKIM	r (relaxed, por defecto) o s (strict)
sp	No	Política para subdominios	none, quarantine, reject
fo	No	Opciones de reporting de fallos	0, 1, d, s

*Aunque rua es técnicamente opcional, deberías incluirlo siempre. Sin reports agregados, estás publicando una política a ciegas, sin manera de ver qué está pasando.

Valores de política explicados#

• none: solo monitorización. Los mensajes que fallan DMARC se entregan con normalidad. Recibes reports que muestran resultados de autenticación, pero no se toma ninguna acción. Este es el punto de partida.
• quarantine: los mensajes que fallan DMARC se tratan como sospechosos. Normalmente se colocan en la carpeta de spam o correo no deseado del destinatario.
• reject: los mensajes que fallan DMARC se rechazan directamente. El servidor receptor devuelve un error y el mensaje no se entrega.

Opciones de reporting de fallos (tag fo)#

• 0 (por defecto): genera un report solo si tanto SPF como DKIM fallan en la alineación.
• 1: genera un report si SPF o DKIM falla en la alineación. Es más útil para depurar y es el ajuste recomendado.
• d: genera un report si DKIM falla, sin importar la alineación.
• s: genera un report si SPF falla, sin importar la alineación.

La progresión en 4 pasos hasta el enforcement completo#

Saltar directamente a p=reject sin preparación es peligroso. Podrías bloquear correo legítimo de servicios que olvidaste estabas usando. El enfoque seguro es una progresión gradual.

Paso 1: desplegar con p=none (monitorización)#

Empieza con una política de solo monitorización para recopilar datos sin afectar la entrega de correo.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Qué hacer durante esta fase:

• Publica el registro y espera al menos de 2 a 4 semanas para recopilar suficientes datos de reports.
• Revisa los reports agregados para identificar todas las fuentes legítimas de email para tu dominio. Esto incluye tu servidor de correo principal, plataformas de marketing (Mailchimp, SendGrid, HubSpot), servicios de email transaccional, sistemas CRM, sistemas de tickets y cualquier herramienta SaaS que envíe emails en tu nombre.
• Para cada fuente legítima, asegúrate de que SPF está configurado (incluye las IP de envío del servicio en tu registro SPF) y que DKIM está activo (publica la clave pública DKIM del servicio en tu DNS).
• Investiga cualquier fuente que no reconozcas. Pueden ser servicios legítimos olvidados o remitentes no autorizados.

Duración: mínimo de 2 a 4 semanas. Más tiempo si tienes una infraestructura de envío compleja.

Paso 2: pasar a p=quarantine al 25 % (enforcement suave)#

Una vez tengas la confianza de que todas las fuentes legítimas pasan DMARC, empieza el enforcement en un pequeño porcentaje del tráfico.

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Esto le indica a los servidores receptores que pongan en cuarentena (normalmente envíen a spam) el 25 % de los mensajes que fallen DMARC. El otro 75 % se trata como si la política fuera none.

Qué hacer durante esta fase:

• Vigila los reports de cerca para detectar cualquier aumento de fallos DMARC desde fuentes legítimas.
• Si descubres un nuevo remitente legítimo al que le falta SPF o DKIM, corrige la configuración antes de continuar.
• Atento a reports de email legítimo que cae en la carpeta de spam.
• Si todo se ve limpio tras 1 o 2 semanas, pasa al siguiente paso.

Duración: de 1 a 2 semanas.

Paso 3: aumentar a p=quarantine al 100 % (cuarentena completa)#

Quita el límite de porcentaje para que la política de cuarentena se aplique a todos los mensajes que fallen.

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

O simplemente omite el tag pct, ya que 100 es el valor por defecto:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Qué hacer durante esta fase:

• Sigue monitorizando los reports.
• Verifica que ningún email legítimo se está poniendo en cuarentena.
• Comunícate con tu equipo para comprobar si alguien reporta emails que faltan.
• Tras 2 a 4 semanas sin incidencias, estás listo para el último paso.

Duración: de 2 a 4 semanas.

Paso 4: aplicar p=reject (protección completa)#

Este es el estado final. Los mensajes que fallan DMARC se rechazan por completo.

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1;

A partir de este momento, cualquiera que intente enviar email desde tu dominio sin autenticación correcta verá sus mensajes rechazados. Tu dominio queda completamente protegido frente a spoofing.

Mantenimiento continuo:

• Sigue revisando los reports agregados al menos mensualmente.
• Cuando añadas un nuevo servicio que envíe email, configura SPF y DKIM antes de enviar.
• Rota las claves DKIM periódicamente y verifica que las nuevas claves pasan DMARC.
• Considera añadir ruf para reports forenses si tu buzón soporta el volumen.

Cómo leer los reports DMARC#

Reports agregados (rua)#

Los reports agregados son ficheros XML enviados a diario por los servidores receptores. Contienen:

• El nombre de la organización del servidor que reporta.
• El rango de fechas cubierto.
• La política DMARC publicada.
• Para cada IP de origen que envió email usando tu dominio: el número de mensajes, los resultados SPF/DKIM/DMARC y los resultados de alineación.

Un extracto simplificado de un report agregado tiene este aspecto:

<record>
  <row>
    <source_ip>198.51.100.10</source_ip>
    <count>1542</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

El XML en bruto es difícil de leer a escala. La mayoría de organizaciones usan un servicio o herramienta de análisis de reports DMARC para parsear y visualizar los datos. Servicios como la monitorización gratuita de DMARC de Postmark, dmarcian o EasyDMARC pueden ayudar.

Reports forenses (ruf)#

Los reports forenses contienen detalles sobre mensajes individuales que fallaron DMARC, incluidas las cabeceras del mensaje y, a veces, contenido parcial. Son útiles para investigar incidentes específicos de spoofing, pero generan altos volúmenes y pueden contener información sensible. Muchos receptores ya no envían reports forenses por motivos de privacidad.

Errores habituales con DMARC#

1. Publicar p=reject sin monitorizar antes#

Este es el error más peligroso. Si algún servicio de email legítimo no está bien configurado con SPF y DKIM, esos mensajes serán rechazados. Empieza siempre con p=none y revisa los reports.

2. Olvidarse de los remitentes externos#

La causa más común de fallos DMARC desde fuentes legítimas es olvidarse de una herramienta SaaS que envía email usando tu dominio. Los culpables habituales incluyen:

• Plataformas de marketing automation
• Sistemas de tickets de atención al cliente
• Plataformas CRM que envían email en tu nombre
• Software de facturación y contabilidad
• Herramientas de RR. HH. y reclutamiento
• Herramientas de calendario y planificación

Audita cada servicio conectado a tu dominio antes de pasar de p=none.

3. Registro SPF que supera las 10 búsquedas DNS#

SPF tiene un límite estricto de 10 mecanismos de búsqueda DNS (include, a, mx, redirect, exists). Si tu registro SPF supera ese límite, la evaluación SPF devuelve un "permerror", lo que significa que SPF falla efectivamente para todos los mensajes. Como DMARC requiere que SPF o DKIM pase con alineación, un permerror SPF carga más presión sobre DKIM.

Si tienes muchos servicios de envío, considera aplanar tu registro SPF o usar una estrategia de subdominios donde diferentes servicios envíen desde diferentes subdominios.

4. No usar rua#

Sin reports agregados, no tienes visibilidad sobre cómo se está autenticando el email de tu dominio. Incluye siempre un tag rua, incluso con p=none.

5. Subdominios sin tag sp=#

Por defecto, si no estableces el tag sp, los subdominios heredan la política del dominio padre. Si usas subdominios para distintos propósitos (p. ej., marketing.yourdomain.com), considera definir una política explícita para subdominios o publicar registros DMARC separados para cada subdominio.

6. Ignorar DMARC tras llegar a reject#

DMARC no es una configuración de "ponlo y olvídate". Se añaden nuevos servicios de envío, las claves caducan, los registros SPF se modifican. Sigue revisando los reports agregados mensualmente para detectar regresiones.

Cómo verificar tu configuración DMARC#

Puedes comprobar tu registro DMARC actual consultando el DNS:

dig TXT _dmarc.yourdomain.com

Para una comprobación completa que evalúa tu DMARC junto con SPF, DKIM, registros MX y estado de blacklist, usa el Email Health Checker gratuito de Nova Uptime. La herramienta te da una puntuación sobre 100, una nota (de la A a la F) y recomendaciones específicas para mejorar tu política DMARC.

La herramienta evalúa el rigor de tu política DMARC como parte de la puntuación. Una política p=reject con reporting agregado obtiene la puntuación más alta, mientras que p=none o un registro DMARC ausente provoca deducciones significativas. Esto te da una imagen clara de la situación de tu dominio y de qué pasos dar a continuación.

Calendario de implementación de DMARC#

Aquí tienes un calendario realista para un despliegue completo de DMARC:

Semana	Acción	Registro DMARC
1	Publicar registro de monitorización, configurar el procesamiento de reports	p=none; rua=mailto:...
2-4	Revisar reports, corregir SPF/DKIM para todos los remitentes legítimos	p=none; rua=mailto:...
5-6	Enforcement suave al 25 %	p=quarantine; pct=25; rua=mailto:...
7-8	Cuarentena completa	p=quarantine; rua=mailto:...
9-12	Enforcement completo	p=reject; rua=mailto:...
Continuo	Revisión mensual de reports, mantener configuraciones	p=reject; rua=mailto:...

Para organizaciones con infraestructura de email sencilla (un servicio de correo principal, una o dos herramientas de marketing), esto puede comprimirse a entre 4 y 6 semanas. Para empresas con decenas de servicios de envío, dedícale entre 3 y 6 meses.

Conclusiones clave#

• DMARC se construye sobre SPF y DKIM añadiendo enforcement de política y requisitos de alineación.
• Empieza siempre con p=none y reporting agregado. Nunca saltes directamente a p=reject.
• Usa el tag pct para incrementar el enforcement de forma gradual.
• Revisa los reports agregados para identificar todas las fuentes de email legítimas antes de aplicar el enforcement.
• Llegar a p=reject es el objetivo, pero requiere preparación.
• Sigue monitorizando tras el despliegue. DMARC requiere mantenimiento continuo.
• Usa el Email Health Checker de Nova Uptime para verificar tu configuración DMARC y obtener una evaluación completa de la autenticación de email.

Una política DMARC bien implementada es una de las protecciones más sólidas que puedes desplegar para tu dominio. Previene el spoofing, genera confianza con los proveedores de correo y te da visibilidad clara de quién está enviando email en tu nombre.

Preguntas frecuentes#

¿Qué es una verificación DMARC?#

Una verificación DMARC comprueba si tu dominio tiene un registro DNS DMARC válido y evalúa sus ajustes de política. Confirma que la sintaxis de tu registro DMARC es correcta, que tu política (none/quarantine/reject) está bien configurada y que tus direcciones de reporting funcionan. Lanza una verificación DMARC gratuita para ver tu configuración actual.

¿Es posible la monitorización DMARC gratis?#

Sí. Nova Uptime incluye monitorización DMARC como parte de su email health checker. Comprueba tu registro DMARC junto con SPF, DKIM y el estado de blacklist con una frecuencia configurable y te avisa cuando algo cambia. El plan gratuito cubre hasta 5 dominios.

¿Cuánto se tarda en llegar a p=reject?#

Para la mayoría de organizaciones, la progresión de p=none a p=reject lleva de 2 a 4 meses. El plazo depende de cuántas fuentes legítimas de email tengas que identificar y autenticar. Apresurarse a reject sin revisar los reports DMARC corre el riesgo de bloquear tu propio email legítimo.

¿Qué ocurre si pongo DMARC en reject sin SPF y DKIM?#

Tus emails serán rechazados por los servidores receptores. El enforcement DMARC requiere que al menos uno de SPF o DKIM pase Y se alinee con tu dominio del From. Configura primero SPF y DKIM, y luego progresa DMARC de none a reject de forma gradual.

Lecturas relacionadas#

• SPF, DKIM y DMARC: guía completa — Cómo trabajan juntos los tres protocolos
• Guía de prueba y configuración DMARC — Configuración avanzada de políticas DMARC
• Guía de comprobación y eliminación de blacklists de email — Qué hacer cuando los problemas de autenticación llevan a una blacklist
• Checklist de entregabilidad de email — 15 pasos para mejorar la llegada al inbox
• Email Health Checker gratis — Comprueba DMARC, SPF, DKIM y blacklists en un solo escaneo