DMARC de p=none a p=reject, con seguridad.

¿Por qué p=none no te está protegiendo de verdad?

Un registro DMARC en p=none indica a los servidores receptores que no tomen ninguna acción sobre los mensajes que fallan la autenticación. Cada mensaje se entrega con normalidad, pase o falle; la única función del registro es generar los informes agregados que muestran quién envía correo como tu dominio. Eso hace de p=none una herramienta de descubrimiento, no una defensa — y un dominio que se queda ahí de forma permanente está viendo cómo ocurre la suplantación sin detenerla.

Esto no es teórico. Audita un dominio en p=none y sus informes muestran de forma rutinaria correo desde IP en países donde la organización no tiene presencia, enviado por servidores que nunca ha usado. Esos mensajes suplantados se marcan como spam y se denuncian como phishing por los destinatarios, y los proveedores de buzón integran ese comportamiento en la reputación de tu dominio — no distinguen entre el correo que enviaste tú y el que otro envió en tu nombre. Quedarse en p=none deja que ese daño se acumule.

La magnitud de la brecha sorprende. Entre los dominios lo bastante implicados como para ejecutar una herramienta de monitorización, alrededor del cuarenta por ciento sigue de forma permanente en p=none, y de los diez millones de dominios con más tráfico solo un pequeño porcentaje aplica quarantine o reject. Alcanzar la aplicación, por tanto, hace más que protegerte — te coloca por delante de la inmensa mayoría de internet que ha publicado DMARC pero nunca lo ha activado.

Los remitentes de terceros que rompen la aplicación

Si una migración falla, la causa casi siempre es un remitente que olvidaste que tenías. Los informes los sacan a la luz, pero solo si los lees: una plataforma de marketing añadida el año pasado, un help desk que envía en tu nombre, un sistema de facturación en un servidor heredado, el dominio antiguo de una adquisición que aún envía facturas. Cada uno tiene que pasar DKIM o SPF con alineación a tu dominio From visible antes de que aprietes la política, y cada uno tiende a fallar a su manera silenciosamente específica.

SPF está limitado a diez búsquedas DNS, y ese techo es fácil de superar a medida que añades herramientas. Suma un CRM, un help desk, una plataforma de marketing y un proveedor transaccional, y los includes encadenados pueden pasar de diez, momento en el que SPF devuelve un error permanente y cae directo en fallos DMARC para correo legítimo. La solución es auditar y aplanar el registro, manteniéndolo dentro del límite, y sacar del SPF raíz a los proveedores que envían desde sus propios subdominios donde la plataforma lo permita.

DKIM tiene sus propios modos de fallo que se esconden hasta que la aplicación los atrapa. Firmas configuradas correctamente al inicio se rompen durante una migración — cambia un proveedor de web, se sustituye un CRM, el DNS se muda a otro host — y nadie verifica que los registros DKIM hayan venido con ellos. Los registros se aplican a un subdominio www en vez de a la raíz, los valores de TTL provocan fallos de validación en receptores estrictos, y las instrucciones CNAME del proveedor simplemente están mal hasta que el proveedor emite valores corregidos. Nada de esto aparece mientras estás en p=none; todo bloquea correo real en cuanto llegas a quarantine, que es justo por lo que existe la fase de monitorización.

¿Y los subdominios y las etiquetas sp y np?

Los subdominios son donde muchos proyectos de aplicación se fugan en silencio. Si omites la etiqueta sp, los subdominios heredan tu política p automáticamente — así que una raíz en p=reject también rechaza por cada subdominio, que suele ser lo que quieres. La mala configuración que hay que cazar es la contraria: p=reject junto a sp=none, que bloquea tu dominio raíz mientras deja cada subdominio suplantable. sp governs existing subdomains; np governs non-existent ones. Omit sp and subdomains inherit p. The p=reject with sp=none mismatch is the misconfiguration to watch.

DMARCbis añade np para subdominios que no existen en absoluto. Un atacante puede falsificar correo desde un subdominio que nunca creaste, y sin np un receptor recurre a tu política sp o p para esos nombres. Poner np=reject cierra esa brecha, pero pruébalo primero — algunos servicios levantan subdominios dinámicos, y un np=reject general puede atrapar correo legítimo que habías olvidado. Bajo el nuevo DNS Tree Walk, los receptores encuentran tu dominio organizativo subiendo por el árbol DNS en vez de consultar la Public Suffix List, lo que no cambia nada en el día a día pero puede importar en jerarquías de dominio profundas.

Una guía de DMARCbis merece mención directa: The spec explicitly advises against p=reject for domains with active mailing-list traffic, to avoid breaking subscribers. Si tu gente publica en listas de proyectos de código abierto, foros del sector o boletines de asociaciones desde tu dominio principal, un reject total puede romper esos mensajes para los suscriptores. La solución habitual es enviar el tráfico de listas desde un subdominio dedicado con su propia política, más suave, manteniendo estricto el dominio raíz.

Un escollo de DMARCbis merece su propia advertencia, porque sorprende a administradores cuidadosos. La nueva etiqueta de prueba t=y pretende dejarte señalar «sigo probando la aplicación» sin aplicar la política completa — pero solo funciona en receptores que ya entienden DMARCbis. Para la gran población de receptores que aún ejecutan la especificación anterior en 2026, t es una etiqueta desconocida, así que la ignoran y aplican tu p=reject directamente, sin rebaja. El resultado son dos poblaciones de receptores comportándose distinto ante el mismo registro: unos tratando tu correo como prueba, otros rechazando los fallos de plano. Si recurres a t=y esperando un lanzamiento suave universal, no lo conseguirás, y el camino más seguro sigue siendo la rampa operativa — demuestra que tus remitentes pasan y luego comprométete con la política en vez de confiar en una etiqueta de prueba cuyo efecto depende de quién la lea.

Dónde nos situamos

Alojamos infraestructura de envío, así que alcanzar la aplicación nos importa: el correo enviado desde infraestructura limpia y bien autenticada es lo que hace segura una política reject en primer lugar. Pero la migración en sí es tuya, guiada por tus informes, y el consejo honesto es del tipo poco vistoso — ve despacio, corrige remitentes antes de apretar, y nunca avances una etapa para cumplir un plazo. Un dominio empujado a p=reject que bloquea sus propias facturas no ha mejorado su seguridad; ha creado una caída de servicio.

Si gestionas tu envío con nosotros, nos aseguraremos de que tus flujos pasen SPF y DKIM con alineación y mantendremos tu reputación lo bastante limpia como para que aplicar sea un no-evento. Si autohospedas o envías por un ESP, la misma secuencia se aplica sea quien sea quien opere los servidores: publica p=none, lee los informes, corrige cada remitente legítimo y sube la política solo a medida que los datos te lo permitan. La recompensa al final es real — suplantación detenida, reputación protegida y BIMI al alcance.