Lista de comprobación de elegibilidad: ¿cuándo un dominio está listo para p=reject?

3. El SPF no supera los 10 lookups DNS

SPF tiene un tope de diez resoluciones DNS. Por encima, la verificación devuelve un PermError y SPF falla, aunque el registro sea «correcto». Ir apilando los include: de cada proveedor hace superar ese tope más rápido de lo que se cree. Conviene comprobar este contador antes de endurecer, o el dominio se apoyará en DKIM solo sin saberlo. El tema se trata en detalle en el error SPF «too many DNS lookups». Casilla marcada cuando el SPF resuelve por debajo de la barrera de los diez.

4. Los subdominios están cubiertos

Un atacante que ya no puede falsificar el dominio raíz se pasa a los subdominios, incluidos los que no existen. La política por defecto de los subdominios hereda de p, pero conviene pilotarla explícitamente con sp, y bloquear los subdominios inexistentes con la etiqueta np de DMARCbis. Es una ganancia rápida y sin riesgo: ningún correo legítimo sale de un subdominio que no existe. Detalles en la política de subdominio DMARC (sp y np). Casilla marcada cuando sp y np estén puestos y sean coherentes con la raíz.

5. Los informes fluyen y están «limpios» desde hace varias semanas

No se endurece sobre una foto instantánea, sino sobre una tendencia. Los informes deben acumularse durante unas semanas —lo suficiente para captar a los remitentes mensuales (facturación, extractos, campañas trimestrales) y no solo el tráfico diario. «Limpios» quiere decir: las únicas IP que aún fallan la alineación son fuentes desconocidas, es decir, suplantadores. Si aún fallan fuentes legítimas, toca volver a la casilla 2. Para asegurarse de que los informes llegan bien, están configurar la dirección rua y no recibo informes DMARC.

Una palabra sobre los secretos que sostienen todo esto: las claves DKIM privadas son credenciales críticas. Almacenarlas en un archivo tirado en un servidor o en un ticket es un riesgo en sí mismo; un gestor de secretos dedicado como Hucency Vault (del proveedor de ciberseguridad Hucency) evita que una clave de firma se filtre y permita a un tercero suplantar un envío alineado, el único caso en el que p=reject no protege.

6. La herramienta y la cadencia de supervisión están listas

Endurecer la política no es un «publica y olvida». Hay que prever quién mira los informes tras el cambio, con qué frecuencia y durante cuánto tiempo. Una buena práctica: pasar a quarantine, vigilar unos días y luego a reject. Históricamente se escalonaba con pct; DMARCbis (2026) retira pct en favor de un modo de prueba (t=y) y de una subida apoyada en la observación. El despliegue progresivo se detalla en desplegar DMARC de forma progresiva.

7. La decisión está tomada: ¿quarantine o reject?

No todas las organizaciones necesitan llegar hasta reject a la primera. p=quarantine ya es una defensa real y sigue siendo reversible si algo se ha escapado. La elección depende de la tolerancia al riesgo y de la criticidad del flujo; es el tema de p=quarantine o p=reject: cuál elegir. Casilla marcada cuando la decisión esté tomada conscientemente, no por defecto.

Las trampas que vacían una casilla ya marcada

Una lista de comprobación solo es útil si las casillas siguen marcadas. Tres regresiones clásicas deshacen un trabajo por lo demás bien hecho:

• Aparece una nueva fuente sin avisar. Marketing lanza una plataforma de test A/B, RR. HH. cambia de herramienta de nóminas, una filial emite bajo su marca. Cada una llega no alineada y será rechazada en reject. La solución no es congelarlo todo, sino mantener un ojo en los informes tras el endurecimiento: una IP nueva que falla la alineación es o bien un suplantador, o bien una fuente que hay que integrar, y conviene saber cuál antes de que caiga un correo importante.
• Una clave DKIM caduca o se rota mal. Una rotación fallida rompe la alineación de golpe, para una fuente entera. Por eso la casilla 5 pide una tendencia, no una foto, y por eso la rotación debe estar documentada y supervisada.
• Una renovación de SPF vuelve a bajar de los diez lookups… y luego los supera. Añadir un include: de más vuelve a lanzar un PermError. El contador de la casilla 3 no es un control único, es una higiene permanente.

Nada de esto es motivo para quedarse en p=none, porque sería renunciar a toda protección por miedo a un incidente reversible. Es motivo para tratar la supervisión posterior al endurecimiento como parte del proyecto, no como una tarea opcional.

Lo que p=reject no cubre (y no debe hacer bajar la guardia)

Marcar las siete casillas protege de la suplantación directa del dominio: ya nadie puede enviar un From: contacto@ejemplo.es falsificado que aterrice en la bandeja. Pero DMARC no bloquea ni los dominios parecidos (ejemp1o.es, ejemplo-soporte.es), ni el spoofing del nombre visible (una etiqueta «La Empresa» sobre una dirección de Gmail cualquiera), ni las cuentas legítimas comprometidas. p=reject es una capa necesaria, no una capa única. Mencionarlo aquí evita la falsa sensación de seguridad que suele seguir a una migración exitosa: la casilla «sé lo que esto no cubre» es mental, pero cuenta.

El veredicto

Si las siete casillas están marcadas, el dominio es elegible: toca endurecer. Si una sola queda vacía, ahí está la próxima tarea, y es precisa. La belleza de la lista de comprobación es que transforma una decisión angustiosa («¿y si lo rompo todo?») en una revisión objetiva: o los datos dicen que sí, o señalan exactamente lo que falta, sin sitio para la intuición ni para la esperanza.

Un último reflejo antes de publicar el nuevo registro: pasar el dominio por el analizador DMARC gratuito para ver, desde fuera, lo que verán los destinatarios: alineación, política, subdominios, SPF. Es la verificación final que atrapa las erratas y las regresiones de última hora. Y para seguir el progreso a lo largo del tiempo en lugar de sobre una foto, el Observatorio DMARC sitúa el dominio respecto a su sector. p=reject no es un acto de valentía; es una lista de comprobación enteramente marcada.