# DMARC: de p=none a p=reject en 30 días URL canónica: https://brew.new/es/blog/dmarc-p-none-to-reject-in-30-days Autoría: Thomas Park Publicado: 2026-10-04 Actualizado: 2026-10-04 DMARC es un registro TXT en `_dmarc.` 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](https://redsift.com/blog/email-authentication-bespinlabs-redsift), 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](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/) 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. ## Puntos clave - Publica `v=DMARC1; p=none; rua=mailto:...` el día 1. Sin `rua`, los receptores no deben enviar informes agregados. - Todos los remitentes legítimos deben superar SPF o DKIM alineados con el dominio de tu From. En la mayoría de las herramientas, eso significa firmar con DKIM con tu dominio. - Mantén SPF dentro del límite de 10 términos que consultan el DNS, includes anidados incluidos, o todo tu correo recibirá `permerror`. - Pasa a `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. - El RFC 9989 (mayo de 2026) declara histórica la etiqueta `pct`. Olvídate de la subida gradual con `pct=10` y `pct=50`. - BIMI necesita `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. ## Qué cambió en DMARC en 2026 En mayo de 2026, el IETF sustituyó el RFC 7489, un documento informativo (Informational) de 2015, por DMARCbis: el [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), un estándar propuesto (Proposed Standard) que también deja obsoleto el RFC 9091, junto con el [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) para los informes agregados. Aquí importan tres cambios: - **La etiqueta `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). ## Los tres registros de los que depende DMARC 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 y el límite de 10 consultas 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](https://www.rfc-editor.org/rfc/rfc7208.html#section-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. ```dns 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 ` 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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) 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: claves de 2048 bits, selectores y rotación DKIM firma cada mensaje con un dominio `d=` y un selector `s=`; el receptor obtiene la clave de `._domainkey.`. Una herramienta que firma con `d=vendor-mail.example` supera DKIM, pero no DMARC. El [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) 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](https://support.google.com/mail/answer/81126) 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. ```dns 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](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf) de M3AAWG indican rotarlas al menos cada seis meses: 1. Publica el nuevo selector y deja que se propague. 2. Cambia la firma a la nueva clave. 3. Mantén la clave pública antigua en el DNS entre 7 y 30 días para que el correo en tránsito se pueda verificar. 4. Retira el selector antiguo con un `p=` vacío. No lo borres. ### Alineación: relajada o estricta 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 plan de 30 días ![Calendario de DMARC de 30 días en cuatro etapas: del día 1 al 7 en p=none con informes rua; del día 8 al 14, corrección de remitentes; el día 15, p=quarantine; el día 22, p=reject, y BIMI a partir del día 30, con el registro TXT exacto de cada etapa.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *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. ### Días 1 a 7: publica p=none con informes ```dns _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.` 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](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) indican que Microsoft envía informes `rua` y no tiene previsto enviar `ruf`. ### Cómo leer un informe agregado 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: ```xml 192.0.2.123 123 none fail fail bounces.vendor.example example.com vendor.example abc123 pass bounces.vendor.example pass ``` 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. ### Días 1 a 7: encuentra los remitentes desconocidos 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](https://support.google.com/mail/answer/14229414) de Google no exigen alineación para ese correo, así que no dejes que te retrase. ### Días 8 a 14: corrige todas las fuentes legítimas Empieza por el `count` más alto y ve bajando: 1. **Correo corporativo** (Google Workspace, Microsoft 365). Activa DKIM en la consola de administración, con 2048 bits si se ofrece, y confirma que el include del proveedor está en SPF. 2. **ESP y herramientas de marketing.** Configura la autenticación del dominio para que firmen con tu `d=` y, si se ofrece, una ruta de retorno personalizada. 3. **Soporte, facturación y CRM.** Lo mismo que con los ESP. Si alguna herramienta no puede firmar con tu dominio, usa un subdominio para el que sí pueda firmar o su propio dominio. 4. **Herramientas que ya no usas.** Elimina sus includes y sus selectores. Después, vuelve a contar las consultas de SPF. ### Día 15: p=quarantine ```dns _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`. ### Día 22: p=reject ```dns _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. ### Cuándo alargar el plan 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. ### Política de subdominios: sp= y np= `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`. ## Del día 30 en adelante: BIMI 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 ``, 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) | Google | El [borrador de BIMI](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) 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](https://bimigroup.org/creating-bimi-svg-logo-files/) 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](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). Este es el registro, según la [guía de implementación del BIMI Group](https://bimigroup.org/implementation-guide/): ```dns 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. ## Qué exigen Gmail, Yahoo y Microsoft 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](https://support.google.com/mail/answer/81126) y sus [preguntas frecuentes](https://support.google.com/mail/answer/14229414), las [prácticas recomendadas para remitentes de Yahoo](https://senders.yahooinc.com/best-practices/), y el [anuncio de abril de 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) y la [página de soporte sobre el error 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) 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](/es/blog/agent-email-deliverability) y nuestra [guía de entregabilidad](/es/blog/email-deliverability). ## DMARC en un dominio de envío de Brew La [configuración de dominios](https://docs.brew.new/get-started/verify-your-sending-domain) de Brew pide: - **DKIM**, un registro TXT en un selector `._domainkey` dentro de tu dominio de envío. Obligatorio. - **SPF**, un registro MX y otro TXT en `send.<your sending domain>`, la ruta de retorno de Brew. Obligatorio. - **DMARC**, un registro TXT en `_dmarc.<your sending domain>`. Opcional, pero recomendado. - Un **CNAME** para el seguimiento de clics, solo si usas un subdominio de seguimiento personalizado. El dominio puede enviar en cuanto se verifican SPF y DKIM, y Brew sugiere un valor de DMARC acorde: ```dns ; 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. - **Verificado**, cuando se encuentra exactamente un registro válido. 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](/es/blog/transactional-emails) 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. ## Preguntas frecuentes ### ¿Cuánto tiempo debo quedarme en p=none antes de pasar a quarantine? 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. ### ¿Está obsoleta la etiqueta pct de DMARC? 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. ### ¿p=reject bloqueará mi correo reenviado? 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. ### ¿Gmail y Yahoo exigen p=reject? 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. ### ¿Necesito un VMC para BIMI? 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](https://bimigroup.org/understanding-bimi-certificate-types/) indica que algunos proveedores, como Yahoo y Fastmail, también muestran logos autodeclarados sin certificado.