Preguntas sobre DMARC,
respondidas

DMARC (Domain-based Message Authentication, Reporting & Conformance) es un protocolo de autenticación de correo que indica a los servidores de correo receptores qué hacer cuando fallan las verificaciones SPF o DKIM. Previene que los atacantes envíen correo que parezca provenir de su dominio, protegiendo su marca y destinatarios del phishing y la suplantación. DMARC está definido en RFC 7489.

Sí. Si su dominio envía correo — o incluso si no lo hace — necesita DMARC. Sin él, cualquiera puede enviar correo suplantando su dominio. Google y Yahoo ahora requieren al menos p=none para dominios que envían más de 5.000 mensajes por día. PCI DSS v4.0 requiere DMARC para dominios orientados al cliente. Los dominios que no envían correo deben publicar p=reject para prevenir la suplantación.

Comience asegurándose de que SPF y DKIM estén configurados para su dominio. Luego publique un registro DNS TXT en _dmarc.sudominio.com con p=none y una dirección rua= de informes. Supervise los informes agregados durante al menos 90 días, corrija la autenticación para todos los remitentes legítimos, luego avance progresivamente a p=quarantine y finalmente p=reject. Use nuestro DMARC Checker para validar su registro.

Publicar un registro DMARC en p=none toma minutos. Alcanzar la aplicación completa en p=reject típicamente toma de 9 a 18 meses. Cada fase (none, quarantine, reject) requiere un mínimo de 90 días de supervisión para identificar todas las fuentes de envío legítimas y corregir su autenticación. Las organizaciones con menos remitentes externos pueden avanzar más rápido.

Un registro DMARC es un registro DNS TXT publicado en _dmarc.sudominio.com. Un registro típico se ve así: v=DMARC1; p=reject; rua=mailto:dmarc@ejemplo.com; ruf=mailto:forense@ejemplo.com; adkim=r; aspf=r. Las etiquetas v= y p= son requeridas; todas las demás son opcionales pero recomendadas. Vea nuestra página ¿Qué es DMARC? para un desglose completo de cada etiqueta.

SPF verifica que el servidor de envío está autorizado por el registro DNS del dominio — verifica el remitente del sobre (Return-Path). DKIM adjunta una firma criptográfica para demostrar que el mensaje no fue alterado en tránsito. DMARC los une: requiere que SPF o DKIM pasen Y se alineen con el dominio del encabezado From visible, luego indica a los receptores qué hacer cuando falla la autenticación. Use nuestro SPF Checker y DKIM Lookup para probar sus registros.

No. Un dominio debe tener exactamente un registro DMARC TXT en _dmarc.dominio.com. Múltiples registros DMARC causan un PermError y los receptores los ignorarán todos. Si necesita enviar informes a múltiples direcciones, lístelas separadas por comas en la etiqueta rua=: rua=mailto:dmarc@ejemplo.com,mailto:informes@ejemplo.com.

La alineación DMARC significa que el dominio en el encabezado From visible debe coincidir con el dominio que pasó SPF o DKIM. La alineación relajada (predeterminada) permite la coincidencia de subdominios — mail.ejemplo.com se alinea con ejemplo.com. La alineación estricta requiere una coincidencia exacta del dominio. La alineación previene que los atacantes pasen SPF con su propio dominio mientras suplantan el suyo en el encabezado From.

La política p=none instruye a los servidores receptores a no tomar ninguna acción de aplicación sobre los mensajes que fallan DMARC. Los mensajes se entregan normalmente independientemente de los resultados de autenticación. El propósito es la supervisión: los receptores aún envían informes agregados, dando al propietario del dominio visibilidad sobre todas las fuentes de envío. Siempre comience con p=none antes de pasar a la aplicación.

La política p=quarantine instruye a los servidores receptores a enviar los mensajes fallidos a la carpeta de spam o correo no deseado. El mensaje aún existe — los destinatarios pueden encontrarlo — pero se marca como sospechoso. Este es el paso de aplicación intermedio entre p=none (supervisión) y p=reject (bloqueo completo). Vea nuestra guía Política DMARC para la progresión completa.

La política p=reject instruye a los servidores receptores a rechazar los mensajes fallidos a nivel SMTP. El destinatario nunca ve el mensaje y el servidor de envío recibe un rebote. Esta es la protección DMARC más fuerte y el objetivo final para cada dominio. Alcanzar p=reject requiere una supervisión exhaustiva a través de las fases p=none y p=quarantine primero.

La etiqueta pct= controla qué porcentaje de mensajes fallidos reciben la acción de aplicación. Con pct=25, solo el 25% de los mensajes fallidos se ponen en cuarentena o se rechazan — el resto se tratan como p=none. Esto permite un despliegue gradual de la aplicación. Comience con pct=10, aumente a 25, 50, luego 100 durante varias semanas. Si se omite pct=, el valor predeterminado es 100.

Un informe agregado (RUA) es un archivo XML enviado diariamente por los servidores de correo receptores que resume los resultados de autenticación para todos los mensajes que afirman ser de su dominio. Muestra qué direcciones IP enviaron correo, si SPF y DKIM pasaron, y qué política se aplicó. Los informes agregados son la base de la supervisión DMARC — le dan los datos necesarios para tomar decisiones de aplicación. DMARC Report convierte estos archivos XML en paneles visuales.

Un informe forense (RUF) proporciona detalles de fallo por mensaje — el correo específico que falló la autenticación, la IP del remitente, la discrepancia From/Return-Path, y qué mecanismo falló. Los informes forenses son útiles para investigar intentos de suplantación activa pero son menos comúnmente soportados por los receptores que los informes agregados. Algunos receptores no envían informes RUF en absoluto debido a preocupaciones de privacidad.

Los informes agregados DMARC sin procesar son archivos XML difíciles de leer manualmente. Use un analizador de informes DMARC como DMARC Report para convertir XML en paneles visuales que muestran el estado de autenticación de remitentes, resultados de alineación y acciones de política. La herramienta clasifica automáticamente los remitentes por proveedor (Google Workspace, Microsoft 365, SendGrid, etc.) y destaca los fallos que necesitan atención.

Razones comunes: su registro DMARC no incluye una etiqueta rua=, la dirección de correo rua= tiene un error tipográfico, o no se ha enviado suficiente volumen de correo para generar informes (los receptores típicamente agrupan los informes diariamente). Si rua= apunta a un dominio diferente al que se está autenticando, necesita un registro DNS de verificación externa. Espere de 24 a 72 horas después de publicar su registro DMARC para que los informes comiencen a llegar. Use nuestro DMARC Checker para validar la sintaxis de su registro.

La mayoría de los receptores envían informes agregados una vez cada 24 horas, típicamente a medianoche UTC. Algunos grandes receptores como Google y Microsoft pueden enviar múltiples informes por día. El volumen de informes que recibe depende de cuántos receptores diferentes procesan correo de su dominio. Los dominios populares pueden recibir cientos de informes diarios de docenas de receptores.

El viaje de p=none a p=reject típicamente toma de 9 a 18 meses. Cada fase requiere un mínimo de 90 días: p=none para supervisión e identificación de remitentes, p=quarantine para aplicación intermedia, y p=reject para protección completa. Las organizaciones con menos remitentes externos y una infraestructura de correo más simple pueden avanzar más rápido, pero apresurarse en la aplicación causa que el correo legítimo sea bloqueado.

Si un remitente legítimo falla DMARC con p=quarantine, su correo va a spam. Con p=reject, se bloquea completamente. Para corregir esto: revise los informes agregados para identificar al remitente que falla, configure su include SPF o firma DKIM, y verifique que la alineación pase. Usar la etiqueta pct= para desplegar gradualmente la aplicación ayuda a detectar estos problemas antes de que afecten todo el correo.

La cuarentena proporciona protección significativa — los mensajes suplantados salen de la bandeja de entrada. Sin embargo, p=reject es el objetivo recomendado porque previene la entrega completamente. Algunos marcos de cumplimiento (PCI DSS v4.0, CISA BOD 18-01 para agencias federales) requieren específicamente p=reject. Además, p=reject es necesario para calificar para BIMI, que muestra el logo de su marca en clientes de correo compatibles.

Sí. El reenvío de correo tradicional puede romper la alineación SPF porque la IP del servidor de reenvío no está en el registro SPF del dominio original. DKIM típicamente sobrevive al reenvío porque la firma está adjunta al mensaje mismo. Por eso la alineación DKIM es especialmente importante para dominios cuyos destinatarios reenvían correo. ARC (Authenticated Received Chain) es un protocolo más nuevo diseñado para abordar esto, pero su adopción aún está creciendo.

DMARC es requerido por un número creciente de estándares y organizaciones. Google y Yahoo requieren al menos p=none para remitentes masivos (5.000+ mensajes/día). PCI DSS v4.0 requiere DMARC para dominios usados en comunicaciones con clientes (vigente desde marzo de 2025). CISA BOD 18-01 exige p=reject para agencias federales de EE.UU. Muchas pólizas de seguro cibernético y procesos de adquisición ahora requieren la aplicación de DMARC.

Desde febrero de 2024, Google y Yahoo requieren que todos los remitentes masivos (5.000+ mensajes/día a usuarios de Gmail/Yahoo) tengan una política DMARC de al menos p=none con una dirección rua= válida. Además, los remitentes deben tener SPF y DKIM correctamente configurados, incluir encabezados de cancelación de suscripción con un clic en correo de marketing, y mantener una tasa de quejas de spam por debajo del 0,3%. Los remitentes que no cumplen experimentan limitación de entrega y rechazos.

Sí. PCI DSS v4.0 (vigente desde marzo de 2025) requiere que las organizaciones que procesan datos de tarjetas implementen DMARC en dominios usados en comunicaciones orientadas al cliente. Específicamente, el Requisito 5.4.1 establece que los mecanismos anti-phishing deben incluir autenticación basada en dominio (DMARC, SPF, DKIM). La mayoría de los evaluadores PCI esperan p=reject o p=quarantine para el cumplimiento.

La Directiva Operacional Vinculante 18-01, emitida por la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA), requiere que todas las agencias del poder ejecutivo federal de EE.UU. implementen DMARC con p=reject. Esta directiva ha aumentado significativamente la adopción de DMARC en el sector gubernamental y es frecuentemente citada como referencia de mejores prácticas por otras organizaciones e industrias.

DMARC respalda el cumplimiento de HIPAA al prevenir la suplantación de correo de nombres de dominio de salud, reduciendo el riesgo de ataques de phishing que podrían llevar a la exposición de Información de Salud Protegida (PHI). Aunque HIPAA no nombra explícitamente a DMARC, la Regla de Seguridad requiere salvaguardas para proteger PHI electrónica, y la autenticación de correo se considera una medida razonable y apropiada. Tenga en cuenta que los informes forenses (RUF) pueden contener contenido de mensajes, por lo que las organizaciones de salud deben usar solo informes agregados (RUA) o asegurarse de que los informes forenses se manejen en cumplimiento con HIPAA.