Para empezar, publica este registro TXT en _dmarc.tudominio.com: v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; pct=100. Esta política solo monitoriza, no bloquea nada, y te da visibilidad antes de endurecerla hacia p=quarantine y luego p=reject. Antes de publicarlo, confirma que SPF y DKIM ya están configurados y funcionando de forma estable.

En resumen:

• SPF y DKIM deben estar estables durante unas 48 horas antes de activar DMARC; SPF falla por completo si supera diez búsquedas DNS.
• La alineación exige que el dominio autenticado coincida con el visible en «De»; el modo relajado acepta subdominios y el estricto requiere coincidencia exacta.
• Los informes agregados identifican las direcciones IP y los fallos de autenticación; audita cada remitente legítimo antes de elevar gradualmente el porcentaje de cuarentena.
• Los informes forenses detallan mensajes individuales, pero muchos proveedores no los envían; reserva un buzón dedicado y recurre a análisis externo si recibes mucho XML.

Tabla de contenidos

• Qué es DMARC y cómo funciona junto a SPF y DKIM
• Requisitos previos: comprobar SPF, DKIM y los límites de DNS
• Cómo crear y publicar el registro DMARC: etiquetas y ejemplos
• Implementación gradual: de p=none a p=reject sin perder correo legítimo
• Recepción y análisis de informes DMARC: qué hacer con los datos
• Resolución de errores frecuentes al activar DMARC
• Por qué el enfoque gradual funciona en operaciones reales
• Cómo ayudamos a gestionar la configuración y el monitoreo de DMARC
• Preguntas frecuentes
• Fuentes

Qué es DMARC y cómo funciona junto a SPF y DKIM

DMARC es el protocolo que le dice al servidor receptor qué hacer cuando un mensaje no pasa SPF o DKIM: ignorarlo, ponerlo en cuarentena o rechazarlo directamente, según la política publicada en DNS. No sustituye a SPF ni a DKIM, los complementa añadiendo una capa de decisión y de reporte.

La pieza clave es la alineación. No basta con que SPF o DKIM pasen en abstracto: el dominio que firma o autoriza el envío debe coincidir con el dominio visible en el campo «De» del mensaje. Esa coincidencia puede ser relajada (r, que acepta subdominios) o estricta (s, que exige coincidencia exacta), y se controla con las etiquetas aspf y adkim.

Cuando la alineación falla sistemáticamente, DMARC actúa como si SPF o DKIM no existieran, por eso la mayoría de los problemas de entregabilidad tras activar DMARC vienen de una alineación mal entendida, no de un fallo real de autenticación.

Requisitos previos: comprobar SPF, DKIM y los límites de DNS

Antes de publicar nada bajo _dmarc, SPF y DKIM deben estar activos, verificados y estables. Google recomienda dejar pasar unas 48 horas tras configurar SPF y DKIM antes de activar DMARC, tiempo suficiente para que la propagación DNS se complete y puedas confirmar que ambos mecanismos funcionan sin errores.

Un punto que se pasa por alto con frecuencia es el límite de SPF: el estándar permite un máximo de diez búsquedas DNS por consulta, contando mecanismos como include, a, mx, ptr, exists y redirect. Superarlo genera un PermError que invalida todo el registro SPF, aunque la sintaxis sea correcta.

Antes de seguir, revisa:

• Que SPF y DKIM respondan correctamente en una consulta DNS pública desde fuera de tu red.
• Que tu registro SPF no supere las diez búsquedas, sobre todo si usas varios proveedores de envío.
• Que tengas inventariados todos los remitentes autorizados, incluidos terceros como CRM, facturación o marketing.
• Que los subdominios que envían correo tengan su propio SPF o estén cubiertos por una política heredada.

Consejo profesional: si gestionas cold email junto con correo transaccional, separa ambos flujos por subdominio para que un problema de autenticación en uno no afecte la reputación del otro.

Nuestra guía sobre configuración técnica de SPF, DKIM y DMARC detalla cómo auditar remitentes antes de este paso.

Cómo crear y publicar el registro DMARC: etiquetas y ejemplos

El registro se publica como TXT en _dmarc.tudominio.com, nunca en el dominio raíz. Las etiquetas principales son:

• v: versión del protocolo, siempre DMARC1.
• p: política para el dominio (none, quarantine o reject).
• pct: porcentaje de mensajes a los que se aplica la política, útil para transiciones graduales.
• rua: dirección de correo que recibe informes agregados en XML.
• ruf: dirección que recibe informes forenses de mensajes individuales.
• aspf y adkim: modo de alineación para SPF y DKIM (r relajado o s estricto).
• sp: política aplicada a subdominios cuando no tienen su propio registro.
• ri: intervalo en segundos entre informes agregados.
• fo: condiciones que generan informes forenses.

Un ejemplo de monitorización inicial: v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; pct=100. Un ejemplo de transición: v=DMARC1; p=quarantine; pct=bajo; rua=mailto:dmarc@tudominio.com; aspf=r; adkim=r. Y uno de aplicación final: v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@tudominio.com; aspf=s; adkim=s.

Las etiquetas v, p, pct, rua y ruf son las que define la especificación base de DMARC para controlar política y reporte, según documenta la referencia técnica del protocolo. Conocerlas evita registros mal formados que algunos receptores simplemente ignoran.

Puedes consultar ejemplos de sintaxis adicionales en nuestra guía completa sobre SPF, DKIM y DMARC.

Implementación gradual: de p=none a p=reject sin perder correo legítimo

Endurecer la política de golpe es la forma más común de bloquear correo que sí es legítimo. El camino recomendado es incremental:

1. Publica p=none y deja correr los informes durante un periodo suficiente para analizar los datos.
2. Audita cada IP y dominio que aparece en los informes agregados y clasifícalos como legítimos o no.
3. Corrige SPF, DKIM o alineación para los remitentes legítimos que estén fallando.
4. Sube a p=quarantine con un pct bajo y observa el impacto.
5. Aumenta pct progresivamente hasta el 100 % en cuarentena antes de pasar a p=reject.

En cada fase, presta atención al volumen de fallos, a qué servicios legítimos aparecen fallando y si necesitas ajustar aspf o adkim de relajado a estricto. Para subdominios sin registro propio, la etiqueta sp te permite definir una política distinta a la del dominio principal, algo útil cuando un subdominio se usa solo para pruebas o para un proveedor externo.

Consejo profesional: documenta cada cambio de pct y de política con fecha, así puedes correlacionar cualquier caída de entregabilidad con el cambio exacto que la provocó.

Nuestro artículo sobre qué política DMARC fijar antes de escalar envíos amplía este calendario para equipos que aumentan volumen de forma constante.

Recepción y análisis de informes DMARC: qué hacer con los datos

Los informes agregados (rua) llegan en XML y resumen, por rango de fechas, qué IPs enviaron en tu nombre y si pasaron SPF, DKIM y la alineación. Los informes forenses (ruf) detallan mensajes individuales que fallaron, aunque muchos proveedores grandes ya no los envían por motivos de privacidad.

Para gestionarlos sin complicarte:

• Crea un buzón dedicado solo para recibir informes, nunca uses tu correo personal o compartido.
• Usa un servicio externo de análisis si el volumen de XML es alto, ya que leerlos manualmente no escala.
• Revisa primero qué IPs nuevas aparecen, luego los resultados de SPF y DKIM por separado, y por último las discrepancias de alineación.

Google documenta este flujo de trabajo en su guía de configuración DMARC, recomendando revisar los informes antes de cada cambio de política.

Resolución de errores frecuentes al activar DMARC

Cuando algo falla tras publicar DMARC, el orden de comprobación importa:

1. Verifica la sintaxis del registro TXT con una herramienta DNS pública; un error tipográfico en una etiqueta invalida todo el registro.
2. Revisa los encabezados de los mensajes rechazados o marcados como spam para identificar si falló SPF, DKIM o la alineación.
3. Si el problema es un PermError de SPF, consolida los include redundantes, elimina proveedores que ya no uses o mueve algunos remitentes a un subdominio con su propio SPF.
4. Ajusta pct hacia abajo temporalmente si ves fallos masivos inesperados, en vez de volver a p=none.

Los códigos de estado extendidos definidos en el RFC 7372 ayudan a diagnosticar con precisión si un rechazo SMTP se debe a fallo de SPF, ausencia de DKIM u otro problema de autenticación, en lugar de adivinar a partir del mensaje de error.

Consejo profesional: antes de tocar el SPF para resolver un PermError, cuenta manualmente las búsquedas DNS de cada include anidado, porque un solo proveedor puede consumir varias búsquedas sin que sea obvio.

Nuestra guía sobre el límite de búsquedas DNS en SPF explica cómo reescribir el registro cuando se supera el máximo permitido.

Por qué el enfoque gradual funciona en operaciones reales

La tentación de saltar directo a p=reject para «resolverlo de una vez» es la causa más común de campañas que dejan de llegar. Monitorizar primero, auditar remitentes y subir pct poco a poco evita bloquear facturación, CRM o cualquier servicio que envíe en tu nombre sin que lo recuerdes. Mantener un inventario de remitentes actualizado y revisar DMARC junto con el resto de la entregabilidad, no como un proyecto aparte, es lo que separa una transición sin incidentes de una llamada de soporte urgente.

— Yaro

Cómo ayudamos a gestionar la configuración y el monitoreo de DMARC

Configurar DMARC correctamente implica mantener sincronizados SPF, DKIM, la infraestructura de envío y los informes que llegan cada semana, algo que consume tiempo cuando gestionas varias bandejas o dominios a la vez. Con infraestructura privada de envío y warm-up gestionado, ayudamos a que la transición de p=none a p=reject no interrumpa campañas activas ni dañe la reputación del dominio.

Lo que incluye nuestro soporte operativo:

• Configuración de SPF, DKIM y DMARC como parte de la puesta en marcha de infraestructura de envío.
• Monitoreo de entregabilidad e IPs dedicadas para detectar bloqueos antes de que afecten el volumen enviado.
• Revisión de la entregabilidad para identificar posibles problemas de autenticación.

Si prefieres que un equipo se encargue de todo el proceso, nuestro servicio DFY Email Setup configura la infraestructura y la autenticación por ti. Para equipos que gestionan varias bandejas y campañas, revisa los planes disponibles según el tamaño de tu operación.

Preguntas frecuentes

¿Qué es DMARC y cómo funciona exactamente?

DMARC es un protocolo que permite publicar en DNS una política indicando qué hacer con los mensajes que fallan SPF o DKIM: ignorarlos, ponerlos en cuarentena o rechazarlos. Se apoya en la alineación entre el dominio visible y el dominio autenticado para decidir si un mensaje es legítimo.

¿Cómo se crea un dominio de correo electrónico?

Un dominio de correo se crea registrando el dominio con un proveedor DNS y configurando registros MX que apunten al servidor de correo elegido, junto con SPF, DKIM y DMARC para autenticación. La documentación de IONOS sobre registros DMARC muestra los pasos desde el panel DNS de un proveedor habitual.

¿Cómo puedo activar DKIM en Office 365?

DKIM en Office 365 se activa publicando las claves públicas generadas por el panel de administración como registros CNAME en tu DNS y luego habilitando la firma desde ese mismo panel. Es recomendable verificar que DKIM funcione correctamente antes de activar DMARC sobre el mismo dominio.

¿Qué es el SPF de un correo?

SPF es un registro DNS tipo TXT que lista qué servidores están autorizados a enviar correo en nombre de un dominio. Tiene un límite de diez búsquedas DNS por consulta y superarlo produce un PermError que anula la protección SPF, incluso si la sintaxis es correcta.

¿Cuál es la diferencia entre p=quarantine y p=reject?

p=quarantine envía los mensajes que fallan autenticación a spam o cuarentena, mientras que p=reject los bloquea por completo en el servidor receptor. La práctica recomendada es pasar primero por quarantine con un pct bajo antes de llegar a reject al 100 %, para confirmar que no se bloquea correo legítimo.

Fuentes

Para profundizar en la especificación y resolver dudas de sintaxis, estas fuentes documentan el protocolo, los códigos de error y los pasos prácticos de configuración mencionados en esta guía.

• DMARC
• Support
• Courier
• RFC 7372 - Email Authentication Status Codes

Recomendaciones

• Configuración técnica para email frío - SPF, DKIM, DMARC
• SPF, DKIM y DMARC: La guía definitiva para la seguridad del correo electrónico
• Cómo poner en la lista blanca un correo electrónico: Guía fácil paso a paso
• Lista de verificación para la entregabilidad del correo electrónico: Mejora el éxito en la bandeja de entrada