Entregabilidad de EmailEjemplo de registro DMARC: Plantillas para cada políticaEjemplos de registros DMARC para p=none, quarantine y reject, además del error de alineación que arruina la autenticación incluso cuando SPF y DKIM pasan. Listos para copiar y pegar para remitentes B2B.
Risotto lidera en Zero Trust con un enfoque 'runtime-first', monitoreo eBPF, aplicación dinámica de privilegios mínimos y automatización de cumplimiento.
Risotto lidera en Zero Trust con un enfoque 'runtime-first', monitoreo eBPF, aplicación dinámica de privilegios mínimos y automatización de cumplimiento.
Risotto lidera en Zero Trust con un enfoque 'runtime-first', monitoreo eBPF, aplicación dinámica de privilegios mínimos y automatización de cumplimiento.
Aquí tienes el registro DMARC operativo más sencillo:
Publícalo como un registro TXT en _dmarc.tudominio.com. Eso es todo. Tu dominio ya cuenta con un registro DMARC válido que cumple con el requisito mínimo de Google, Yahoo y Microsoft.
Si tienes prisa, ese registro es todo lo que necesitas por ahora. Vuelve al resto de esta guía cuando estés listo para entender qué hace cada etiqueta, cómo pasar a políticas más estrictas sin romper tus correos y por qué DMARC puede seguir fallando aunque SPF y DKIM den luz verde.
Para los demás: vamos a repasar qué significa realmente un registro DMARC, qué hace cada nivel de política, el error de alineación en el que cae la mayoría de los remitentes y cómo encaja DMARC en tu configuración general de entregabilidad como remitente B2B.
Un registro DMARC es un único registro DNS TXT que se publica en un subdominio específico de tu dominio:
El registro útil más sencillo tiene este aspecto:
Tres partes. Eso es todo lo que necesitas para empezar.
Esto establece la versión. Todo registro DMARC debe empezar con esto. Debe aparecer primero, exactamente como está escrito. Nada antes.
Esta es la política. Le indica a los servidores de correo receptores qué hacer con los mensajes que no pasan la verificación DMARC. Con p=none, la respuesta es: nada. El correo fluye con normalidad. Recopilas datos. Ningún correo se bloquea o filtra por culpa de este registro.
Exactamente por eso es el punto de partida ideal. Activas el monitoreo sin tocar la entrega.
Esto le indica a los proveedores de correo dónde enviar tus informes DMARC agregados: resúmenes diarios en XML que muestran qué sistemas están enviando correos con tu dominio y si están pasando la autenticación. Reemplaza la dirección por una que revises de verdad.
Sin rua=, no tienes visibilidad. El registro funciona, pero estás a ciegas.
Cada registro DMARC contiene una etiqueta de política (p=) que le indica a los servidores receptores qué hacer cuando un correo falla en la autenticación. Hay tres opciones. Así es como se ve cada una y cuándo debes usarla. Para profundizar más en cómo funcionan juntos SPF, DKIM y DMARC, consulta nuestra guía sobre cómo implementar SPF, DKIM y DMARC.
No se toma ninguna medida con los mensajes que fallan. El correo sigue fluyendo con normalidad. Recibes informes diarios que muestran cada sistema que envía correos usando tu dominio, si están pasando la autenticación y de dónde vienen los fallos.
Usa p=none cuando:
Esto es también lo mínimo que exigen Google y Yahoo para los remitentes masivos (más de 5000 correos al día), y Microsoft desde mayo de 2025 para los correos dirigidos a direcciones de Outlook, Hotmail y Live.
Los correos que no pasan la verificación se consideran sospechosos. La mayoría de los servidores de correo los envían a la carpeta de spam o correo no deseado en lugar de bloquearlos por completo.
Usa p=quarantine cuando:
p=reject - Aplicación estricta
Los correos que no pasan la verificación se rechazan antes de llegar al destinatario. Es la protección más potente contra la suplantación de identidad.
Usa p=reject solo cuando:
Este es el problema de DMARC más común que vemos, y es el que la competencia o bien esconde en un apéndice o pasa por alto por completo. Así que vamos a abordarlo directamente.
Que SPF y DKIM pasen no es suficiente. Para que DMARC pase, al menos uno de esos resultados también debe coincidir con el dominio que tus destinatarios ven en la dirección De: (From).
Esto es lo que significa la alineación en la práctica:
El detonante más común: conectas un CRM, un servicio de asistencia (helpdesk), una herramienta de cold outreach o una plataforma de marketing. Esa plataforma envía correos usando tu dominio en la dirección De:, pero se autentica bajo su propio dominio entre bambalinas. SPF y DKIM pasan para el dominio de la plataforma, pero no se alinean con tu dominio del campo De. DMARC falla.
Vemos esto constantemente cuando los equipos añaden nuevas herramientas sin actualizar su configuración de DNS. La solución es configurar cada plataforma de envío para que se autentique específicamente bajo tu dominio, y no bajo su propia infraestructura compartida.
Un registro DKIM por cada Proveedor de Servicios de Correo (ESP), no por herramienta. Si un ESP envía correos para varias herramientas de tu stack, necesitas una entrada DKIM para ese ESP, configurada para firmar con tu dominio.
Cómo diagnosticar un fallo de alineación:
Si ves fallos de DMARC que no te cuadran, nuestra guía sobre cómo solucionar fallos de DMARC repasa las causas específicas y sus arreglos.
La mayoría de los dominios pueden empezar con el ejemplo básico de p=none anterior. Pero algunas situaciones requieren un enfoque diferente.
Si un dominio nunca envía correos (dominios aparcados, registros defensivos, dominios de protección de marca), el registro DMARC correcto es un rechazo estricto sin necesidad de dirección de informes:
Esto le indica a cada proveedor de buzón que rechace cualquier correo que pretenda venir de este dominio. Como nunca debería enviarse nada legítimo, no hay riesgo de interrumpir correos reales.
Este es el caso de uso que la mayoría de las guías de DMARC pasan por alto por completo.
Si haces cold outreach B2B, deberías usar dominios secundarios, no subdominios de tu dominio principal. Los subdominios comparten la reputación con el dominio principal. Un problema de deliverability en un subdominio afecta también a tu dominio principal. Los dominios secundarios (tuempresa.co, tuempresa.io) están totalmente separados y construyen su propia reputación de forma independiente.
Quédate con extensiones conocidas: .com, .co, .io. Evita TLDs exóticos. Despiertan sospechas antes de que tu correo siquiera llegue.
Cada dominio secundario necesita su propia configuración de autenticación completa:
Para el cold outreach B2B, DMARC es solo la capa de autenticación. La capa de reputación es la que realmente hace que los correos pasen de spam a la bandeja de entrada. Descubre cómo el email warmup construye la reputación de remitente que tus dominios secundarios necesitan.
Por defecto, los subdominios heredan la política DMARC del dominio principal. Si quieres un control explícito, usa la etiqueta sp=:
p= se aplica a tu dominio principal. sp= se aplica a todos los subdominios. Si tienes subdominios sin usar que nunca deberían enviar correos, bloquearlos con sp=reject evita que se utilicen para la suplantación de identidad (spoofing).
El registro DMARC tarda unos minutos en publicarse, pero el despliegue lleva semanas. Los equipos que suelen tener problemas son casi siempre los que se saltan la fase de monitoreo y descubren que faltan remitentes solo cuando los correos legítimos empiezan a rebotar.
Esta es la secuencia que funciona:
Déjalo así durante al menos dos o cuatro semanas. Confirma que los reportes estén llegando y revísalos.
Aquí es donde la mayoría de las organizaciones se llevan una sorpresa. Además de tu proveedor principal de correo, revisa:
Los reportes DMARC suelen ser el primer lugar donde los equipos descubren sistemas de envío que ya ni recordaban que existían.
Para cada plataforma de envío que encuentres:
Haz este cambio solo cuando tus reportes muestren una autenticación limpia en todos tus remitentes. Sigue monitoreando. Vigila si algún correo legítimo cae en la bandeja de spam.
Múdate a p=reject solo después de meses de reportes limpios, con cada remitente verificado, cualquier problema de alineación resuelto y un proceso establecido para evaluar nuevas herramientas antes de que empiecen a enviar correos.
Una nota sobre la etiqueta pct=: es posible que veas registros DMARC que usan pct=10 o pct=25 para aplicar la política solo a un porcentaje de los mensajes. Las recomendaciones actuales desaconsejan depender de esto, ya que los proveedores de correo no lo implementan de forma uniforme. Un despliegue gradual de p=none a p=quarantine y luego a p=reject es mucho más fiable.
Los informes DMARC son la forma de ver qué pasa después de que tu registro esté activo. Si no activas los informes, puedes aplicar políticas, pero no sabrás qué sistemas están pasando, fallando o intentando enviar correos usando tu dominio.
Los informes agregados son resúmenes diarios en XML que envían los proveedores de buzones participantes. Te muestran quién envía correos con tu dominio, qué IPs están involucradas y si pasan o fallan SPF, DKIM y DMARC.
Este es el que necesitas. Para la mayoría de las organizaciones, con rua= es suficiente.
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
Apunta a un buzón dedicado que vayas a revisar de verdad. Los proveedores suelen enviar informes una vez al día. Prepárate para recibir archivos XML que requieren un análisis manual o una herramienta de informes para leerlos fácilmente.
Los informes forenses contienen detalles sobre fallos de autenticación individuales. Son opcionales, los proveedores no los envían de forma constante y plantean dudas sobre privacidad en algunas regiones. Para la mayoría de los remitentes, rua= es la configuración adecuada.
Si tu dirección rua= usa un dominio diferente al que utilizas para enviar, el dominio de recepción debe publicar un registro DNS que se autorice a sí mismo para recibir informes en tu nombre. Sin esto, es posible que los informes no se entreguen, y lo harán sin previo aviso.
Comprueba siempre que los informes llegan a los pocos días de publicar tu registro DMARC. Si no es así, revisa primero este requisito de autorización.
DMARC es necesario. Pero no es suficiente.
Google, Yahoo y Microsoft usan la alineación de SPF, DKIM y DMARC para decidir si un mensaje está autenticado correctamente. Para quienes envían grandes volúmenes, esta capa de autenticación ya es imprescindible. Sin ella, es mucho más probable que tus correos se marquen como basura, se rechacen o se consideren sospechosos antes de que siquiera se evalúen el contenido y la reputación. Pero eso no te asegura la bandeja de entrada. Esa decisión depende de tres pilares:
La autenticación es lo mínimo exigido. Es lo que te permite saltar al campo de juego. La reputación es lo que hace que tus correos pasen de la carpeta de spam a la bandeja de entrada.
Para el cold outreach B2B en concreto, esto importa muchísimo. Estás enviando correos a personas que no te conocen de nada. No hay una relación previa, ni historial de interacción, ni reconocimiento de marca con su proveedor de correo. Un registro DMARC limpio le dice a los proveedores que tu correo es legítimo y viene de ti. Pero no les dice en absoluto que tu correo merezca la pena.
Por eso cualquier dominio de outreach secundario necesita email warmup, y no solo autenticación. MailReach mejora la reputación de tu remitente mediante interacciones positivas reales con una red de más de 30 000 buzones activos de Google Workspace y Microsoft 365. Es la capa de reputación que trabaja junto a la autenticación para que tus correos lleguen de verdad a la bandeja de entrada. Echa un vistazo a cómo funciona el email warmup y por qué la calidad de la red es lo que diferencia un calentamiento eficaz del resto.
El ejemplo más sencillo es v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com, publicado como un registro TXT en _dmarc.tudominio.com. v=DMARC1 establece la versión, p=none indica a los servidores de correo que solo supervisen sin tomar medidas, y rua= es a donde van tus informes agregados. Este es el mínimo requerido por Google, Yahoo y Microsoft para los remitentes masivos.
Para empezar y cumplir con los requisitos de los proveedores de correo, sí. p=none también es el punto de partida correcto porque te da visibilidad sin alterar el envío de correos. Para entornos de envío complejos con múltiples plataformas y proveedores, un p=quarantine bien supervisado suele ser el objetivo ideal a largo plazo. No te precipites a usar p=reject hasta que tus informes confirmen que cada remitente está limpio.
Alineación. Que SPF y DKIM pasen la validación no es suficiente: el dominio autenticado también tiene que coincidir con el dominio que aparece en tu dirección De: (From:). Esto suele fallar cuando una herramienta de terceros (CRM, servicio de asistencia, plataforma de outreach) autentica el correo bajo su propio dominio en lugar del tuyo. La solución es configurar cada plataforma para que firme y autentique usando específicamente tu dominio.
Normalmente no. Un solo registro en tu dominio principal rige los subdominios por defecto. Usa la etiqueta sp= para establecer una política específica para subdominios; por ejemplo, sp=reject para proteger los subdominios desde los que nunca envías correos. Sin embargo, los dominios secundarios de outreach son completamente independientes y cada uno necesita su propio registro DMARC.
Sí. Configura rua=mailto: en cualquier bandeja de entrada que controles y recibirás informes agregados gratis. El problema es que llegan como archivos XML sin procesar, lo cual sirve para un dominio pequeño pero se vuelve difícil de analizar a gran escala. Para un solo dominio de envío con actividad limitada, tu propia bandeja de entrada está bien.
DMARC es necesario pero no suficiente. Sin él, Google, Yahoo y Microsoft pueden rechazar o mandar a spam tu correo antes de que siquiera sea evaluado. Pero tenerlo no te garantiza llegar a la bandeja de entrada principal; eso depende de tu reputación como remitente y del contenido. DMARC soluciona el pilar de la autenticación. La llegada a la bandeja de entrada depende de los tres. Echa un vistazo a nuestra guía sobre cómo mejorar la deliverability de tus emails para tener una visión completa.
Sí. Desde el 5 de mayo de 2025, Microsoft exige SPF, DKIM y una política DMARC mínima de p=none a los remitentes masivos (más de 5,000 correos al día) que envíen a direcciones de Outlook.com, Hotmail.com y Live.com. Los mensajes que no cumplen con esto se envían inicialmente a la carpeta de spam, y posteriormente son rechazados. Google y Yahoo adoptaron requisitos similares en febrero de 2024. Los tres principales proveedores de correo exigen ahora DMARC para el correo masivo.
Cada correo en spam equivale a un cliente potencial perdido. Empieza a mejorar tu posicionamiento en la bandeja de entrada hoy mismo con las pruebas de spam y el warmup de MailReach.
Seguir las reglas no es suficiente: descubre dónde aterrizan tus emails y qué los está frenando. Verifica tu puntuación de spam con nuestra prueba gratuita y mejora la entregabilidad con el warmup de MailReach.
Sin el warmup adecuado, tus mejores campañas no sirven de nada. Puedes empezar probando dónde aterrizan tus emails y empezar a mejorarlo hoy mismo.
Ejemplo de registro DMARC: Plantillas para cada política
.avif)
¿Qué son las directrices para remitentes de Gmail? (Guía 2026)
Vamos a revelarte la estrategia de envío y warmup de cold email más eficiente para evitar caer en spam. Prepárate, esto es súper potente para mejorar la deliverability de tus cold emails y conseguir grandes resultados en tus campañas.
Entregabilidad de Email con SendGrid: Lo que los remitentes B2B de cold email necesitan saber en 2026
Rotación de claves DKIM: La guía sincera (y por qué la mayoría de los remitentes de cold outreach no la necesitan)
Smart DMARC: La clave para una mejor entregabilidad y protección de tus emails
