DMARC es un registro TXT en el DNS de tu dominio que dice a los servidores receptores qué hacer con los correos que dicen venir de ti pero no superan la autenticación SPF o DKIM alineada con tu dirección «From»: entregarlos, mandarlos a spam o rechazarlos. Además te devuelve informes para ver quién envía en nombre de tu dominio. Si envías correo comercial o de prospección, ya no es opcional: es una condición para llegar a la bandeja de entrada. Esta guía te explica cómo montarlo sin bloquear tu propio correo.
En resumen
- DMARC se publica como un registro TXT en
_dmarc.tudominio.comy funciona sobre SPF y DKIM: sin ellos bien configurados, DMARC no sirve de nada. - Los grandes proveedores exigen a los remitentes masivos SPF, DKIM y una política DMARC de al menos
p=none. - Empieza en
p=nonecon informesrua, identifica todos tus remitentes legítimos y sube después aquarantineyreject. - Los informes
rua(agregados) son los que debes vigilar; losruf(forenses) llegan poco y con datos recortados. - La causa más común de fallos es la alineación del dominio, no la ausencia de registros.
Tabla de contenidos
- Qué es DMARC y qué problema resuelve
- Por qué ahora es obligatorio para quien envía en volumen
- Antes de publicar: SPF y DKIM tienen que funcionar
- La alineación: lo que casi todos pasan por alto
- Cómo es un registro DMARC y qué significa cada etiqueta
- Paso a paso: de p=none a reject sin perder correo
- RUA y RUF: qué informes recibirás y cuáles importan
- Errores frecuentes al implantar DMARC
- Nuestra opinión: DMARC no es un trámite, es parte de la infraestructura
- Cómo te ayuda PlusVibe con la parte técnica del envío
- Preguntas frecuentes
- Fuentes
Qué es DMARC y qué problema resuelve
DMARC son las siglas de Domain-based Message Authentication, Reporting and Conformance. Según la documentación de Google Workspace, se define introduciendo un registro DMARC en la configuración DNS de tu dominio. Ese registro indica a los servidores de destino qué acción tomar con los mensajes enviados desde tu dominio que no pasan la autenticación SPF o DKIM. Las opciones son rechazar, poner en cuarentena o entregar el mensaje, y puedes pedir informes para saber qué está ocurriendo.
El problema de fondo es la suplantación. Cualquiera puede escribir tu dominio en el campo «From» de un correo. SPF y DKIM comprueban partes técnicas del envío, pero ninguno de los dos obliga por sí solo al receptor a actuar contra la dirección visible. DMARC cierra ese hueco: vincula lo que ve la persona en el remitente con lo que se ha autenticado por debajo y fija una consecuencia cuando no coincide.
Hay un segundo beneficio, menos comentado: la reputación. Un dominio con DMARC en enforcement es más difícil de falsificar, y los proveedores lo tratan como un dominio que sabe lo que envía. Si quieres ver las tres capas juntas, tenemos una guía más amplia sobre SPF, DKIM y DMARC.
Por qué ahora es obligatorio para quien envía en volumen
Google y Yahoo pasaron DMARC de recomendación a requisito para remitentes masivos. Las buenas prácticas de Yahoo para remitentes piden implementar SPF y DKIM, publicar una política DMARC válida con al menos p=none, que DMARC se supere, y recomiendan con fuerza incluir una etiqueta rua bien configurada para recibir informes.
En la práctica, esto afecta a tres perfiles:
- Equipos de ventas y agencias que lanzan secuencias de correo frío desde varios dominios y buzones.
- Tiendas y empresas que envían newsletters o correo transaccional con herramientas externas.
- Cualquier dominio con web corporativa, incluso si apenas envía correo, porque un registro DMARC evita que otros lo usen para enviar spam.
Si tu volumen es bajo hoy, igualmente conviene tenerlo: cuando crezcas, no tendrás que corregir un dominio con meses de mala reputación. Para el caso concreto de la prospección en frío, hemos detallado la política DMARC que conviene fijar antes de escalar el envío.
Antes de publicar: SPF y DKIM tienen que funcionar
Este es el error que más correo legítimo rechaza. Google indica en su guía de configuración de DMARC que SPF y DKIM deben estar configurados y autenticando tu correo activamente, y recomienda esperar unas 48 horas antes de activar DMARC. Si publicas una política estricta sin esa base, los receptores pueden rechazar o enviar a spam mensajes legítimos.
Revisa esta lista antes de tocar el DNS:
- Inventario de remitentes. Anota todo lo que envía con tu dominio: tu proveedor de correo, el CRM, la herramienta de newsletters, la plataforma de facturación, el soporte, las herramientas de prospección.
- SPF correcto. Un único registro SPF por dominio que incluya a esos remitentes. Si necesitas repasarlo, aquí tienes cómo configurar SPF en menos de cinco minutos.
- DKIM activo en cada servicio. Cada remitente debe firmar con una clave publicada en tu DNS.
- Un buzón para los informes. No uses tu correo personal: los informes se acumulan rápido.
La alineación: lo que casi todos pasan por alto
Pasar SPF o DKIM no basta. DMARC exige alineación: el dominio de la cabecera «From» visible debe coincidir (en modo relajado o estricto) con el dominio validado por SPF o por DKIM. Así lo recoge el borrador del IETF sobre DMARC. Basta con que una de las dos comprobaciones esté alineada y supere la verificación.
Un ejemplo típico: envías desde hola@tuempresa.com con una herramienta externa que firma DKIM con su propio dominio, por ejemplo herramienta.net. DKIM pasa, pero con un dominio distinto al del «From». No hay alineación, y DMARC falla aunque los registros «estén bien». La solución es configurar en esa herramienta la firma con tu propio dominio (normalmente añadiendo unos registros CNAME o TXT que te facilita).
Este punto explica por qué muchos dominios se quedan años sin llegar a reject: el problema no es un registro ausente, sino un remitente mal alineado. Si te interesa el lado DKIM, lo desarrollamos en DKIM alignment, el asesino silencioso de la entregabilidad.
Cómo es un registro DMARC y qué significa cada etiqueta
El registro se publica como TXT en el subdominio _dmarc de tu dominio. Un punto de partida seguro es este:
v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com
Se lee así:
| Etiqueta | Función | Valor típico |
|---|---|---|
v |
Versión del protocolo | DMARC1 |
p |
Política para el dominio | none, quarantine o reject |
rua |
Dirección para informes agregados | mailto:dmarc@tudominio.com |
ruf |
Dirección para informes forenses | mailto:... (opcional) |
sp |
Política para subdominios | Igual que p si no se indica |
pct |
Porcentaje de mensajes al que se aplica la política | 100 por defecto |
adkim / aspf |
Modo de alineación DKIM / SPF | r (relajado) o s (estricto) |
La ayuda de IONOS explica cómo crear el registro en un panel de dominios en español, y la guía de Google lo detalla para Workspace. El procedimiento general es el mismo en cualquier proveedor DNS: crear un registro de tipo TXT, con nombre _dmarc y el texto anterior como valor.
Paso a paso: de p=none a reject sin perder correo
La estrategia estándar es gradual. Según la documentación de Google, se empieza con p=none para observar el tráfico sin afectar a la entrega, y cuando se han identificado todos los remitentes legítimos se pasa a cuarentena y, por último, a rechazo.

Fase 1: observar con p=none
Publica el registro con p=none y una dirección rua. Durante dos a cuatro semanas recibirás informes de quién envía en nombre de tu dominio. Tu objetivo es una lista completa: remitentes legítimos que pasan, remitentes legítimos que fallan (los que debes arreglar) y remitentes desconocidos (posible suplantación).
Fase 2: corregir remitentes
Por cada servicio legítimo que falle, revisa SPF, firma DKIM y alineación. Repite hasta que el tráfico legítimo pase de forma estable. No avances mientras sigas viendo fuentes legítimas fallando.
Fase 3: quarantine
Cambia a p=quarantine. Los mensajes que fallen irán a spam en lugar de la bandeja principal. Puedes usar pct para empezar con un porcentaje bajo (por ejemplo pct=25) y subirlo si no aparecen incidencias.
Fase 4: reject
Con p=reject, los mensajes que no pasan se bloquean. Es la protección completa frente a la suplantación del dominio. Mantén la revisión de informes: cada nueva herramienta que conectes puede romper la alineación.
Un aviso importante: p=none es una fase de diagnóstico, no un destino. Los especialistas de Suped señalan que un fallo habitual es quedarse en monitorización durante años, sin usar los datos de los informes para avanzar hacia la aplicación de la política. Cumples el mínimo del proveedor, pero no obtienes la protección.
Si prefieres un recorrido más detallado, lo tienes en nuestra guía para configurar DMARC paso a paso sin bloquear tu correo.
RUA y RUF: qué informes recibirás y cuáles importan
Las dos etiquetas de informes se confunden con facilidad.
RUA (informes agregados). Son resúmenes en XML, normalmente diarios, enviados por cada proveedor receptor. Según Suped, no contienen el contenido de los correos ni direcciones de remitente y destinatario, y recogen datos como el volumen de mensajes, las IP de los servidores emisores y la política aplicada. La documentación de SAP Emarsys describe rua como la dirección a la que se envían estos datos agregados.
RUF (informes forenses o de fallo). En teoría incluyen detalles de cada mensaje fallido, como cabeceras o fragmentos. En la práctica, los grandes proveedores los recortan mucho o directamente no los envían por motivos de privacidad y cumplimiento normativo. Por eso la recomendación práctica es priorizar rua y tratar ruf como un extra opcional. Si lo activas en España o en la UE, ten en cuenta que esos informes pueden contener datos personales y consulta con quien gestione tu protección de datos.

Dónde enviar los informes
Un dominio con actividad puede recibir cientos de informes al día. Google aconseja no usar una dirección personal: crea un buzón dedicado, un grupo de distribución o recurre a un servicio de monitorización DMARC que procese el XML por ti. Leer los XML a mano es posible, pero poco práctico en cuanto tienes más de un remitente.
Errores frecuentes al implantar DMARC
- Saltar directamente a reject. Es la forma más rápida de perder facturas, avisos de pedidos o respuestas de clientes. Pasa siempre por
none. - Varios registros SPF o DMARC en el mismo dominio. Los receptores pueden ignorarlos. Debe haber uno solo de cada.
- Olvidar los subdominios. Si envías desde
mail.tudominio.com, revisa la políticaspy la configuración de ese subdominio. - Conectar una herramienta nueva sin revisar la alineación. Tras cualquier alta, comprueba los informes a los pocos días.
- Dominios que no envían correo sin protección. Aunque no envíes nada, publicar un registro con política restrictiva evita que lo usen para spam, como indica la documentación pública de Cloudflare sobre este caso.
- Confundir DMARC con entregabilidad completa. DMARC autentica; no garantiza bandeja de entrada. Influyen también la reputación, el contenido, las listas y la tasa de rebote.
Si después de configurar todo ves rechazos, el motivo puede estar en otro sitio: revisa qué significan los códigos de rebote 550 o cómo actuar ante un bloqueo temporal SMTP. Y si tu IP o dominio aparece en listas negras, consulta cómo salir de Spamhaus.
Nuestra opinión: DMARC no es un trámite, es parte de la infraestructura
Desde PlusVibe vemos DMARC a diario en equipos que prospectan por correo frío, y el patrón se repite. Quien trata DMARC como un registro que se pone una vez y se olvida suele tener problemas semanas después, cuando añade un buzón, un dominio o una herramienta y nadie revisa la alineación. Quien lo trata como parte de la infraestructura de envío, con dominios y buzones bien separados, calentamiento controlado y vigilancia de entregabilidad, escala con mucha menos fricción.
Nuestra postura es sencilla. Primero, la autenticación (SPF, DKIM, DMARC) tiene que estar limpia antes de enviar a volumen, no después. Segundo, conviene separar la infraestructura de prospección de la del correo corporativo, para que un problema de reputación en una no contamine a la otra. Tercero, la infraestructura de envío privada, no compartida con otros clientes, reduce que el comportamiento ajeno afecte a tu reputación. Esa es la razón por la que construimos la plataforma alrededor de warm-up privado, infraestructura aislada y monitorización de entregabilidad.
Y una advertencia honesta: ningún registro DNS arregla una mala campaña. DMARC te pone en la línea de salida; que la bandeja de entrada te reciba depende luego de a quién escribes y qué les dices.
— Yaro
Cómo te ayuda PlusVibe con la parte técnica del envío
Si lanzas campañas de correo frío y no quieres montar a mano dominios, buzones y autenticación, en PlusVibe puedes empezar con una prueba gratuita y ver cómo funciona el warm-up privado, la rotación de buzones y el monitoreo de entregabilidad. Los planes publicados incluyen Starter por 19 $ al mes, Growth por 39 $ al mes y Scale por 89 $ al mes; puedes compararlos en la página de planes. Si prefieres que alguien configure la infraestructura por ti, existe el servicio de configuración de email llave en mano. Y antes de enviar, puedes pasar tus mensajes por el verificador gratuito de spam en correos fríos.
Preguntas frecuentes
¿Cómo activar DMARC en mi dominio?
Entra en el panel DNS de tu dominio y crea un registro TXT con nombre _dmarc. Como valor, usa v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com, sustituyendo la dirección por un buzón dedicado. Antes comprueba que SPF y DKIM funcionan, porque DMARC depende de ellos.
¿DMARC protege mi correo de virus o de spam entrante?
No. DMARC protege a quienes reciben mensajes que fingen venir de tu dominio y evita que lo suplanten. No filtra el correo que tú recibes. Para eso necesitas los filtros de tu proveedor de correo y buenas prácticas de seguridad.
¿Qué diferencia hay entre rua y ruf?
Rua envía informes agregados con estadísticas de tráfico, y es la etiqueta que recomiendan los grandes proveedores. Ruf pide informes de fallo por mensaje, pero muchos receptores los recortan o no los envían por privacidad. Empieza siempre con rua.
¿Puedo poner p=reject desde el primer día?
No es aconsejable. Si algún remitente legítimo no está autenticado o alineado, sus mensajes se bloquearán. Lo seguro es pasar por none, revisar los informes y avanzar a quarantine y después a reject.
¿Cuánto tarda en notarse un registro DMARC?
El cambio DNS puede propagarse en minutos u horas según el TTL, y los primeros informes rua suelen llegar al día siguiente. Para tener una imagen fiable de todos tus remitentes, deja correr la fase de observación al menos un par de semanas.
Fuentes
- Sender Best Practices, Yahoo Sender Hub
- Añadir un registro DMARC, Ayuda de Google Workspace
- Set up DMARC, Google Workspace Help
- draft-ietf-dmarc-dmarcbis-25, IETF
- Diferencia entre las etiquetas ruf y rua, Suped
- Configurar un registro DMARC para un dominio, IONOS Ayuda
- DMARC Additional Reporting Options, SAP Engagement Cloud Expert Connect


.jpeg)
























































