La etiqueta np de DMARC: bloquear los subdominios que no existen

_dmarc.ton-domaine.fr.  IN TXT
  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:rapports@ton-domaine.fr"

np vs sp vs p: quién cubre qué

Es la confusión más frecuente. Las tres etiquetas se reparten los casos:

• p — la política del dominio raíz en sí mismo (tu-dominio.es).
• sp — la política de los subdominios que existen (mail.tu-dominio.es, news.tu-dominio.es).
• np — la política de los subdominios que no existen (factura-loquesea.tu-dominio.es).

Antes de DMARCbis, solo existían p y sp. Un atacante que apuntaba a un subdominio inexistente caía en una zona gris. np suprime esa zona gris. En la práctica, para un dominio bien gestionado, se suele configurar las tres con el mismo valor estricto: p=reject; sp=reject; np=reject.

Por qué es una ganancia rápida y prioritaria

La mayoría de los endurecimientos de DMARC exigen trabajo: inventariar las fuentes, alinearlas, vigilar los informes (consulta llegar a p=reject). np es lo contrario: cero inventario, cero riesgo, efecto inmediato. Como ningún servicio legítimo emite desde un subdominio inexistente, no puedes romper nada. Por eso se recomienda pronto, a menudo en cuanto el dominio raíz está sano, incluso antes de haber terminado la subida hacia p=reject en el conjunto.

Esto es especialmente cierto para las organizaciones con una gran superficie de subdominios —bancos, grandes grupos, sector público— que explotan decenas de subdominios reales y dejan otros tantos imaginables. En este terreno, np=reject cierra de golpe una categoría entera de ataques. Detallamos el caso financiero en los bancos.

Algunas precisiones útiles

• np solo lo interpretan los destinatarios que están al día de DMARCbis. Durante la transición, algunos aún lo ignorarán —sin daño, retroceden al comportamiento anterior. Nada que perder por publicarlo desde ya.
• np no sustituye a sp. Necesitas las dos: sp para tus subdominios reales, np para los fantasmas. Omitir una deja expuesta la mitad de la superficie.
• El «inexistente» se juzga a través del DNS. Un subdominio se considera inexistente si no resuelve (sin registro). Aquí interviene el DNS Tree Walk, el mecanismo por el que DMARCbis determina la jerarquía de los dominios.
• Los dominios aparcados adoran np. Un dominio que posees pero desde el que nunca envías debería estar en p=reject; np=reject; también es válido para los dominios inactivos.

Cómo comprobar que está en marcha

Una vez publicado np=reject, dos comprobaciones:

1. Relee tu registro con un analizador para confirmar que la etiqueta está presente y que la sintaxis es válida; nuestro analizador gratuito lo hace en unos segundos.
2. Vigila tus informes agregados: un subdominio inexistente suplantado aparecerá ahora con una disposición reject en lugar de colarse. Aprende a leerlos en cómo leer los informes agregados.

Un escenario de ataque concreto

Desarrollemos un ataque real para ver np en acción. Una empresa, exemple.fr, ha hecho bien su trabajo: p=reject en el dominio raíz, sp=reject para sus subdominios conocidos (mail.exemple.fr, news.exemple.fr). Se cree protegida.

Un atacante prepara una campaña de phishing. En lugar de suplantar exemple.fr (rechazado por p=reject) o mail.exemple.fr (rechazado por sp=reject), elige From: facturation@comptes.exemple.fr. Ese subdominio comptes.exemple.fr no existe en el DNS de exemple.fr. Sin la etiqueta np, muchos destinatarios se encuentran en una zona gris: ¿hay que aplicar la política raíz? ¿la de los subdominios? ¿ninguna? Según la implementación, el mensaje puede pasar y aterrizar en la bandeja de la víctima con una dirección perfectamente creíble.

Ahora, el mismo ataque con np=reject publicado: el destinatario constata que comptes.exemple.fr no tiene registro (mediante el DNS Tree Walk), aplica la política np y rechaza el mensaje. El ataque fracasa, sin que exemple.fr haya tenido que crear ni vigilar el menor subdominio ficticio. Ese es todo el valor de np: cubrir el infinito de los subdominios que no has creado.

Configuraciones recomendadas según tu caso

• Dominio de envío normal, ya en p=reject: p=reject; sp=reject; np=reject. El trío estricto, sin dudarlo.
• Dominio aún en subida (p=quarantine): puedes ya poner np=reject, con independencia de p. Ningún correo legítimo sale de un subdominio inexistente, así que no hay riesgo en bloquearlo de inmediato.
• Dominio puramente «corporativo» sin subdominios de envío: np=reject es casi obligatorio; es precisamente este tipo de dominio el que se suplanta mediante subdominios inventados.
• Dominio aparcado (sin envíos): p=reject; sp=reject; np=reject en todo. No sale nada, todo debe rechazarse.

Preguntas frecuentes sobre np

¿Puede np=reject bloquear correo legítimo? No, por construcción. La etiqueta solo se aplica a los subdominios sin registro DNS. Ahora bien, un servicio legítimo que envía desde un subdominio tiene forzosamente registros (como mínimo para SPF/DKIM). Si los tiene, el subdominio «existe» y depende de sp, no de np.

¿Qué pasa si creo más adelante un subdominio real? En cuanto tenga registros DNS, «existe» y pasa al régimen de sp. Solo tienes que acordarte de autenticarlo (SPF/DKIM) antes de usarlo para enviar, como cualquier otra fuente.

¿Es np obligatoria? No, nada es obligatorio en DMARCbis. Pero es una de las novedades con mejor relación beneficio/riesgo: efecto real contra el phishing, cero riesgo, una sola etiqueta.

¿Todos los destinatarios respetan ya np? Aún no todos —la adopción de DMARCbis es progresiva. Los que no la conocen simplemente la ignoran (sin daño). Cuanto más se actualiza el ecosistema, más se refuerza la protección. Ninguna razón para esperar a publicarla.

np y el gobierno de tus subdominios

Más allá de la etiqueta en sí, np es la ocasión de plantearte una pregunta que rara vez se aborda: ¿quién crea subdominios en tu casa y quién lo sabe? En muchas organizaciones, cualquier equipo puede hacer que campana-verano.exemple.fr apunte a un proveedor, sin avisar a seguridad. Cada subdominio real es una superficie que autenticar; cada subdominio no creado es una superficie que rechazar. np=reject resuelve la segunda categoría de golpe, pero la primera exige una disciplina de verdad: inventariar tus subdominios de envío, alinearlos y mantener sp coherente.

Un buen reflejo: tratar la lista de tus subdominios como un activo de seguridad, al mismo nivel que tu inventario de fuentes de envío. Los informes agregados también ayudan aquí: revelan correo emitido desde subdominios que habías olvidado, legítimos o no. Una vez hecho ese mapeo, el par sp/np resulta sencillo de configurar: sp estricto para lo que existe y envía, np=reject para todo lo demás.

Esto es especialmente cierto si aspiras a BIMI a medio plazo: mostrar tu logotipo supone una marca coherente y una política estricta sobre todo tu espacio de nombres. Un subdominio suplantable es una grieta en ese relato de confianza. Bloquear los subdominios inexistentes con np es, por tanto, tanto una medida anti-phishing como una pieza de coherencia de marca.

En resumen

La etiqueta np de DMARCbis fija la política de los subdominios que no existen, una brecha que sp no cubría. Configura np=reject: es sin riesgo (nada legítimo sale de un subdominio inexistente) e inmediatamente eficaz contra una categoría entera de phishing. Tres etiquetas que distinguir: p (raíz), sp (subdominios reales), np (subdominios fantasma).

Deja que Thomas ponga la política correcta

np, sp, p: tres etiquetas, basta configurar mal una para dejar una puerta abierta. Thomas, tu CISO virtual, genera el registro DMARCbis completo y coherente para tu dominio —raíz, subdominios reales e inexistentes— y comprueba en tus informes que ninguna fuente legítima se ve afectada antes de endurecer.

Analiza tu dominio gratis → o crea una cuenta. Para el contexto completo de DMARCbis, consulta este nuevo estándar explicado de forma sencilla.