La política de subdominio DMARC: sp y np

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@ejemplo.es

La etiqueta np: bloquear los subdominios inexistentes

Es el aporte más útil de DMARCbis en materia de subdominios. La etiqueta np (non-existent subdomain policy) fija la política de los subdominios que no existen en el DNS, es decir, que no tienen ningún registro A, AAAA o MX.

¿Por qué es crucial? Porque un atacante no necesita que factura.ejemplo.es exista para escribirlo en un From:. Forja la dirección, la envía, y cuenta con que la política del dominio no cubra ese caso. Con np=reject, la raíz declara: «todo correo que pretenda venir de un subdominio que no existe debe rechazarse».

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@ejemplo.es

La gran ventaja de np: es una ganancia inmediata y sin riesgo. Ningún correo legítimo sale de un subdominio que no existe, por definición. np=reject puede, por tanto, colocarse muy pronto en el despliegue, incluso antes de haber terminado de alinear todas las fuentes reales; no hay nada que observar, nada que romper. La etiqueta tiene su propia guía detallada: la etiqueta np (subdominio inexistente).

Cómo elige el destinatario el registro correcto

Para aplicar sp o np, el destinatario debe primero determinar qué registro DMARC gobierna un mensaje dado, y si el subdominio existe. Históricamente, esta determinación del dominio organizativo se apoyaba en la Public Suffix List (PSL). DMARCbis la reemplaza por el DNS Tree Walk: una serie de consultas DNS (ocho como máximo) que remonta el árbol de nombres hasta encontrar el registro DMARC aplicable.

En la práctica, para un mensaje que pretende venir de a.b.ejemplo.es, el destinatario busca un registro DMARC en ese nombre, luego remonta nivel por nivel hasta el dominio organizativo, y aplica la política más específica encontrada, distinguiendo subdominio existente (sp o su propio registro) e inexistente (np). El mecanismo se explica en detalle en el DNS Tree Walk. No hay nada que configurar para el Tree Walk en sí; basta con publicar sp/np coherentes.

El escenario de ataque que esto bloquea

Sirva de ejemplo un banco cuya raíz banco.es está en p=reject, sin np. Un defraudador envía una campaña de phishing desde seguridad.banco.es, un subdominio que no existe. Como no existe, no tiene registro propio; y según la implementación, la herencia de p puede aplicarse de forma desigual a un nombre inexistente. El mensaje puede, por tanto, pasar, con una dirección de remitente creíble que inspira confianza a la víctima.

Con np=reject, ese escenario se derrumba: el destinatario ve un subdominio inexistente, aplica np, rechaza el mensaje. Es exactamente el tipo de suplantación de identidad «por el costado» que sufren las grandes marcas, y que sp/np neutralizan por un coste de configuración casi nulo. El tema de las marcas muy atacadas se desarrolla en DMARC para los bancos.

Ajustes recomendados

Para la mayoría de los dominios, la configuración objetivo es simple y simétrica:

• p=reject en la raíz, una vez alineadas las fuentes.
• sp=reject para que los subdominios existentes sin registro propio también estén protegidos.
• np=reject para cerrar los subdominios inexistentes, a colocar temprano, sin esperar.

Si un subdominio legítimo tiene necesidades particulares (proveedor aún no alineado), conviene darle su propio registro DMARC en lugar de debilitar sp en toda la raíz. Es más quirúrgico y preserva la protección global.

Cuándo un subdominio merece su propio registro

La herencia vía sp cubre el caso general, pero algunos subdominios tienen una vida propia que justifica un registro DMARC dedicado, publicado directamente en _dmarc.el-subdominio.ejemplo.es. Tres situaciones típicas:

• Un flujo de envío distinto y voluminoso. Si mail.ejemplo.es sirve exclusivamente a la plataforma de marketing, darle su propio registro permite tener una dirección rua separada y seguir ese flujo independientemente de la raíz. La salud de esa fuente concreta se lee entonces de un vistazo, en informes dedicados.
• Un ritmo de endurecimiento diferente. Un subdominio cuyas fuentes aún no están todas alineadas puede quedarse en quarantine mientras la raíz pasa a reject. En lugar de bajar sp para toda la organización, se aísla el retraso en el único subdominio afectado.
• Una delegación a una entidad de terceros. Filial, marca secundaria, proveedor que gestiona un subdominio completo: confiarle su propio registro DMARC clarifica las responsabilidades y evita que un error por su parte afecte a la política de la raíz.

La regla mental es simple: el registro más específico gana. Un _dmarc colocado en el subdominio gana siempre a sp heredado de la raíz. Esta especificidad sirve para tratar las excepciones localmente, sin debilitar nunca la protección global a nivel del dominio organizativo.

El caso de los dominios aparcados y sin correo

Un punto ciego frecuente: los dominios (o subdominios) que una organización posee pero desde los que no sale ningún correo: marcas defensivas, nombres antiguos, dominios reservados «por si acaso». Muchas organizaciones los dejan sin DMARC, pensando que un dominio que no envía nada no corre ningún riesgo. Es al revés: un dominio sin política DMARC es un dominio que cualquiera puede suplantar sin resistencia. La buena práctica es colocarles desde el principio la política más estricta —p=reject; sp=reject; np=reject— puesto que, por construcción, ningún correo legítimo sale de ellos. np cobra ahí todo su sentido: en un dominio aparcado, todos los subdominios son inexistentes.

Los subdominios tienen un ciclo de vida — sp y np lo siguen

Un último punto que integrar: la frontera entre sp y np no es fija. La evalúa el destinatario en el momento en que llega un mensaje, según lo que dice el DNS en ese instante. Basta con montar un microsite de campaña con un simple registro A para que ese nombre exista a partir de entonces; un correo forjado en su nombre se juzga bajo sp, no bajo np. Al desmantelar un viejo servicio y borrar sus registros DNS, el nombre vuelve silenciosamente bajo np. Dos consecuencias prácticas. Primero, conviene mantener sp exactamente igual de estricto que np: si sp es más laxo, la simple publicación de un subdominio puramente web debilita la protección de correo sin que nadie haya tocado el email. Después, la limpieza del DNS se integra en el desmantelamiento; es el registro borrado el que devuelve el nombre a su política más estricta.

Errores frecuentes

• Endurecer la raíz y olvidar los subdominios. Es la brecha más común tras una migración exitosa: p=reject en la raíz, nada en sp/np, y una puerta lateral de par en par.
• Confundir sp y np. sp cubre los subdominios que existen; np los que no existen. Ambos son necesarios; uno no reemplaza al otro.
• Esperar para colocar np. Puesto que es sin riesgo, aplazar np=reject solo prolonga inútilmente la exposición.
• Creer que la política de subdominio arregla la alineación. sp y np dicen qué hacer con el correo en fallo; no alinean por ello las fuentes reales de los subdominios, eso sigue siendo un trabajo aparte.

En resumen

Llevar la raíz a reject sin arreglar los subdominios es cerrar con llave la puerta de entrada dejando la ventana abierta. sp protege los subdominios existentes, np cierra los inexistentes, y np es una ganancia gratis que aprovechar desde el principio del despliegue. Juntos, suprimen el ángulo de ataque «por el costado» que sobrevive con demasiada frecuencia a una migración DMARC por lo demás exitosa. El reflejo a recordar es simple: cada vez que se endurece una raíz, sp y np vienen a continuación, como dos gestos indisociables; la raíz sola nunca es una protección completa.

Para verificar que la raíz y sus subdominios están correctamente cubiertos —incluidos los casos inexistentes— el analizador DMARC gratuito acepta cualquier dominio: muestra la política efectiva vista desde fuera, exactamente como un destinatario (o un atacante) la descubriría.