Un plan semana a semana para pasar un dominio de DMARC p=none a quarantine y a reject: registros DNS exactos, cómo leer los informes y qué exige BIMI después.
DMARC es un registro TXT en _dmarc.<your domain> que indica a los receptores qué hacer con el correo que usa tu dominio en el encabezado From y no supera ni SPF ni DKIM alineados, y adónde enviar los informes. p=none solo pide informes, p=quarantine pide a los receptores que traten como sospechoso el correo que falla y p=reject les pide que lo rechacen.
Gmail, Yahoo y Microsoft aceptan p=none de los remitentes masivos, así que muchos dominios lo publican y se quedan ahí: reciben informes sobre quienes los suplantan, pero no los bloquean. El análisis de Red Sift sobre 73,3 millones de dominios, citado en abril de 2026, concluyó que el 14,9 % tenía alguna política DMARC y que el 2,5 % aplicaba p=reject. EasyDMARC, otro proveedor de DMARC, publicó en 2025 que el 62,7 % de las empresas de la lista Fortune 500 con DMARC usaba p=reject, frente al 15,2 % de las empresas de la lista Inc. 5000.
Este es un plan de 30 días para llegar a p=reject, registro a registro, pensado para un dominio que envía desde el correo corporativo, uno o dos ESP, una herramienta de soporte y una de facturación. Treinta días bastan para un subdominio de envío. Un dominio que tu equipo usa para el correo del día a día necesita más tiempo.
v=DMARC1; p=none; rua=mailto:... el día 1. Sin rua, los receptores no deben enviar informes agregados.permerror.p=quarantine el día 15 y a p=reject el día 22, en ambos casos después de una semana de informes sin problemas. Para un dominio que tu equipo usa para el correo del día a día, el RFC 9989 pide un mes en cada una de las dos primeras etapas.pct. Olvídate de la subida gradual con pct=10 y pct=50.p=quarantine o p=reject en el dominio organizativo, nada de sp=none, un logo en SVG Tiny PS y, para Gmail, un VMC o un CMC.En mayo de 2026, el IETF sustituyó el RFC 7489, un documento informativo (Informational) de 2015, por DMARCbis: el RFC 9989, un estándar propuesto (Proposed Standard) que también deja obsoleto el RFC 9091, junto con el RFC 9990 para los informes agregados. Aquí importan tres cambios:
pct pasa a ser histórica. El apéndice A.6 dice que “normalmente no se aplicaba con precisión, salvo que el valor especificado fuera 0 o 100”.t=y sustituye a pct=0. Los receptores aplican un nivel por debajo de tu política, así que p=reject; t=y funciona como quarantine. Es un interruptor de prueba.np es nueva. Cubre los subdominios que no existen en el DNS, y los receptores antiguos deben ignorarla.Además, para encontrar el dominio organizativo, un recorrido del árbol DNS sustituye a la lista de sufijos públicos (Public Suffix List).
Un mensaje supera DMARC cuando supera SPF o DKIM y el dominio que los supera está alineado con el dominio del From. Basta con un resultado correcto alineado.
SPF autoriza servidores para el dominio del sobre (MAIL FROM o ruta de retorno), la única identidad que usa DMARC (no HELO). El RFC 7208, sección 4.6.4, limita a 10 los términos que consultan el DNS: include, a, mx, ptr, exists y redirect, contados a través de todos los includes anidados. ip4, ip6 y all no consumen consultas. Si se supera el límite, el resultado es permerror. La misma sección también permite como máximo dos “búsquedas vacías” (void lookups), que suelen deberse a un include de un nombre de host que ya no existe.
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all"Este registro ya consume 4 consultas sin contar lo que anida cada proveedor, así que resuelve cada include con dig +short TXT <name> hasta el final de la cadena. Para no pasar de 10, elimina las herramientas que ya no usas o da a cada ESP su propio subdominio de ruta de retorno, como bounce.example.com, con su propio cupo de 10. La guía de configuración de SPF de Microsoft recomienda terminar con -all en los dominios que también usan DKIM y DMARC.
Muchos ESP usan por defecto su propio dominio de ruta de retorno, que no está alineado con el tuyo. Configura una ruta de retorno personalizada o apóyate en DKIM.
DKIM firma cada mensaje con un dominio d= y un selector s=; el receptor obtiene la clave de <selector>._domainkey.<d domain>. Una herramienta que firma con d=vendor-mail.example supera DKIM, pero no DMARC.
El RFC 8301 establece que los firmantes deben usar claves RSA de al menos 1024 bits y que deberían usar 2048. Las directrices para remitentes de Google dicen lo mismo para los envíos a cuentas personales de Gmail. Una clave de 2048 bits supera el límite de 255 caracteres de una cadena TXT, así que se publica como varias cadenas entre comillas en un mismo registro, algo que la mayoría de los proveedores de DNS hacen por ti.
s202610._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..."
"...remainder-of-the-2048-bit-key...IDAQAB" )Asigna a cada sistema de envío su propio selector y no reutilices nunca un nombre. Una fecha, como s202610, mantiene el historial legible. Las prácticas de rotación de claves de M3AAWG indican rotarlas al menos cada seis meses:
p= vacío. No lo borres.El RFC 9989 define dos modos:
| Modo | Etiqueta | Dominio que supera SPF/DKIM | Dominio del From | ¿Alineado? |
|---|---|---|---|---|
| Relajado (predeterminado) | aspf=r, adkim=r |
bounce.example.com |
mail.example.com |
Sí, mismo dominio organizativo |
| Estricto | aspf=s, adkim=s |
bounce.example.com |
mail.example.com |
No, los nombres deben coincidir |
| Cualquiera de los dos | vendor.example.net |
example.com |
No |
El RFC 9989 señala que “a casi todos los propietarios de dominios les ha bastado con la alineación relajada”. No incluyas aspf ni adkim. Con la alineación estricta de SPF, la ruta de retorno habitual en un subdominio deja de estar alineada.
El registro de cada etapa. Avanza solo después de una semana de informes sin problemas.
| Días | Política | Qué haces | Condición para avanzar |
|---|---|---|---|
| Del 1 al 7 | p=none |
Publica con rua y haz una lista de todas las fuentes |
7 días de informes de Google, Yahoo y Microsoft |
| Del 8 al 14 | p=none |
Corrige DKIM y SPF y retira los remitentes que no usas | Todas las fuentes legítimas superan SPF o DKIM alineados |
| Del 15 al 21 | p=quarantine |
Vigila si el correo legítimo acaba en cuarentena | 7 días sin fallos de ninguna fuente legítima |
| Del 22 al 30 | p=reject |
Sigue leyendo los informes y añade np=reject |
Una semana estable |
| Del 30 en adelante | p=reject |
Empieza con BIMI | Certificado emitido |
Si en la segunda semana aparece una fuente que nadie puede corregir, quédate en p=none. Rechazar tus propias facturas es peor que aplicar la política tarde.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Los informes son XML comprimido con gzip y llegan al menos una vez al día de cada receptor, así que dirige rua a un procesador de informes, no a una persona. Si la dirección está en otro dominio organizativo, el RFC 9990 indica a los receptores que la ignoren salvo que example.com._report._dmarc.<report domain> la autorice. Los procesadores publican ese registro; para tus propios dominios, añádelo tú.
Publica exactamente un registro DMARC. Si algún asistente de configuración deja dos registros v=DMARC1 en _dmarc.example.com, los receptores descartan los dos.
No uses ruf. El RFC 9989 señala que los receptores que cuidan la privacidad eliminan muchos datos de los informes de fallos o directamente no los envían, y las preguntas frecuentes del anuncio de Microsoft para remitentes de gran volumen indican que Microsoft envía informes rua y no tiene previsto enviar ruf.
El RFC 9990 describe informes XML “diarios (o más frecuentes)”, uno por cada dominio de política. Este es un registro, adaptado de su ejemplo:
<record>
<row>
<source_ip>192.0.2.123</source_ip>
<count>123</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<envelope_from>bounces.vendor.example</envelope_from>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>vendor.example</domain>
<selector>abc123</selector>
<result>pass</result>
</dkim>
<spf>
<domain>bounces.vendor.example</domain>
<result>pass</result>
</spf>
</auth_results>
</record>En policy_evaluated, dkim y spf son resultados de alineación, y disposition es lo que hizo el receptor. auth_results contiene los resultados sin procesar y sus dominios. Aquí ambos se superan para vendor.example, así que ambos fallan la alineación: es un proveedor que envía como tú sin firmar como tú. Activa su DKIM personalizado o la autenticación del dominio.
Agrupa por source_ip, envelope_from y el domain más el selector de DKIM, ordena por count y clasifica los resultados:
| Patrón en el informe | Causa probable | Qué hacer |
|---|---|---|
| DKIM o SPF alineado y superado | Configuración correcta | Nada |
| DKIM y SPF superados para dominios del proveedor | Herramienta SaaS que usa su propia identidad | Activa el DKIM personalizado |
| DKIM alineado superado, SPF fallido, IP de un proveedor de correo o de una lista | Reenvío o lista de correo | Normalmente, nada. El DKIM alineado sobrevive al reenvío |
| Sin DKIM, SPF fallido, IP imposibles de atribuir | Suplantación | Nada. Esto es lo que frena p=reject |
Para atribuir una IP, ejecuta dig -x 192.0.2.123 +short y revisa el selector, que a menudo lleva el nombre del proveedor. Después, pregunta a finanzas, soporte y ventas qué envía correo en nombre de la empresa: facturación, herramienta de soporte, invitaciones de calendario, escáneres de oficina.
El correo reenviado y el de listas fallarán de formas que no puedes corregir, y las preguntas frecuentes para remitentes de Google no exigen alineación para ese correo, así que no dejes que te retrase.
Empieza por el count más alto y ve bajando:
d= y, si se ofrece, una ruta de retorno personalizada.Después, vuelve a contar las consultas de SPF.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"En la práctica, quarantine suele significar la carpeta de spam. Vigila las fuentes legítimas con una disposición quarantine. Para hacer un ensayo, p=quarantine; t=y pide a los receptores que siguen el RFC 9989 que apliquen none, aunque el RFC solo tiene unos meses y todavía no todos los receptores respetan t.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com"Los receptores que respetan p=reject rechazan en la propia sesión SMTP el correo que falla, pero el RFC 9989 les indica que lo pongan en cuarentena cuando la política es su única prueba, así que una parte acaba en spam.
El mismo RFC dice que un dominio con p=reject “NO DEBE (MUST NOT) basarse únicamente en SPF” y debe firmar con DKIM, ya que el reenvío rompe SPF pero no DKIM. Antes, confirma que todas las fuentes tienen DKIM alineado.
Mantén rua para siempre. La nueva herramienta del próximo trimestre aparecerá en tus informes antes que en tu cola de soporte.
El RFC 9989, en su sección 7.4, dice que los dominios cuyos usuarios publican en listas de correo “NO DEBERÍAN (SHOULD NOT)” publicar p=reject, y que los que lo hagan deberían pasar primero “al menos un mes” en p=none y “un periodo igual de largo” en p=quarantine. Esto incluye a la mayoría de los dominios raíz de las empresas, así que, en ellos, dale un mes a cada una de las dos primeras etapas. Un subdominio que solo usa tu ESP no tiene tráfico de listas y puede mantener el ritmo de 30 días.
p cubre el dominio y sus subdominios. sp tiene prioridad sobre p en los subdominios que existen, y np, en los que no existen. Un subdominio con su propio registro usa ese registro, y el RFC 9989 ignora sp en ese caso.
Un subdominio de envío dedicado como mail.example.com, que usa un solo ESP con SPF y DKIM verificados, puede publicar p=reject desde el primer día. p=none; sp=reject en el dominio raíz protege los subdominios mientras terminas con el dominio principal, pero bloquea BIMI.
Los dominios estacionados deberían publicar v=spf1 -all, según la guía de SPF de Microsoft, además de v=DMARC1; p=reject; en _dmarc.
BIMI muestra tu logo junto al correo autenticado en las bandejas de entrada compatibles:
| Requisito | Detalle | Fuente |
|---|---|---|
| Política DMARC | p=quarantine o p=reject en el dominio organizativo y en el dominio del From |
Borrador de BIMI |
| Política de subdominios | Si se publica sp, que no sea none |
Borrador de BIMI |
| Porcentaje | Con quarantine, pct no puede ser inferior a 100 |
Borrador de BIMI |
| Logo | SVG Tiny PS: baseProfile="tiny-ps", version="1.2", un <title>, sin scripts ni referencias externas y sin x= ni y= en la raíz |
BIMI Group |
| Certificado | Gmail necesita un VMC (marca registrada e insignia de verificación) o un CMC (sin marca registrada ni insignia de verificación) |
El borrador de BIMI va por la revisión 14 (mayo de 2026) y sigue siendo un Internet-Draft redactado sobre el RFC 7489, de ahí pct. No incluyas pct ni configures t=y.
La regla del dominio organizativo afecta a quienes envían desde subdominios: con mail.example.com en p=reject y example.com en p=none, los receptores no deben mostrar el logo, así que el dominio raíz también tiene que completar el plan.
Las indicaciones del BIMI Group sobre el SVG recomiendan un logo cuadrado y centrado sobre un fondo sólido, de menos de 32 KB. Google añadió la compatibilidad con CMC en septiembre de 2024. Este es el registro, según la guía de implementación del BIMI Group:
default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"Registrar una marca lleva meses, así que, si vas a necesitar un VMC, empieza ya.
Ninguno de los tres exige aplicar la política, solo un registro DMARC y alineación.
| Gmail | Yahoo | Outlook.com | |
|---|---|---|---|
| Umbral | Cerca de 5000 al día a cuentas personales de Gmail, por dominio principal; permanente una vez alcanzado | Remitentes masivos, sin una cifra concreta | Más de 5000 al día a outlook.com, hotmail.com y live.com, por dominio del From |
| SPF y DKIM | Ambos | Ambos | Ambos deben superarse |
| DMARC | Registro obligatorio; se acepta p=none |
Al menos p=none; rua muy recomendado |
Al menos p=none |
| Alineación | SPF o DKIM | SPF o DKIM; la relajada es suficiente | SPF o DKIM |
| Fallo | Rechazos temporales y permanentes desde noviembre de 2025 | No se indica | 550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level. |
Fuentes: las directrices para remitentes de Google y sus preguntas frecuentes, las prácticas recomendadas para remitentes de Yahoo, y el anuncio de abril de 2025 y la página de soporte sobre el error 5.7.515 de Microsoft. Microsoft empezó a aplicar estos requisitos el 5 de mayo de 2025, después de que una actualización del 29 de abril cambiara la acción, que pasó de enviar el correo a la carpeta de correo no deseado a rechazarlo.
Las preguntas frecuentes de Google dicen que la alineación con SPF y con DKIM a la vez “acabará siendo un requisito para los remitentes”, así que alinea ambos en la segunda semana. Sobre las tasas de bajas y de spam, consulta qué sigue vigente cuando un agente envía tus emails y nuestra guía de entregabilidad.
La configuración de dominios de Brew pide:
._domainkey dentro de tu dominio de envío. Obligatorio.send.<your sending domain>, la ruta de retorno de Brew. Obligatorio._dmarc.<your sending domain>. Opcional, pero recomendado.El dominio puede enviar en cuanto se verifican SPF y DKIM, y Brew sugiere un valor de DMARC acorde:
; dedicated sending subdomain, e.g. mail.example.com
_dmarc.mail.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com"
; apex domain, or a domain Brew can't prove is dedicated
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Un subdominio dedicado recibe p=reject porque nada envía desde él antes de que se verifiquen el SPF y el DKIM de Brew. Un dominio raíz recibe p=none porque es probable que tus otras herramientas también envíen con él, así que sigue el plan anterior. La alineación se mantiene relajada porque la ruta de retorno send.<domain> solo está alineada en modo relajado.
Brew lee el registro _dmarc.<sending domain> tal como está publicado al añadir el dominio, al verificarlo y en cada nueva comprobación. Dominios muestra el resultado, igual que get_domain_health por MCP y GET /v1/domains/{domainId}/health:
dmarc_missing, una advertencia con el registro exacto que debes añadir.dmarc_invalid, cuando hay dos registros DMARC en ese nombre, o una versión o una política incorrectas, o etiquetas duplicadas. Indica qué registro debes eliminar.La configuración automática del DNS solo escribe DMARC cuando no existe ningún registro, así que nunca crea un duplicado. La comprobación se hace en el dominio de envío, no en su dominio superior, así que da a cada subdominio de envío su propio registro, incluido uno para el correo transaccional si separas ambos tipos como recomienda la documentación. Tu procesador de rua es donde lees los informes y decides cuándo pasar a reject.
Hasta que una semana completa de informes muestre que todas las fuentes legítimas superan SPF o DKIM alineados; en un subdominio de envío, suele ser entre una y dos semanas. Para un dominio que tu equipo usa para el correo del día a día, el RFC 9989 pide al menos un mes. Pasar dos años en p=none sin que nadie lea los informes no sirve de nada.
Sí. El RFC 9989 clasifica pct como “histórica” y sustituye sus únicos valores fiables por t: t=y equivale a pct=0, y t=n, a pct=100. Los receptores antiguos pueden seguir leyendo pct, pero nunca aplicaron los valores intermedios de forma coherente, así que avanza en pasos completos.
El reenvío simple suele romper SPF, pero no DKIM, así que el DKIM alineado sigue superándose. Las listas que modifican el asunto o el pie de página rompen DKIM, y algunas reescriben el encabezado From para compensarlo. Tener DKIM alineado en todas partes es tu mejor protección.
No. Ambos exigen a los remitentes masivos que publiquen DMARC y aceptan p=none, igual que Microsoft por encima de 5000 mensajes al día a Outlook.com. Aplicar la política frena la suplantación y es obligatorio para BIMI, pero ninguno de los tres lo exige.
Para Gmail, necesitas un VMC, que requiere una marca registrada y muestra una insignia de verificación, o un CMC, que muestra el logo sin insignia. El BIMI Group indica que algunos proveedores, como Yahoo y Fastmail, también muestran logos autodeclarados sin certificado.
