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

_dmarc.ejemplo.es.  IN TXT
  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:informes@ejemplo.es"

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 (ejemplo.es).
• sp — la política de los subdominios que existen (mail.ejemplo.es, news.ejemplo.es).
• np — la política de los subdominios que no existen (factura-loquesea.ejemplo.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 (véase 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 puede 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. Hacen falta las dos: sp para los 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 se posee pero desde el que nunca se envía 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. Releer el 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. Vigilar los informes agregados: un subdominio inexistente suplantado aparecerá ahora con una disposición reject en lugar de colarse. Su lectura se explica en cómo leer los informes agregados.

Un escenario de ataque concreto

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

Un atacante prepara una campaña de phishing. En lugar de suplantar ejemplo.es (rechazado por p=reject) o mail.ejemplo.es (rechazado por sp=reject), elige From: facturacion@cuentas.ejemplo.es. Ese subdominio cuentas.ejemplo.es no existe en el DNS de ejemplo.es. 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 cuentas.ejemplo.es no tiene registro (mediante el DNS Tree Walk), aplica la política np y rechaza el mensaje. El ataque fracasa, sin que ejemplo.es 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 se han creado.

Configuraciones recomendadas según el 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): np=reject puede publicarse ya, 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 más adelante se crea un subdominio real? En cuanto tenga registros DNS, «existe» y pasa al régimen de sp. Basta con acordarse 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 los subdominios

Más allá de la etiqueta en sí, np es la ocasión de plantear una pregunta que rara vez se aborda: ¿quién crea subdominios en la organización y quién lo sabe? En muchas estructuras, cualquier equipo puede hacer que campana-verano.ejemplo.es 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 los subdominios de envío, alinearlos y mantener sp coherente.

Un buen reflejo: tratar la lista de subdominios como un activo de seguridad, al mismo nivel que el inventario de fuentes de envío. Los informes agregados también ayudan aquí: revelan correo emitido desde subdominios olvidados, 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 para quien aspira a BIMI a medio plazo: mostrar el logotipo supone una marca coherente y una política estricta sobre todo el 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. Configurar np=reject no tiene riesgo (nada legítimo sale de un subdominio inexistente) y resulta inmediatamente eficaz contra una categoría entera de phishing. Tres etiquetas que distinguir: p (raíz), sp (subdominios reales), np (subdominios fantasma).

Thomas pone la política correcta

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

Análisis gratuito del dominio o crear una cuenta. Para el contexto completo de DMARCbis, véase este nuevo estándar explicado de forma sencilla.