Reenvío
- SPF192.0.2.80 no está en el SPF de example.com
- DKIMfirma intacta
El informe muestraspf=fail dkim=pass → pass
Firme todo con DKIM; DKIM sobrevive al reenvío. ARC (RFC 8617) ayuda a que los reenviadores den fe.
Verificador DMARC
Verifique el registro DMARC de cualquier dominio como lo lee un servidor de correo receptor: dónde se encuentra la política, qué pasa con el correo que falla, si los informes llegan a alguien y qué necesitan SPF y DKIM antes de aplicar la política.
Fuentes: los registros TXT _dmarc del dominio y de sus dominios superiores, mediante Google Public DNS (Cloudflare 1.1.1.1 detrás) · recorrido del árbol de RFC 9989 · autorización de informes según RFC 9990 · SPF y DKIM de nuestros propios verificadores · no se guarda nada sobre usted
¿Cómo se comprueba un registro DMARC?
Escriba un dominio arriba: el verificador pide al DNS el registro TXT en _dmarc. más el dominio, sube hasta el dominio organizacional cuando no hay ninguno (RFC 9989 §4.10) y muestra qué hace un servidor receptor con el correo que falla.
A mano, consulte el mismo nombre: dig +short TXT _dmarc.paypal.com, o nslookup -type=TXT _dmarc.paypal.com en Windows. Una respuesta que empieza con v=DMARC1 es el registro; con dos respuestas, los receptores no usan ninguna (RFC 9989 §4.10).
dig se detiene ahí. No sube desde un subdominio, no comprueba si las direcciones de informes aceptan los informes y no dice qué RFC sigue un receptor. Eso es lo que añade el verificador.
dig +short TXT _dmarc.example.comTodas las respuestas en el nombre. La que empieza con v=DMARC1 es el registro.
Qué muestra dig y qué no
$ dig +short TXT _dmarc.paypal.com 1
"v=DMARC12; p=reject; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@vali.email; ruf=mailto:d@ruf.agari.com,mailto:MTc4Mzcw@ruf.vali.email3"
$ dig TXT _dmarc.mail.google.com | grep status 4
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
- 1El nombre es _dmarc. más el dominioNo el dominio mismo: un TXT en paypal.com es el lugar de SPF.
- 2Un registro, v=DMARC1 primeroDos registros en un nombre: los receptores descartan ambos (RFC 9989 §4.10).
- 3Tags, separados por ;p es la política; rua y ruf dicen adónde van los informes.
- 4¿Nada aquí? Suba_dmarc.mail.google.com es NXDOMAIN: se aplica el registro de google.com.
Cómo leer el resultado: la vista del receptor
La respuesta va primero, como una frase. Debajo, las pruebas: el registro como lo analizan los receptores, cada tag coloreado sobre sus caracteres exactos y, sobre azul marino, el camino que sigue un servidor receptor para este dominio, hasta lo que hace con el correo que falla.
Sin puntuación: una política en none es una fase, no un fracaso, y la escalera bajo el camino dice qué necesita el siguiente paso.
El veredictoUna frase sobre qué hacen los receptores con el correo que falla, con la política, SPF y DKIM de un vistazo.El registroCada tag coloreado sobre sus caracteres: pase el cursor o toque uno para ver qué hace. Los valores predeterminados, debajo.La vista del receptorCada pregunta DNS que hace un servidor receptor para el dominio, en orden, con su respuesta.Correo que falla DMARCQué hacen los receptores con el dominio, sus subdominios existentes y los nombres que no existen.La escalera de aplicaciónDónde está el dominio entre none y reject, y qué necesita el siguiente paso.¿Para qué se usa DMARC?
DMARC dice a los servidores de correo receptores qué hacer con el correo que usa su dominio en la línea From: pero no puede demostrar que viene de usted, y adónde enviar los informes al respecto (RFC 9989 §4.7).
La prueba es SPF o DKIM, alineado con el dominio del From:: SPF pasa para un dominio de rebote de la misma organización, o una firma DKIM lleva d= su dominio. Un solo resultado alineado basta (RFC 9989 §5.3.5); todo lo demás falla DMARC, y la política del registro decide: entregar, carpeta de spam o rechazar.
Los informes son la otra mitad. Los receptores que respetan rua envían un resumen diario de cada servidor que envió como su dominio, y así encuentra a los remitentes legítimos que olvidó antes de aplicar la política.
Dos mensajes, una línea From:
From: billing@example.comp=reject · rua=mailto:dmarc@example.com
Su factura, enviada mediante un servicio de correomediante un servicio configurado con DKIM personalizado, por lo que firma con d=example.com
- SPFpass · bounces.esp.example (sin alineación)
- DKIMpass · d=example.com (alineado)
- DMARCpass: un resultado alineado basta
Entregado
Una factura falsa desde 203.0.113.9un servidor que example.com nunca autorizó
- SPFfail · 203.0.113.9 no está en la lista
- DKIMnone · sin firma
- DMARCfail → p=reject
Rechazado
550 5.7.1 Email rejected per DMARC policy for example.com
El informe agregado de mañana a dmarc@example.com: 1 mensaje desde 203.0.113.9, SPF fail, DKIM none, disposición reject.
Política DMARC: p=none, quarantine o reject
p=none pide a los receptores que entreguen como siempre el correo que falla y solo lo informen; quarantine les pide que lo traten como sospechoso, normalmente en la carpeta de spam; reject les pide que lo rechacen durante la conversación SMTP.
None es una fase, no un fracaso: RFC 9989 §7.4 sugiere al menos un mes ahí con los informes llegando, y otro tanto en quarantine, antes de reject. Los dominios cuyas personas escriben en listas de correo deberían quedarse en quarantine.
Los grandes proveedores de correo también distinguen: gmail.com y outlook.com publican p=none para el dominio mismo y sp=quarantine para los subdominios, mientras que google.com, yahoo.com y microsoft.com publican reject.
Dónde termina un mensaje falsificado
Entregadop=none
apache.orggmail.comsamsung.com
23 de 192
Carpeta de spamp=quarantine
github.comapple.comamazon.com
30 de 192
Rechazadop=reject
google.compaypal.commicrosoft.com
139 de 192
¿Es DMARC realmente necesario?
Sí, si envía en volumen a Gmail, Yahoo u Outlook.com: los tres exigen un registro DMARC, y p=none basta para cumplir la regla. La aplicación (quarantine o reject) es lo que impide que otros envíen como su dominio, y los logos BIMI la necesitan.
Gmail lo exige desde el 1 de febrero de 2024 a quienes envían más de 5000 mensajes al día a cuentas de Gmail; Yahoo desde febrero de 2024, sin indicar un volumen; Outlook.com desde el 5 de mayo de 2025, por encima de 5000 al día. Sin registro, Gmail responde 4.7.31 (y 4.7.32 cuando From: no está alineado), y Outlook.com rechaza con 550 5.7.515.
Para un dominio que no envía nada, DMARC es la protección más barata que existe: p=reject, un MX nulo y v=spf1 -all, como publica example.com (M3AAWG).
Qué pide cada proveedor de correo a los remitentes masivos
Gmail1 feb 20245000+ al día a cuentas de Gmail
4.7.31 · 4.7.32Yahoofeb 2024sin umbral publicado
DMARC debe pasarOutlook.com5 may 20255000+ al día
550 5.7.515Entregadop=nonecumple la regla de los tres proveedores
Carpeta de spamquarantinefrena la mayor parte de la suplantación · logos BIMI posibles
Rechazadorejectfrena la suplantación en la puerta · BIMI
✓Obligatorio: un registro, p=none o más estrictoiProtección: quarantine o reject
Cómo corregir fallos de DMARC: reenvío, listas de correo, el dominio propio de un proveedor
Encuentre la fuente que falla en sus informes agregados y corríjala en el remitente: haga que firme con DKIM para su propio dominio, o muévala a un dominio de rebote dentro de su organización. Tres causas cubren la mayoría de los fallos.
El reenvío conserva la firma DKIM pero rompe SPF, así que DKIM sostiene el pass. Las listas de correo que editan el mensaje rompen ambos. Y un servicio de correo que firma con su propio dominio pasa DKIM para sí mismo, no para usted: active su DKIM personalizado (normalmente CNAMEs como s1._domainkey) y un Return-Path personalizado.
Tres fallos, qué muestra el informe y la solución
Lista de correo
- SPFenvía el servidor de la lista
- DKIMcuerpo cambiado: el hash falla
El informe muestraspf=fail dkim=fail → fail
Las listas que reescriben From: lo resuelven; los dominios cuyas personas escriben en listas se quedan en quarantine (RFC 9989 §7.4).
El dominio propio de un proveedor
- SPFpass para bounces.esp.example: sin alineación
- DKIMpass para esp.example: sin alineación
El informe muestradkim=pass(esp.example) → fail
Active el DKIM personalizado del proveedor: s1 y s2 de paypal.com son CNAMEs hacia SendGrid, que firma como paypal.com.
DMARC para subdominios: sp y np
Un subdominio sin registro propio recibe la política de su dominio organizacional: sp para los subdominios que existen, np para los nombres que no existen, cada uno con p como respaldo (RFC 9989 §4.7).
Un subdominio que publica su propio registro lo usa para sí mismo. Pero un registro entre un nombre y su dominio organizacional nunca se usa para ese nombre: el árbol de berkeley.edu lo muestra, donde el sp=none de eecs.berkeley.edu no llega a www.eecs.berkeley.edu (RFC 9989 §4.10.1).
np es la ganancia fácil: los nombres que no existen no envían correo real, así que np=reject bloquea las falsificaciones desde ellos aunque p siga en none. Los receptores de RFC 7489 no conocen np y usan sp.
El árbol de berkeley.edu, como lo lee un receptor
berkeley.edup=reject; np=reject; psd=n; rua=…su propio registro · psd=n: el dominio organizacionalRechazado
www.berkeley.edusin registroexiste → sp, ausente → pRechazado
eecs.berkeley.edup=reject; sp=none; rua=…su propio registro → pRechazado
www.eecs.berkeley.edusin registrorecorrido: el registro de eecs.berkeley.edu se omite (no es el dominio organizacional) → el p de berkeley.eduRechazado
nosuch-x7.berkeley.eduNXDOMAINno existe → npRechazado
El sp=none de eecs.berkeley.edu nunca se aplica: un registro entre un nombre y su dominio organizacional no se usa para él (RFC 9989 §4.10.1). El verificador lo señala como un registro que no se usa.
Cómo leer los informes DMARC (rua)
Un informe agregado es un archivo XML diario de cada receptor que enumera todos los servidores que enviaron correo como su dominio, cuántos mensajes y si SPF, DKIM y DMARC pasaron (RFC 9990).
Léalo por fuente: sus propios servidores y servicios deberían mostrar un pass alineado; un servicio conocido que falla necesita su DKIM personalizado; una dirección desconocida que falla con p=reject es suplantación, detenida. Un servicio de informes (dmarcian, Valimail, EasyDMARC, Postmark y otros) convierte miles de archivos en esa lista.
Los informes a una dirección de otro dominio solo llegan si ese dominio está de acuerdo: publica yourdomain._report._dmarc.its-host con v=DMARC1 (RFC 9990 §4). El verificador pregunta por usted y da el registro exacto cuando falta.
Un informe, leído línea por línea
<org_name>google.com</org_name>1
<date_range>23 oct, 0:00 UTC – 24 oct, 0:00 UTC</date_range>
<policy_published>example.com · p=reject</policy_published>2
<source_ip>198.51.100.24</source_ip> <count>412</count> dkim=pass spf=fail → none3
<source_ip>203.0.113.9</source_ip> <count>37</count> dkim=fail spf=fail → reject4
- 1Quién informóUn archivo por receptor y por día (RFC 9990: al menos cada 24 horas).
- 2La política que encontróLo que leyó en _dmarc.example.com.
- 3Correo reenviado, salvado por DKIMSPF falló en el reenviador; la firma alineada pasó DMARC.
- 4Suplantación, detenidaUn servidor desconocido, nada alineado, rechazado.
paypal.comrua=mailto:d@rua.agari.comrua.agari.com
paypal.com._report._dmarc.rua.agari.com TXT "v=DMARC1;"✓ autorizada: los informes lleganServicios de informes que el verificador reconocedmarcianValimailEasyDMARCPostmarkCloudflareMimecastProofpointAgariRed SiftPowerDMARC+6 más
Verificador DMARC: preguntas frecuentes
¿Qué es DMARC?
DMARC es un registro DNS que dice a los servidores de correo receptores qué hacer con el correo que usa su dominio en la línea From: pero falla la alineación de SPF y DKIM: entregarlo, ponerlo en cuarentena o rechazarlo. También indica adónde envían los receptores los informes sobre ese correo. Se publica como un registro TXT en _dmarc más su dominio y lo define RFC 9989, que reemplazó a RFC 7489 en mayo de 2026.
¿Qué muestra un verificador de registros DMARC?
Lee el registro TXT en _dmarc más el dominio, y el de sus dominios superiores cuando no hay ninguno, como lo hace un receptor. Este muestra el registro tag por tag con sus valores predeterminados, la política del dominio, de sus subdominios y de los nombres que no existen, si las direcciones de informes aceptan los informes, y el registro SPF y las claves DKIM del dominio, sin puntuación.
¿Cómo se prueba DMARC?
Verifique arriba el dominio para ver la política publicada: esa es la prueba DMARC que puede responder el DNS. Para ver si un mensaje real pasa, envíe uno a un buzón que usted controle y lea su encabezado Authentication-Results, o pegue los encabezados en el Analizador de Cabeceras de Correo. Un validador DMARC revisa la sintaxis del registro; solo un mensaje muestra si SPF o DKIM se alinearon.
¿Con qué política DMARC conviene empezar?
Empiece con p=none y una dirección rua, para que los receptores le envíen informes diarios sin cambiar la entrega. Corrija cada remitente legítimo que falla, normalmente activando su DKIM personalizado, y luego pase a quarantine y, por último, a reject. RFC 9989 sugiere al menos un mes con p=none y otro tanto con quarantine. Un dominio que no envía correo puede ir directo a p=reject.
¿p=none protege mi dominio?
No. p=none pide a los receptores que traten como siempre el correo que falla, así que un mensaje falsificado solo lo juzgan sus propios filtros de spam. Lo que sí le da son informes, y cumple la regla de Gmail, Yahoo y Outlook.com para remitentes masivos. Considérelo una fase de monitoreo: la protección empieza con quarantine, y reject frena el correo falsificado antes de que llegue a nadie.
¿Qué significa t=y en un registro DMARC?
t=y es el modo de prueba de RFC 9989: los receptores aplican un escalón por debajo de la política publicada, de modo que p=reject actúa como quarantine y p=quarantine como none. No tiene efecto con p=none y no cambia los informes. Los receptores que aún usan RFC 7489 no conocen el tag y aplican la política tal como está escrita. Quite t=y cuando sus informes muestren que todos los remitentes legítimos están alineados.
¿Todavía se usa el tag pct?
RFC 9989 eliminó pct, junto con rf y ri, porque los valores distintos de 0 y 100 se aplicaban de forma inconsistente. Los receptores actuales lo ignoran y aplican la política a todo el correo que falla. Los que aún usan RFC 7489 hacen muestreo: pct=25 con quarantine manda una cuarta parte del correo que falla a spam y entrega el resto. pct=100 es inofensivo; para una fase de prueba, use t=y.
¿Por qué mi dirección rua aparece como «no autorizada»?
Cuando los informes van a un buzón de otro dominio organizacional, ese dominio debe estar de acuerdo publicando un registro TXT llamado yourdomain._report._dmarc.its-host con el valor v=DMARC1 (RFC 9990 §4). Sin él, los receptores que lo comprueban omiten la dirección. El registro va en el DNS del destino, no en el suyo: los servicios de informes publican un comodín para todos sus clientes, así que normalmente se trata de un error de escritura o del buzón de un socio.
¿Los subdominios necesitan su propio registro DMARC?
Normalmente no. Un subdominio sin registro recibe la política de su dominio organizacional: sp para los subdominios que existen, np para los nombres que no existen, ambos con p como respaldo. Publique uno en un subdominio solo cuando necesite una política distinta. Un registro en un nombre intermedio, como team.example.com para www.team.example.com, no se usa para el nombre más profundo.
¿Qué pasa si un dominio publica dos registros DMARC?
Los receptores descartan ambos, así que no se aplica ninguna política DMARC y no se envían informes, aunque uno de los dos diga reject (RFC 9989 §4.10). Suele ocurrir cuando se agrega un registro nuevo sin borrar el anterior, o cuando un proveedor de DNS agrega uno por defecto. Deje un solo registro en _dmarc y borre el otro; el verificador muestra cuál parece el que se pretendía.
¿Por qué falla DMARC si SPF pasa?
DMARC necesita que SPF pase para un dominio que se alinee con la dirección del From:. La mayoría de los servicios de correo envían con su propio dominio de rebote, así que SPF pasa para ellos, no para usted, y no cuenta. Lo mismo ocurre con DKIM firmado con el dominio del servicio. Configure el DKIM personalizado o el Return-Path personalizado del servicio para que el dominio que pasa sea el suyo.
El verificador no muestra ningún registro, pero acabo de agregar uno. ¿Por qué?
Revise primero el campo de host: la mayoría de los paneles DNS quieren solo _dmarc, y escribir allí _dmarc.example.com crea _dmarc.example.com.example.com. Luego espere a que caduque la respuesta anterior: si el nombre ya se había consultado, los resolvedores guardan su NXDOMAIN durante el TTL negativo de la zona, a menudo de 5 minutos a una hora. Un SERVFAIL o un tiempo agotado se muestra como «no se pudo verificar», nunca como sin registro.
¿Le falta algo?Sugiera una función o una herramienta nueva
Herramientas de correo y DNS relacionadas
Verificador de Registro SPF
Valida registros SPF y verifica el conteo de consultas DNS según RFC 7208
Verificador DKIM
Verifica registros DKIM con detección automática de selector
Verificador de registros BIMI
Verifique registros BIMI, logos SVG Tiny PS y certificados VMC, y qué bandejas muestran el logo
Generador de registros DMARC
Cree su registro DMARC para el RFC 9989, partiendo del que publica hoy, y vea qué harán los receptores con el correo que falla.
Analizador de Cabeceras de Correo
Analiza cabeceras de correo sin procesar y rastrea el recorrido del correo
Consulta MX
Encuentra registros MX y detalles del servidor de correo