Llegar a p=reject sin romper el correo legítimo

Etapa 2: inventariar cada fuente legítima

Los informes agregados revelan cada IP que emite por el dominio. El trabajo consiste en transformar esa lista de direcciones en una lista de servicios: «esta IP de alto volumen que pasa DKIM es nuestra plataforma de correo; la que falla las dos es el CRM; esta otra es una herramienta de encuestas que el marketing había olvidado.» Este inventario es todo el meollo — imposible aplicar una política con serenidad sin saber, con certeza, quién envía legítimamente por el dominio. Hay que esperar sorpresas; siempre hay algunas fuentes de las que nadie se acordaba.

Etapa 3: alinear cada fuente legítima

Para cada remitente legítimo, hay que asegurarse de que pase SPF o DKIM y se alinee con el dominio del From:. En la práctica, esto significa generalmente poner en marcha una firma DKIM con un dominio de la marca (d=ejemplo.es) en cada plataforma, ya que los remitentes de terceros rara vez alinean SPF. Se recorre la lista hasta que cada fuente real muestre un paso alineado en los informes. Es lo esencial del esfuerzo, y donde se va la mayor parte del tiempo de calendario.

Etapa 4: pasar a quarantine

Cuando los informes muestran todas las fuentes legítimas alineadas, se sube la política a p=quarantine. El correo no autenticado se va ahora a correo no deseado en lugar de a la bandeja de entrada — una defensa real, pero reversible si algo se ha escapado. Históricamente, se escalonaba con la etiqueta pct (pct=25, luego 50, luego 100) para aplicar la política a una fracción creciente del correo en fallo. DMARCbis (2026) retira pct en favor de un modo de prueba binario (la etiqueta t=y) y de una subida apoyada en la observación de los informes en lugar de en un porcentaje. En la práctica hoy: si la herramienta y los destinatarios aún honran pct, se puede usar durante el tiempo de la transición; si no, se avanza por etapas cortas — unos días en quarantine vigilando los informes — antes de pasar a reject.

Etapa 5: pasar a reject

Cuando quarantine funciona limpiamente — las únicas fuentes en fallo restantes son desconocidas, es decir, suplantadores — se sube la política a p=reject. El correo falsificado en nombre del dominio se rechaza ahora a la entrada. Queda por ajustar la política de subdominio (sp) en consecuencia, para que los atacantes no se pasen simplemente a un subdominio. La aplicación está alcanzada.

DMARCbis: lo que cambia para la subida de política

Publicado en mayo de 2026 (RFC 9989/9990/9991), DMARCbis moderniza el estándar sin dejar obsoleto este recorrido — la secuencia none → quarantine → reject sigue siendo exactamente la correcta. Dos novedades merecen atención durante la subida:

• La etiqueta np. Fija la política de los subdominios inexistentes — un objetivo de suplantación clásico, porque un atacante puede forjar factura.ejemplo.es aunque ese subdominio no exista. Es una victoria rápida y sin riesgo: np=reject se pone pronto, en cuanto la raíz está sana, ya que ningún correo legítimo sale de subdominios que no existen.
• pct → t y el DNS Tree Walk. pct desaparece (cf. etapa 4) y la determinación del dominio organizativo ya no depende de la Public Suffix List sino de una serie de consultas DNS (ocho máximo). Nada que rehacer en la progresión: el registro sigue siendo válido, es solo la ocasión de retirar un pct que ha quedado inútil.

¿Cuánto tiempo lleva?

Para un dominio pequeño con una o dos fuentes, unos días. Para una gran organización con decenas de plataformas repartidas entre negocios y regiones, unos meses es lo normal — sobre todo pasados en la etapa 3, la alineación de las fuentes, no en el cambio de política. El ritmo lo fija la velocidad a la que se configura cada plataforma, no DMARC en sí. Para referencias más finas según el tamaño de la organización y la etapa en curso, ver cuánto tiempo lleva el paso a p=reject.

Cómo saber que el momento de endurecer ha llegado

No hay que adivinar el momento adecuado; los informes lo dicen. Tres señales concretas antes de subir un peldaño:

• Las fuentes legítimas conocidas muestran todas un paso alineado a lo largo de varios días de informes — no una vez por casualidad, sino de forma estable.
• Las únicas líneas en fallo restantes son IP desconocidas, con poco volumen o en picos aislados: el perfil de un suplantador o de un reenvío, no de un servicio de negocio.
• Ninguna fuente mensual falta a la cita. Facturación, extractos, campañas trimestrales: hay que esperar a haber visto pasar al menos un ciclo completo antes de concluir que el inventario es exhaustivo.

Si estas tres casillas están marcadas, la etapa siguiente es segura. Si no, más vale quedarse donde se está y corregir primero la fuente que falta — endurecer sobre un inventario incompleto es exactamente lo que rompe el correo legítimo.

Trampas frecuentes por el camino

• Endurecer demasiado pronto. El medio más común de romper el propio correo. Hay que dejar que los informes prueben que una fuente está alineada antes de aplicarla.
• Olvidar la distinción sobre / cabecera. Una fuente puede pasar SPF en bruto y fallar DMARC por falta de alineación. Se lee siempre la alineación, no solo pasa/falla.
• Dejar los subdominios abiertos. Se aplica la raíz pero se olvida sp, y los suplantadores se pasan a mail.ejemplo.es.
• Pararse en quarantine. Es un avance, pero el correo suplantado sigue alcanzando la carpeta de correo no deseado, donde algunos usuarios lo rescatan. reject es el objetivo. Los dos niveles no equivalen — la comparativa detallada muestra lo que cada uno bloquea realmente.

Anclar el proceso en la organización

Una última palanca no depende del DNS sino de la gobernanza. Conviene avisar a los equipos emisores — marketing, RR. HH., comercial, producto — antes de cada cambio de nivel: son ellos quienes notarán primero que una campaña se va a correo no deseado, y un aviso rápido vale más que un descubrimiento tardío. Sobre todo, hay que instaurar una regla simple para lo que venga: ninguna nueva herramienta de envío pasa a producción sin firma DKIM alineada con el dominio. Sin ese reflejo, la primera plataforma contratada tras el paso a reject verá sus mensajes desaparecer silenciosamente, y la organización revivirá la crisis que la subida metódica le había ahorrado. La aplicación no es un estado que se alcanza, es un estado que se mantiene — y el mantenimiento cuesta mucho menos integrado en el proceso de compra que improvisado a posteriori.

Por qué p=reject vale la pena

Alcanzar la aplicación es un verdadero proyecto; es legítimo, por tanto, preguntarse qué reporta más allá de marcar una casilla de conformidad. Mucho, en realidad:

• La suplantación se detiene de verdad. Es lo esencial. En p=reject, un email falsificado que usa el dominio exacto en el From: es rechazado por los destinatarios antes incluso de alcanzar a un cliente. El phishing que suplanta a la marca sencillamente deja de ser entregable — ni filtrado, ni señalado, sino rechazado de entrada.
• Una mejor entregabilidad para el correo real. Los proveedores confían más en los dominios que aplican una política. Un dominio en p=reject con una alineación limpia es una fuerte señal de reputación positiva, de la que se benefician cada día las campañas legítimas y los mensajes transaccionales.
• La conformidad, resuelta. El DMARC aplicado satisface de sobra los requisitos para remitentes de Gmail y Yahoo, y constituye un control claro y auditable que presentar para marcos como NIS2 y DORA.
• La oportunidad del logo. Solo los dominios que aplican una política pueden publicar BIMI y mostrar un logo verificado en la bandeja de entrada — una marca de confianza visible y un activo de marca que no se desbloquea de ninguna otra forma.
• Una tranquilidad duradera. Una vez en reject con la vigilancia mantenida, toda nueva fuente no autorizada aparece en los informes en lugar de en las bandejas de los clientes. Lo difícil es la subida; permanecer ahí se reduce sobre todo a verificar que los informes sigan limpios.

Comparadas con el coste de una sola suplantación exitosa — pérdidas por fraude, sobrecarga del soporte, daño duradero a la marca — las pocas semanas de alineación se rentabilizan rápido. El verdadero error nunca fue el esfuerzo de la subida; es pararse en p=none y confundir vigilancia con protección.

Thomas hace el grueso del trabajo

Esta secuencia es exactamente lo que automatiza Thomas, el RSSI virtual. Ingiere los informes, nombra cada fuente de envío, genera el DNS exacto que hay que pegar (etiquetas DMARCbis incluidas), evalúa la preparación sobre datos deslizantes, y señala el momento preciso en que cada etapa es segura — desde p=none hasta p=reject, sin bloquear un solo email legítimo.

Análisis de dominio gratuito o crear una cuenta para empezar. ¿Con curiosidad por ver en qué punto están sectores enteros? El Observatorio DMARC muestra negro sobre blanco cuántos dominios se quedan bloqueados a medio camino, en p=none.