Verificador de registros DMARC — validación instantánea contra la política publicada de tu dominio
Escribe un dominio. El navegador consulta DNS sobre HTTPS directamente contra el resolver 1.1.1.1 de Cloudflare y parsea el registro TXT resultante en _dmarc.tudominio.com. Verás el registro crudo, la política parseada, las direcciones de informes agregados y forenses, los modos de alineación, la política de subdominio y cualquier problema de sintaxis u operativo — incluyendo los que bloquean a Gmail, Yahoo y Microsoft Outlook para aceptar correo en volumen bajo los requisitos de remitente 2024-2026. Sin cuenta, sin telemetría, sin límites de tasa; la consulta ocurre enteramente en tu navegador.
Verifica un dominio
Introduce cualquier dominio — el tuyo, el de un competidor, un proveedor que estés evaluando. La consulta corre en tu navegador contra el resolver público DNS sobre HTTPS de Cloudflare.
DNS sobre HTTPS vía cloudflare-dns.com · Sin datos enviados a nuestros servidores
DMARC es la capa de política sobre SPF y DKIM — el lugar donde dices a los receptores qué hacer con correo que falla autenticación o alineación
El registro DMARC es una única entrada TXT en _dmarc.tudominio.com en tu DNS. Es una declaración corta de política, definida en RFC 7489, que los receptores como Gmail, Outlook y Yahoo leen cuando evalúan correo entrante que dice venir de tu dominio. El receptor corre las verificaciones SPF y DKIM primero; DMARC luego pregunta dos cosas más. Primero, ¿pasó al menos una de esas verificaciones con el dominio en la cabecera From: — el requisito de alineación que impide que un atacante pase SPF en su propio dominio mientras dice ser tú. Segundo, ¿qué debe hacer el receptor si ninguna verificación pasó alineada: entregar normalmente (p=none, solo monitorización), enrutar a spam (p=quarantine) o rechazar directamente en tiempo SMTP (p=reject).
El registro también dice a los receptores dónde enviar informes agregados — los resúmenes XML diarios que muestran qué remitentes están usando tu dominio y si pasan o fallan — vía el tag rua. Un segundo tag, ruf, solicita informes forenses de fallo, aunque la mayoría de receptores principales dejó de enviarlos en 2017-2018 por preocupaciones de privacidad. Dos tags de modo de alineación controlan si las verificaciones SPF y DKIM necesitan alinearse de forma estricta (coincidencia exacta de dominio) o relajada (coincidencia de dominio organizacional): aspf y adkim, ambos por defecto en relajado. Un tag de política de subdominio sp establece la política para subdominios; sin él, los subdominios heredan la política del padre. Un tag de porcentaje pct aplica la política a una fracción del correo fallido — útil durante despliegues de enforcement pero fuente común de confusión cuando los remitentes lo olvidan tras completar el despliegue.
El panorama de enforcement 2024-2026 ha hecho material la diferencia entre niveles de política. Desde febrero de 2024, Gmail y Yahoo exigen a remitentes en volumen (5.000+ mensajes diarios a cuentas Gmail) publicar un registro DMARC con política mínima p=none; sin uno, el correo es rechazado. Microsoft Outlook siguió en mayo de 2025 con el mismo umbral y un código de rechazo SMTP 550 5.7.15 para correo en volumen no conforme. La v2 de Postmaster Tools de Gmail en octubre de 2025 añadió un indicador binario "Compliance Status" que lee DMARC a nivel enforcement (p=quarantine o p=reject) como una señal de confianza más fuerte que solo monitorización. La progresión de p=none a enforcement ya no es opcional para remitentes que tratan de mantener colocación en bandeja a escala.
Para el contexto regulatorio en LATAM y España, esto se entrecruza con el marco propio. La AEPD ha priorizado en sus guías 2024-2025 la autenticación de dominio como medida técnica razonable bajo el Art. 32 RGPD; la ANPD brasileña hace énfasis análogo bajo LGPD; el INAI mexicano lo incorpora en sus criterios de transferencia y seguridad. Para una entidad financiera mexicana bajo la LFPDPPP, una fintech argentina bajo la Ley 25.326, o un SaaS chileno bajo la reforma a la Ley 19.628, publicar y mantener DMARC en enforcement es parte del estándar mínimo razonable que un auditor de seguridad de cliente B2B esperará ver. La herramienta de arriba te dice en qué lado de esa línea está tu registro, y el resto de esta página recorre qué arreglar cuando devuelve problemas.
Cada tag que el verificador parsea, qué significa, y qué valor deberías típicamente usar
Registro de ejemplo en enforcement
v=DMARC1; p=reject; rua=mailto:dmarc@ejemplo.com; ruf=mailto:forense@ejemplo.com; sp=reject; adkim=s; aspf=s; pct=100; fo=1
v=DMARC1 Identificador de versión. Siempre DMARC1. Debe ser el primer tag. Los receptores ignoran el registro si falta o está malformado.
p=none | quarantine | reject Política para correo fallido. none = solo monitorizar, quarantine = enrutar a spam, reject = bloquear en tiempo SMTP. La escala de señal de confianza 2024-2026 corre none → quarantine → reject.
rua=mailto:direccion Dónde enviar los informes agregados XML — el resumen diario de resultados de autenticación de todos los remitentes que usan tu dominio. Crítico para visibilidad. Múltiples direcciones permitidas, separadas por comas.
ruf=mailto:direccion Destino de informes de fallo (forenses). La mayoría de receptores principales dejó de enviarlos hacia 2017-2018 por privacidad. Opcional y cada vez más ignorado — configúralo si tu plataforma DMARC lo requiere; no esperes volumen.
sp=none | quarantine | reject Política de subdominio. Si se omite, los subdominios heredan p. Configurar sp=reject mientras p=quarantine es un patrón común de despliegue — estricto en subdominios no usados, gradual en el dominio principal.
adkim=r | s · aspf=r | s Modos de alineación. r (relajado, default) permite coincidencia de dominio organizacional — mail.ejemplo.com alinea con ejemplo.com. s (estricto) requiere coincidencia exacta. Estricto atrapa más spoofing pero rompe más remitentes legítimos que usan subdominios.
pct=N (1-100) Porcentaje de correo fallido al que se aplica la política. pct=10 con p=quarantine significa cuarentena al 10% de fallos, tratar el resto como p=none. Usado durante despliegues; debería volver a pct=100 en estado estable.
fo=0 | 1 | d | s Opciones de informes de fallo. fo=1 envía informe cuando SPF o DKIM falla (más útil). fo=d solo fallo DKIM, fo=s solo SPF, fo=0 solo cuando ambos fallan. El default 0 produce muy pocos datos para uso diagnóstico.
Los ocho problemas que vemos con más frecuencia al correr este check contra dominios de cliente
No hay registro publicado
El resultado más común en la primera verificación. Cero protección, y desde febrero de 2024 bloquea entrega a cuentas Gmail y Yahoo para remitentes en volumen (5.000+ mensajes diarios). Empieza con v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; para iniciar monitorización; eso te da visibilidad sobre quién envía bajo tu dominio antes de endurecer la política.
Política atascada en p=none durante años
El registro existe pero la política nunca se movió de monitorización. La v2 de Postmaster Tools de Gmail desde octubre de 2025 lee DMARC a nivel enforcement (quarantine o reject) como señal de confianza más fuerte que p=none. Si tus informes agregados muestran alineación limpia para remitentes conocidos durante 30-90 días, mueve a p=quarantine; pct=10, luego escala pct durante 4-8 semanas, luego a p=reject.
Múltiples registros DMARC
Dos o más registros TXT en _dmarc.tudominio.com. Por RFC 7489, esto causa que los receptores traten la política como indefinida y salten enforcement enteramente. Suele pasar cuando una herramienta de seguridad añade un registro sin quitar el viejo. Consolida en un solo registro.
Errores de sintaxis
Falta de punto y coma, valores de tag inválidos, cadena de versión incorrecta, email malformado en rua. Los receptores parsean estrictamente; un único error de sintaxis causa que el registro sea ignorado. El error más común que vemos es un typo en v=DMARC1 (v en minúscula, falta el 1, o DMARC2 por confusión con el draft IETF DMARCbis).
Sin dirección rua — sin visibilidad
Un registro DMARC sin rua sigue haciendo enforcement de la política en los receptores, pero no recibes informes agregados. Estás volando ciego sobre qué remitentes legítimos usan tu dominio y si pasan autenticación. Siempre configura rua — a una bandeja que realmente lees, o a una plataforma de monitorización DMARC que parsea el XML por ti.
Destino de informe externo no autorizado
Si tu rua o ruf apunta a un dominio que no posees (una plataforma DMARC como Postmark, dmarcian, EasyDMARC, o nuestra propia monitorización), el dominio receptor necesita un registro TXT separado en tudominio.com._report._dmarc.sudominio.com autorizando el reporting cruzado de dominios. La mayoría de plataformas lo configuran por ti; algunas requieren configuración manual.
Sin política de subdominio en subdominios aparcados o no usados
Sin sp, los subdominios heredan la política del padre. Si tu padre está en p=none durante un despliegue lento, cada subdominio — incluyendo los que no envías pero los atacantes pueden suplantar — está también en p=none. Añade sp=reject temprano; no cuesta nada para subdominios que no usas.
Valor pct atascado de despliegue antiguo
Registros con p=reject; pct=10 son comunes — el equipo desplegó quarantine, escaló pct, movió a reject, y olvidó devolver pct al 100. Resultado: solo el 10% del correo fallido es realmente rechazado. Restaura pct=100 en estado estable; tienes la política que querías solo cuando pct coincide.
Correr la verificación es el paso uno. Los siguientes son ingesta de informes agregados, arreglos de alineación para remitentes mal comportados, y el despliegue a enforcement
Un registro DMARC por sí solo no mejora deliverability — solo añade una declaración de política que puede o no reflejarse en decisiones del receptor. El trabajo real para llegar a p=reject de forma segura es: ingerir informes agregados diarios durante 30-90 días para ver quién envía bajo tu dominio, arreglar la alineación SPF y DKIM para remitentes legítimos que aparecen fallando (plataformas de newsletter, ESPs transaccionales, herramientas de marketing, sistemas de nómina, software de tickets de soporte — cada dominio tiene una cola larga), luego escalar pct en etapas y vigilar daños colaterales antes de declarar enforcement.
La herramienta arriba te da la foto de política. El trabajo más largo es lo que hacemos día a día para clientes gestionados — parsing de informes agregados, identificación de remitentes, remediación de alineación, y el despliegue de monitorización a quarantine a reject sin bloquear al proveedor de nómina de la propia empresa tres días antes del ciclo. Si corres esto en tu propio dominio y el resultado es p=none tras años, esa es la conversación a tener, no la de qué registro DMARC publicar.
Lo que los equipos preguntan al correr esta verificación por primera vez
¿Esta herramienta envía mis datos a vuestros servidores?
+
No. La consulta corre enteramente en tu navegador usando el resolver público DNS sobre HTTPS de Cloudflare en cloudflare-dns.com/dns-query. El dominio que escribes va a la infraestructura DNS de Cloudflare — el mismo camino de consulta que tu navegador usa para cualquier resolución DNS — y la respuesta es parseada localmente. Nunca vemos la consulta, el resultado, ni ningún otro dato de navegación. Puedes verificarlo en la pestaña de red de las herramientas de desarrollador de tu navegador; no hay peticiones a dominios de Authorize Hosting durante la verificación.
¿Es suficiente p=none para satisfacer los requisitos de remitente en volumen de Gmail y Yahoo?
+
Sí, técnicamente. Los anuncios de Gmail y Yahoo de febrero de 2024 establecieron el mínimo en "tener un registro DMARC con al menos p=none." Microsoft Outlook siguió el mismo umbral en mayo de 2025. Así que p=none es el boleto de entrada; sin él, el correo a esos receptores es rechazado en tiempo SMTP.
El matiz es que desde el lanzamiento de Postmaster Tools v2 de Gmail en octubre de 2025, el indicador binario "Compliance Status" da una señal de confianza más fuerte para DMARC a nivel enforcement (p=quarantine o p=reject) que para monitorización. La colocación en bandeja, los umbrales de queja y la recuperación de reputación están todos en juego. p=none te pasa la puerta; p=reject con informes agregados limpios te da la mejor mesa.
¿Cuánto tiempo deberíamos quedarnos en p=quarantine antes de mover a p=reject?
+
Depende de la forma de tu programa de envío, pero el patrón típico que vemos en migraciones gestionadas es 30 días en p=none para reunir informes agregados, luego un despliegue graduado de p=quarantine: pct=10 por 1-2 semanas, pct=25 por 1-2 semanas, pct=50 por 2 semanas, pct=100 por 2-4 semanas, luego mover a p=reject; pct=100. El despliegue completo de sin-DMARC a enforcement es típicamente 3-4 meses. Más corto es posible para remitentes con infraestructura simple y bien controlada; más largo es normal para empresas con docenas de fuentes legítimas de envío que necesitan remediación de alineación.
Tenemos p=reject y aún vemos intentos de spoofing pasando. ¿Cómo?
+
Varias posibilidades. Primero, p=reject solo protege contra spoofing directo de dominio — atacantes usando tu dominio exacto en la cabecera From:. Dominios lookalike (tu-empresa.co frente a tu-empresa.com, o variantes homoglyph) y spoofing de display name (donde el nombre visible dice "Tu Empresa" pero la dirección From es atacante@gmail.com) son superficies de ataque completamente diferentes que DMARC no aborda.
Segundo, algunos receptores — particularmente servidores pequeños o autoalojados, cierto software de listas de correo, y algunos gateways enterprise heredados — no aplican DMARC para nada, o lo aplican de forma inconsistente. Tus informes agregados te dicen qué receptores honran tu política; la cola larga de receptores pequeños puede mostrar fallos llegando de todos modos.
Tercero, DMARC tiene interacciones conocidas con listas de correo y reenvío. Un mensaje legítimo reenviado a través de una lista falla DMARC a menudo en el segundo salto porque la lista reescribe el cuerpo o cambia el From. ARC (Authenticated Received Chain) fue diseñado para abordar esto pero la adopción es desigual. Si tus informes muestran fallos DMARC correlacionados con actividad de listas, eso es lo que estás viendo.
¿Podemos usar este verificador para dominios de cliente que no poseemos?
+
Sí. Los registros DMARC son registros DNS públicos — cualquiera puede consultarlos para cualquier dominio. Agencias, MSPs y consultores corren verificaciones como esta rutinariamente como parte del onboarding de clientes. El verificador no se autentica contra el dominio de destino de ninguna manera; solo realiza una consulta DNS pública. La única diferencia entre verificar tu propio dominio y el de un cliente es que puedes actuar sobre el resultado para el tuyo.
¿Qué hay de DMARCbis — la actualización propuesta a DMARC?
+
DMARCbis es el draft IETF que actualiza RFC 7489 — añadiendo una consulta consciente de Public Suffix List para el dominio organizacional, formalizando tree walking para resolución de subdominios, depreciando pct a favor de despliegues nombrados de porcentaje, y endureciendo requisitos de formato de informe. A mediados de 2026 el draft sigue en proceso IETF; ningún receptor principal ha señalado que requerirá sintaxis específica de DMARCbis. La cadena de versión sigue siendo v=DMARC1; no publiques registros declarando DMARC2 o DMARCbis — no son válidos y los receptores los ignorarán.