¿Cada subdominio necesita su propio registro DMARC?

No. Un subdominio sin registro propio hereda del dominio organizacional, usando la etiqueta sp cuando está presente y p cuando no. Publica un registro en el subdominio cuando quieras que funcione con una política distinta a la de la raíz, por ejemplo un subdominio de envío delegado que todavía se está calentando.

Mi dominio está en p=reject. ¿Mis subdominios están protegidos?

Por lo general sí, siempre que no hayas publicado sp=none y que ningún subdominio tenga un registro propio más débil. Esas dos cosas son las que anulan en silencio una raíz estricta. Revisa si tu registro trae una etiqueta sp y luego revisa cada subdominio que envía por un _dmarc olvidado.

¿Cuál es la diferencia entre las etiquetas sp y np?

La etiqueta sp define la política para subdominios que existen en DNS. La etiqueta np, agregada en el RFC 9989, define la política para nombres que no existen, es decir, aquellos cuya consulta devuelve NXDOMAIN. Para esos nombres np tiene prioridad sobre sp, así puedes dejar un subdominio real en monitoreo y aun así rechazar los inventados.

Subdominios en DMARC: la etiqueta sp y el hueco np

Imagina una distribuidora de 30 personas que hizo bien la tarea de DMARC. El SPF pasa, DKIM firma cada mensaje, el registro del dominio raíz está en p=reject y los reportes agregados llegan cada mañana a un buzón. Un día los clientes empiezan a reenviarles facturas falsas. La dirección del remitente dice cobros@facturacion.ejemplo.com, un subdominio que la empresa nunca creó ni usa. El dominio raíz está blindado y la suplantación ocurre una etiqueta más a la izquierda.

Este es el hueco más común que encontramos en dominios cuyos dueños dan DMARC por terminado. La política funcionó tal como está especificada. Lo que pasó es que nunca le hicieron la pregunta que el dueño creía haberle hecho.

Cómo encuentra un receptor la política de un subdominio

DMARC no evalúa el dominio que configuraste. Evalúa el dominio que aparece en la cabecera From del mensaje que tiene enfrente, al que la especificación llama dominio autor. Todo lo relacionado con subdominios sale de ese único hecho.

Cuando llega un mensaje que dice venir de facturacion.ejemplo.com, el receptor consulta primero _dmarc.facturacion.ejemplo.com. Si ahí hay un registro válido, ese registro decide el resultado y no se consulta nada del dominio raíz. Si no hay nada, el receptor sube hasta encontrar el dominio organizacional, el nombre que en realidad registraste, y aplica el registro que encuentre a ese nivel.

Ese ascenso cambió en mayo de 2026, cuando DMARC pasó a ser un protocolo Standards Track con el RFC 9989, que deja obsoleto al RFC 7489 informativo de 2015. El RFC 7489 deducía el dominio organizacional a partir de la Public Suffix List y consultaba exactamente dos nombres: el dominio autor y luego el dominio organizacional. Los niveles intermedios se saltaban por completo, así que un registro publicado en _dmarc.eu.ejemplo.com era invisible para un mensaje enviado desde mail.eu.ejemplo.com. El RFC 9989 reemplaza esa lista por un recorrido del árbol DNS: sube una etiqueta a la vez, con un límite de ocho consultas, hasta encontrar el registro que marca el límite del dominio. Si alguna vez publicaste una política en un nivel intermedio de un nombre largo y viste que no hacía absolutamente nada, ese es el comportamiento que cambió.

En cualquiera de los dos casos la regla práctica es la misma, y es la que más se malentiende: un subdominio con su propio registro DMARC ignora al padre por completo. Si publicas v=DMARC1; p=none en un subdominio, ese subdominio se queda en monitoreo por más estricto que esté el dominio raíz.

La etiqueta sp y el hueco que deja debajo

Cuando el registro que termina aplicando se encontró en el dominio organizacional y no en el subdominio, el receptor no usa p. Busca sp, la política de subdominios, y solo recurre a p si sp no está. Ese comportamiento por defecto es seguro: un p=reject sin etiqueta sp sí protege a todos los subdominios que no tengan registro propio.

El problema empieza porque sp=none es genuinamente útil durante una implementación. Es la forma de aplicar política en la raíz mientras todavía estás ordenando un sistema de facturación o una plataforma de marketing que vive en un subdominio, y lo recomendamos justo para eso. También es lo que cargan un montón de registros copiados y pegados sin ninguna razón.

_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@ejemplo.com"

Con el RFC 7489 ese registro era todo o nada. El valor de sp cubría a todos los subdominios, tanto al real que estabas sacando adelante durante una migración como al nombre que un atacante se inventó hace cinco minutos. Para dejar un subdominio real en monitoreo tenías que dejar en monitoreo también a todos los subdominios imaginarios. Ese es el hueco por donde se cuela el caso de la distribuidora.

El RFC 9989 agrega np, una política que aplica únicamente cuando el dominio autor no existe. La especificación amarra la existencia al propio DNS: si una consulta por el nombre devuelve NXDOMAIN, entonces ese nombre y cualquier subdominio suyo no existen. Los valores válidos son los tres de siempre, none, quarantine y reject, y np tiene prioridad sobre sp para cualquier nombre que no pase esa prueba de existencia.

_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:dmarc@ejemplo.com"

Lee ese registro como una frase: aplica política en la raíz, deja los subdominios reales en monitoreo mientras terminamos el trabajo y rechaza cualquier cosa que diga venir de un nombre que nunca se creó. Pocos dominios tienen una buena razón para que les falte esa tercera cláusula.

Hay una distinción que define qué etiqueta cubre qué. La existencia es una pregunta de DNS, no de correo. Un nombre como app.ejemplo.com con un registro A que apunta a una aplicación web existe. Nunca ha enviado correo ni lo hará, pero responde en DNS, así que cae bajo sp y no bajo np. El soporte de np en los receptores todavía no es universal, así que trátalo como una capa que agregas y no como lo único que te separa de un subdominio falsificado.

Lo que revisamos primero en el dominio de un cliente

Antes de tocar un solo registro armamos la lista, porque cada decisión que viene después depende de saber qué subdominios son reales y cuáles de ellos envían.

Todos los nombres del dominio que resuelven, leídos de la zona DNS y no de memoria. Aplicaciones web, ambientes de prueba, puntos de VPN, una impresora que alguien nombró hace años.
Cuáles de esos envían correo de verdad, según los reportes agregados y no según lo que la gente cree.
Si cada subdominio que envía tiene su propio registro _dmarc y qué dice. Un p=none olvidado en un subdominio anula en silencio una raíz estricta.
Si cada subdominio que envía tiene su propio registro SPF.

Ese último punto es la asimetría que sorprende hasta a administradores con experiencia. DMARC sube por el árbol. SPF no. SPF se evalúa contra el dominio exacto del remitente del sobre, y si no hay un registro TXT en ese nombre exacto el resultado es none. El registro de la raíz nunca se consulta y no ayuda en nada. Entonces un sistema de facturación que envía como facturacion.ejemplo.com sin registro SPF publicado ahí falla SPF en cada mensaje, y lo único que mantiene esas facturas entregables es una firma DKIM alineada. Si aplicas política DMARC sin revisar eso primero, lo que rompes es tu propia facturación.

Subdominios que nunca deberían enviar

Para cada nombre de la lista que no tiene por qué enviar correo publicamos tres registros. El orden importa menos que el hecho de que estén los tres.

app.ejemplo.com.        MX   0 .
app.ejemplo.com.        TXT  "v=spf1 -all"
_dmarc.app.ejemplo.com. TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@ejemplo.com"

El primero es un MX nulo, definido en el RFC 7505 como un único registro MX con preferencia 0 y un destino de longitud cero escrito como un punto, que anuncia que ese nombre no acepta correo. Un dominio que anuncia un MX nulo no debe anunciar ningún otro registro MX, así que limpia lo viejo antes de agregarlo. El segundo dice que ningún servidor está autorizado a enviar como ese nombre. El tercero hace que el nombre deje de depender de sp, y eso es lo que vuelve útil este patrón en el puñado de nombres que importan, incluso cuando ya tienes np publicado.

En una zona grande cubrimos solo los nombres que resultan creíbles en una dirección de remitente falsificada: facturacion, cobros, pagos, rrhh, planilla, seguro, y el nombre del sistema contable que use la empresa.

Delegar un subdominio a una plataforma de marketing

El caso contrario es un subdominio que existe precisamente para que alguien más envíe desde ahí. Cuando una empresa hace campañas con una plataforma de correo, mover ese tráfico a noticias.ejemplo.com en lugar del dominio raíz trae dos beneficios que sí valen la pena.

El primero es separar la reputación. Una campaña que junta quejas daña la reputación del nombre que la envió, así que mantener el correo masivo fuera del nombre por donde salen tus cotizaciones y facturas significa que un envío malo no persigue a tu equipo de ventas hasta la bandeja de entrada.

El segundo es el presupuesto de consultas de SPF. SPF permite diez consultas DNS durante la evaluación, y un registro que lo excede devuelve permerror, lo que hace fallar el SPF de una vez. Los mecanismos include de las plataformas son la razón habitual por la que un dominio se queda sin margen. Como SPF se evalúa por nombre, un include que vive en noticias.ejemplo.com no le cuesta nada al dominio raíz. Delegar tus dos o tres remitentes más pesados a subdominios propios suele ser una solución más limpia que aplanar registros que después se quedan desactualizados en silencio. El conteo y las alternativas los explicamos en la guía para bajar del límite de diez consultas.

En un subdominio delegado configuramos los registros SPF y DKIM de la plataforma en ese nombre, su propio registro _dmarc para que el subdominio pueda estar en una política distinta a la de la raíz mientras se calienta, y verificamos que la plataforma firme con un dominio que alinee. La alineación es donde estos arreglos suelen quebrarse. En el modo relajado, que es el predeterminado, SPF y DKIM alinean cuando el dominio autenticado y el dominio del From comparten el mismo dominio organizacional, así que una firma DKIM con d=ejemplo.com alinea con un remitente en noticias.ejemplo.com. En modo estricto, que se activa con adkim=s o aspf=s, los nombres deben coincidir exactamente y esa misma combinación falla. Activar alineación estricta sin auditar antes los subdominios que envían es una forma segura de romper una campaña. Los registros específicos de las plataformas más comunes están en nuestro artículo sobre la alineación de Mailchimp, HubSpot y Klaviyo.

Leer las filas de subdominios en tus reportes

Los reportes agregados, que el RFC 9990 especifica en un documento propio, son donde te enteras de qué subdominios existen en la práctica y no en el papel. Dos costumbres los vuelven útiles para esto.

Lee el dominio del From de cada bloque de registro, no solo la política que publicaste. Los reportes agrupan por el dominio que los mensajes dijeron usar, así que el tráfico de subdominios aparece en sus propias filas, fáciles de pasar por alto cuando vas buscando volumen. Una fila de un subdominio que no reconoces es justamente la razón para revisar.

Después revisa qué dice el reporte que se aplicó. El bloque de política publicada te muestra tu registro tal como lo leyó el receptor, sp incluida, así que puedes confirmar que tu política de subdominios se está viendo como querías en lugar de suponerlo desde tu propio DNS. Cuando un subdominio muestra fallos que igual se entregaron, la explicación habitual es un registro _dmarc olvidado en ese subdominio que anula a la raíz en silencio, y el reporte es donde eso se hace visible. Nuestro recorrido por el XML está en cómo leer un reporte DMARC agregado, y puedes pegar uno en nuestro analizador DMARC para ver las filas decodificadas.

Cómo ayuda Guanacos Tech

El trabajo con subdominios es inventario antes que DNS. Sacamos la zona, la comparamos con lo que los reportes muestran que realmente envía y luego decidimos nombre por nombre cuáles subdominios reciben una configuración de envío delegada en forma, cuáles se blindan y cuáles simplemente pueden heredar de la raíz. Si tu dominio raíz ya está en p=reject y quieres saber si esa protección llega un nivel más abajo, pasa tu registro por el analizador o agenda una llamada y revisamos tu zona contigo.

Subdominios y DMARC: por qué un dominio raíz blindado igual se puede suplantar