DMARC de p=none a p=reject sin perder correo legítimo: el despliegue por etapas (2026)

Publicado 2026-07-08

Cifras a fecha de 2026-06-29 · metodología v7. Datos agregados del censo sobre 261 millones de dominios calificados. Consulte cómo calificamos.

Pase DMARC de p=none a p=reject en cuatro etapas: monitorice los informes rua durante 2–4 semanas, corrija cada remitente legítimo, suba gradualmente p=quarantine con pct y luego rechace — nunca salte directamente a reject. 70.368.600 de 261.086.232 dominios calificados están estancados en un SPF blando sin aplicación de DMARC, según el censo de Defaults.Exposed.

Este es el procedimiento operativo: una tabla de etapas con criterios de salida, el registro para cada etapa, la sutileza de pct del RFC 7489 que cambia lo que significa “50%” en reject, y la etiqueta sp= para los subdominios. Si está decidiendo si aplicar la política, lea primero las 6 etapas de madurez de DMARC — ese es el marco; y si los propios niveles de política le resultan nuevos, qué significan realmente p=none, p=quarantine y p=reject es la introducción. Esta página es la ejecución.

¿Por qué no puede saltar directamente a p=reject?

Porque p=reject indica a todos los receptores que la respetan que devuelvan el correo que falla DMARC — y hasta que haya observado sus informes, no sabe qué falla. Casi todos los dominios que activan la monitorización descubren remitentes legítimos que habían olvidado: el CRM, la herramienta de facturación, un formulario de contacto. Salte a reject el primer día y ese correo no va a spam; desaparece en el momento SMTP. Perder una tanda de facturas enseña a una organización a temer a DMARC, y el registro se revierte a p=none de forma permanente — de 261.086.232 dominios calificados, 37.312.637 están estancados exactamente ahí, y solo el 10,59% (27.640.987) llega alguna vez a una política con aplicación.

La otra razón es la alineación. DMARC pasa solo cuando SPF o DKIM pasa y se alinea con el dominio From visible — SPF contra el dominio del Return-Path (RFC5321.MailFrom), DKIM contra el d= de la firma. Los remitentes de terceros suelen pasar SPF en el dominio de ellos, no en el suyo, y por eso la etapa de corregir-cada-fuente consiste sobre todo en activar el DKIM de dominio personalizado de cada proveedor — desgranado en DMARC falla pero SPF y DKIM pasan.

¿Cuáles son las cuatro etapas del despliegue?

Etapa	Registro de política	pct	Qué pasa con el correo que falla	Criterios de salida
1. Monitorizar	`p=none; rua=mailto:…`	—	Se entrega con normalidad; usted recibe informes agregados	2–4 semanas de informes; cada remitente que aparece identificado como legítimo o no
2. Corregir fuentes	`p=none` (sin cambios)	—	Sigue entregándose con normalidad	Todas las fuentes legítimas pasan DMARC con alineación (DKIM de dominio personalizado por remitente); los fallos restantes son solo tráfico desconocido/suplantado
3. Subida de quarantine	`p=quarantine`	10 → 25 → 50 → 100	La parte muestreada va a las carpetas de spam; la parte fuera de la muestra se trata como p=none (se entrega)	1–2 semanas en pct=100 con cero correo legítimo en cuarentena
4. Reject	`p=reject`	100	Se devuelve en el momento SMTP; el remitente recibe un rebote, el destinatario no ve nada	Continuo — mantenga `rua` activo para siempre para detectar remitentes nuevos

Datos a fecha de 2026-06-29; comportamiento de la política según el RFC 7489.

La etapa 3 es donde los dominios se estancan o entran en pánico. El correo en la carpeta de spam es recuperable — los usuarios lo encuentran, usted afloja pct, corrige la fuente. El rechazo no es recuperable, y por eso quarantine en pct=100 funcionando limpio es el billete de entrada a la etapa 4.

¿Cómo se ejecuta el despliegue, paso a paso?

Ejecute el análisis gratuito en defaults.exposed antes de tocar el DNS. Confirma su política actual y si SPF y DKIM están en su sitio por debajo — las dos patas sobre las que se apoya la aplicación.
Active la monitorización si aún no lo ha hecho. Publicar p=none con rua= es el paso de cinco minutos de “DMARC policy not enabled”. Recopile 2–4 semanas de informes — suficiente para captar remitentes mensuales como las tandas de facturación.
Inventaríe todas las fuentes de los informes. Clasifique los remitentes en suyos, de sus proveedores y desconocidos. Los informes en bruto llegan como XML — una herramienta de procesamiento de informes (o el panel de su proveedor) los convierte en un inventario de remitentes legible.
Haga que cada fuente legítima pase con alineación. Active el DKIM de dominio personalizado de cada proveedor (normalmente dos registros CNAME en su panel) para que las firmas lleven su dominio, no el de ellos. Prefiera DKIM para la alineación: sobrevive al reenvío, SPF no.
Espere una quincena limpia. Salga de la etapa 2 solo cuando los fallos reportados sean exclusivamente tráfico que no reconoce — la suplantación que quiere bloquear.
Pase a p=quarantine; pct=10 — edite el registro TXT _dmarc existente (ejemplo práctico: configuración de DMARC en IONOS), y vigile la sintaxis: una errata en la etiqueta de política puede invalidar el registro por completo. Suba pct a 25, 50, 100 a lo largo de 2–4 semanas, vigilando los informes y los tickets de soporte. Si algo legítimo cae en spam: baje pct, corrija la fuente, reanude.
Pase a p=reject tras 1–2 semanas limpias en pct=100. Mantenga rua= activo de forma permanente — cada herramienta nueva que adopte su empresa es un futuro remitente que falla.

¿Qué hace pct realmente? La sutileza del RFC 7489

pct pide a los receptores que apliquen su política a ese porcentaje del correo que falla. La sutileza, del RFC 7489 §6.6.4: el correo que queda fuera de la muestra no recae en “entregar con normalidad” — recibe la política inmediatamente menos severa. Con p=quarantine; pct=25, el otro 75% se trata como p=none y se entrega. Pero con p=reject; pct=50, el otro 50% se pone en cuarentena, no se entrega. No existe un reject suave: en el momento en que su registro dice reject, todo mensaje que falla acaba como mínimo en la carpeta de spam en los receptores que lo respetan.

Usado a propósito, eso es una ventaja — p=reject; pct=1 se comporta como “poner en cuarentena casi todo, rechazar un goteo”, una rampa final legítima. Dos advertencias: no todos los receptores implementan el muestreo igual, así que trate pct como un dial aproximado; y quite la etiqueta (o ponga pct=100) una vez que la etapa 4 sea estable, para que su registro diga lo que usted quiere decir.

¿Y los subdominios — la etiqueta sp=?

Por defecto, los subdominios heredan la política del dominio organizativo: p=reject en yourdomain.com cubre también mail.yourdomain.com. La etiqueta sp= les permite divergir, en direcciones tanto útiles como peligrosas. Útil: p=quarantine; sp=reject blinda los subdominios desde los que nunca envía mientras el dominio raíz sigue a mitad de la subida — los suplantadores atacan deliberadamente los subdominios de dominios monitorizados. Peligroso: un sp=none olvidado exime en silencio a todos los subdominios de la política reject que le costó seis semanas ganarse. Compruébelo en la etapa 4; si un subdominio necesita de verdad una política más laxa, publique un registro _dmarc en ese subdominio en lugar de aflojarlos todos.

¿NIS2 obliga a las empresas de la UE a hacer esto?

DMARC funciona igual en todas partes — nada de este procedimiento cambia al cruzar una frontera de la UE. Lo que cambia es la presión de cumplimiento. El artículo 21(2)(j) de NIS2 exige a las entidades dentro de su ámbito proteger sus comunicaciones, y el Reglamento de Ejecución (UE) 2024/2690 de la Comisión detalla los requisitos técnicos para las entidades de infraestructura digital que cubre — su anexo (punto 6.7.2(k)) exige un plan de implantación para desplegar los estándares modernos de seguridad del correo acordados internacionalmente, y el punto 6.7.2(l) exige buenas prácticas de seguridad de DNS. Una política DMARC con aplicación, con SPF y DKIM por debajo, es el control auditable reconocido contra la suplantación; p=none es, demostrablemente, monitorizar, no proteger. Si sus clientes están dentro del ámbito, sus cuestionarios de proveedores preguntan cada vez más exactamente por esto.

Preguntas frecuentes

¿Cuánto dura el despliegue completo? Lo típico son de seis a diez semanas: 2–4 semanas de monitorización, 1–3 semanas corrigiendo fuentes, 2–4 semanas subiendo quarantine, y luego reject. Es tiempo de calendario, no de esfuerzo — sobre todo esperar a que los informes confirmen cada cambio. El 89,41% de los 261.086.232 dominios calificados sin política con aplicación (datos a fecha de 2026-06-29) en su mayoría no está a mitad de despliegue; nunca puso el reloj en marcha.

¿Puedo saltarme quarantine y usar p=reject con un pct bajo en su lugar? Puede — según el RFC 7489 §6.6.4, p=reject; pct=10 significa un 10% rechazado y un 90% en cuarentena, aproximadamente el final de la etapa 3. Pero p=quarantine primero es más fácil de razonar, y los receptores varían en la fidelidad con la que muestrean. En cualquier caso, las etapas 1–2 no son negociables: ninguna variante de aplicación es segura mientras los remitentes legítimos sigan fallando.

¿Y el correo que no puedo arreglar — reenviadores y listas de correo? El reenvío rompe SPF por diseño, y algunas listas de correo reescriben el contenido, rompiendo también DKIM. Un DKIM alineado sobrevive al reenvío ordinario, lo que resuelve la mayor parte; el pequeño residuo es la razón de que exista la etapa de quarantine — el correo en la carpeta de spam es recuperable mientras usted evalúa. Detalles en el correo reenviado falla SPF.

¿Quedarse en p=quarantine es suficiente? Es la mayor parte del valor, y mucho mejor que los 37.312.637 dominios estancados en p=none (de 261.086.232 calificados, datos a fecha de 2026-06-29) — pero el correo suplantado sigue llegando a las carpetas de spam, de donde la gente lo rescata. Reject es el punto final: solo el 10,59% de los dominios calificados aplica la política en absoluto, y terminar es lo que los verificadores, las aseguradoras y los cuestionarios acreditan.

Envíe el informe al propietario

Si está ejecutando este despliegue para un cliente o para su empresa, la línea de meta se puede enseñar. Vuelva a ejecutar el análisis gratuito cuando p=reject resuelva y reenvíe el informe calificado: el dominio pasando a una política con aplicación, con fecha y en lenguaje claro. Esa única página responde a la línea de seguridad del correo en las renovaciones de ciberseguro y en los cuestionarios de proveedores impulsados por NIS2 mejor que una captura de pantalla de un panel de DNS — y hace visibles seis semanas de trabajo cuidadoso e invisible ante la persona que lo paga.

Compruebe su política DMARC gratis

Vea cuál es su política actual — y si SPF y DKIM pueden sostener la aplicación — de forma privada y solo para el propietario.

Compruebe su dominio → · Arreglar DMARC → · “DMARC policy not enabled” — el primer paso honesto → · Solo datos agregados. Datos almacenados y procesados en la UE.