Los intentos de apropiación de subdominios ahora comúnmente eluden la autenticación de correo electrónico porque las organizaciones asumen que la herencia de política DMARC funciona automáticamente. No es así. Cuando un subdominio carece de un registro DMARC explícito, el subdominio hereda la política del dominio organizacional—pero solo si la política del dominio organizacional existe y está configurada correctamente. Si la herencia falla, los atacantes pueden enviar correo no autenticado desde marketing.example.com, support.example.com, o cualquier subdominio no reclamado, incluso cuando example.com aplica DMARC en p=reject.

La herencia de DMARC en subdominios crea tres condiciones de fallo que los equipos de seguridad comúnmente pasan por alto: (1) la política del dominio organizacional existe pero está mal configurada, por lo que los subdominios heredan una política más débil de lo previsto, (2) el subdominio envía correo a través de un servicio de terceros que no se alinea con la autenticación del dominio organizacional, por lo que la política heredada falla las verificaciones de alineación, o (3) el subdominio está registrado en DNS pero no gestionado activamente, creando una brecha explotable donde los atacantes pueden reclamar el subdominio a través de vulnerabilidades del proveedor de hosting o del proveedor de DNS y enviar correo antes de la detección.

Las campañas de phishing impulsadas por IA ahora escanean estas brechas usando enumeración DNS automatizada y validación de políticas. Si un subdominio devuelve NXDOMAIN o un registro DMARC nulo, el atacante prueba si el correo falsificado desde ese subdominio pasa DMARC. Si lo hace, el subdominio se convierte en un vector de phishing persistente.

Esta guía explica cómo funciona realmente la herencia de DMARC en subdominios, dónde falla la herencia silenciosamente, y cómo configurar la aplicación que cierra brechas explotables antes de que los atacantes las encuentren.

I. Cómo Funciona la Herencia de Política DMARC (y Dónde se Rompe)

Diagrama de flujo que muestra la secuencia de consultas de registros DMARC desde el subdominio hasta el dominio organizativo, con aplicación de la política heredada cuando no existe un registro específico.

Cuando un servidor de correo receptor evalúa DMARC para [email protected], consulta DNS en busca de un registro DMARC en _dmarc.marketing.example.com. Si no existe registro, el servidor consulta _dmarc.example.com. Si existe un registro en el dominio organizacional, el subdominio hereda la política definida en ese registro.

Este mecanismo de herencia funciona correctamente cuando:

  • El dominio organizacional (example.com) publica un registro DMARC
  • El subdominio (marketing.example.com) no publica un registro DMARC
  • El subdominio envía correo que se alinea con la configuración SPF o DKIM del dominio organizacional

La herencia falla cuando:

  • El registro DMARC del dominio organizacional contiene errores de sintaxis, por lo que el registro es ignorado y el subdominio efectivamente no hereda ninguna política
  • El subdominio envía correo a través de un servicio de terceros que usa su propio dominio de remitente de sobre, rompiendo la alineación SPF
  • El servicio de terceros no firma con un selector DKIM bajo el dominio organizacional, rompiendo la alineación DKIM
  • El subdominio está registrado en DNS pero no gestionado activamente, por lo que los atacantes pueden reclamarlo a través de recuperación de cuenta del proveedor de hosting, vulnerabilidades del proveedor DNS, o registro de dominio expirado

Cuando la herencia falla, el correo del subdominio o bien falla DMARC silenciosamente (si la política organizacional es p=none o p=quarantine) o falla DMARC visiblemente pero aún llega a la bandeja de entrada (si el servidor receptor no respeta la aplicación o aplica anulaciones de reputación).

II. Escenarios Comunes de Fallo de DMARC en Subdominios

Proceso de cuatro pasos que muestra cómo el modo de alineación estricta provoca que los correos electrónicos enviados desde un subdominio a través de Mailchimp no cumplan con la política DMARC heredada.

Escenario 1: La Política del Dominio Organizacional Existe pero la Autenticación del Subdominio no se Alinea

Configuración:

  • example.com publica v=DMARC1; p=reject; aspf=s; adkim=s
  • marketing.example.com envía correo a través de Mailchimp
  • Remitente de sobre de Mailchimp: [email protected]
  • Firma DKIM de Mailchimp: d=mcdlv.net

Qué ocurre:

  • DMARC consulta _dmarc.marketing.example.com → sin registro
  • DMARC consulta _dmarc.example.com → encuentra p=reject; aspf=s; adkim=s
  • SPF evalúa [email protected] → pasa SPF para mcdlv.net, no marketing.example.com
  • DKIM evalúa firma con d=mcdlv.net → pasa DKIM para mcdlv.net, no marketing.example.com
  • La verificación de alineación DMARC falla porque ni SPF ni DKIM se alinean con marketing.example.com en modo estricto
  • Resultado: La política heredada instruye a los receptores a rechazar el mensaje, pero debido a que la política fue heredada y no establecida explícitamente para el subdominio, algunos receptores pueden aplicar aplicación más laxa

Solución:
Publicar un registro DMARC explícito en _dmarc.marketing.example.com:

v=DMARC1; p=none; rua=mailto:[email protected]; sp=reject

Luego configurar Mailchimp para firmar DKIM con d=marketing.example.com o d=example.com, para que la alineación DKIM pase bajo modo relajado.

Alternativamente, usar aspf=r; adkim=r en el dominio organizacional para permitir alineación relajada para subdominios.

Escenario 2: Subdominio Registrado en DNS pero No Gestionado Activamente

Configuración:

  • example.com publica v=DMARC1; p=reject
  • dev.example.com existe en DNS pero ya no envía correo y ya no aloja servicios
  • El atacante descubre dev.example.com mediante enumeración DNS
  • El atacante reclama dev.example.com a través de recuperación de cuenta del proveedor de hosting, vulnerabilidad del proveedor DNS, o expiración de dominio

Qué ocurre:

  • El atacante configura infraestructura de correo en dev.example.com
  • El atacante envía correo de phishing desde [email protected]
  • DMARC consulta _dmarc.dev.example.com → sin registro
  • DMARC consulta _dmarc.example.com → encuentra p=reject
  • La infraestructura de correo controlada por el atacante usa SPF y DKIM controlados por el atacante, ambos se alinean con dev.example.com bajo modo de alineación relajado
  • DMARC pasa porque el atacante controla el subdominio y puede configurar autenticación conforme
  • El correo llega a la bandeja de entrada a pesar de la aplicación del dominio organizacional

Solución:
Publicar explícitamente p=reject en _dmarc.dev.example.com:

v=DMARC1; p=reject; rua=mailto:[email protected]

Eliminar registros DNS para subdominios inactivos. Si el subdominio debe permanecer registrado, publicar un registro MX nulo para señalar que el subdominio no envía ni recibe correo:

dev.example.com. IN MX 0 .

Monitorear informes DMARC para autenticación inesperada desde subdominios.

Escenario 3: Error de Sintaxis en la Política del Dominio Organizacional Rompe la Herencia

Configuración:

  • example.com publica:
v=DMARC1; p=reject; rua=mailto:[email protected]; pct=50
  • newsletter.example.com envía correo
  • No existe registro DMARC explícito para newsletter.example.com

Qué ocurre:

  • DMARC consulta _dmarc.newsletter.example.com → sin registro
  • DMARC consulta _dmarc.example.com → encuentra registro con pct=50
  • Muchas implementaciones DMARC modernas ignoran pct= o tratan la aplicación basada en porcentaje de manera inconsistente
  • El subdominio hereda una política que puede no ser aplicada de manera predecible
  • Los atacantes envían correo falsificado desde newsletter.example.com y observan si se aplica la aplicación

Solución:
Eliminar pct= de la política del dominio organizacional:

v=DMARC1; p=reject; rua=mailto:[email protected]

Escalonar la aplicación por subdominio o grupo de remitente, no por porcentaje.

III. Patrones de Configuración de Política Explícita de Subdominio

Arquitectura de tres capas que muestra las etapas de un ataque de toma de control de subdominios, desde el descubrimiento hasta el compromiso y la explotación.

Patrón 1: Heredar Política del Dominio Organizacional (Comportamiento Predeterminado)

Registro del dominio organizacional:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Comportamiento del subdominio:

  • marketing.example.com hereda p=reject
  • support.example.com hereda p=reject
  • Todos los subdominios heredan p=reject a menos que exista un registro explícito

Cuándo usar:

  • Controlas todos los subdominios
  • Todos los subdominios envían correo a través de infraestructura que se alinea con SPF o DKIM del dominio organizacional

Patrón 2: Anular Política Heredada para Subdominios Específicos

Registro del dominio organizacional:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Anulación de subdominio:

_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Resultado:

  • marketing.example.com usa p=none
  • Todos los demás subdominios heredan p=reject

Cuándo usar:

  • Un subdominio específico envía correo a través de servicios de terceros que aún no pueden alinearse con la autenticación del dominio organizacional
  • Necesitas visibilidad sobre los resultados de autenticación antes de aplicar política en el subdominio

Patrón 3: Establecer Política de Subdominio a Nivel de Dominio Organizacional

Registro del dominio organizacional:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]"

Resultado:

  • example.com usa p=reject
  • Todos los subdominios heredan p=quarantine (definido por sp=)

Cuándo usar:

  • Quieres diferente aplicación para el dominio organizacional vs. subdominios
  • Los subdominios envían correo de menor volumen o menor riesgo

Patrón 4: Aplicación Explícita para Cada Subdominio

Registro del dominio organizacional:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Registros explícitos de subdominio:

_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
_dmarc.support.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
_dmarc.newsletter.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Cuándo usar:

  • Quieres máxima visibilidad y control
  • Quieres eliminar ambigüedad sobre qué política se aplica
  • Quieres detectar intentos de apropiación de subdominios a través de anomalías en informes

IV. Interacción entre Modo de Alineación y Herencia de Subdominios

El modo de alineación DMARC (aspf= para SPF, adkim= para DKIM) controla si la alineación requiere una coincidencia exacta de dominio (modo estricto) o permite coincidencia de dominio organizacional (modo relajado).

Modo relajado (aspf=r; adkim=r):

  • SPF pasa si el dominio del remitente de sobre es mail.example.com y el From del encabezado es [email protected]
  • DKIM pasa si el dominio de firma DKIM es mail.example.com y el From del encabezado es [email protected]

Modo estricto (aspf=s; adkim=s):

  • SPF pasa solo si el dominio del remitente de sobre coincide exactamente con el dominio del From del encabezado
  • DKIM pasa solo si el dominio de firma DKIM coincide exactamente con el dominio del From del encabezado

Interacción de herencia de subdominios:
Cuando un subdominio hereda una política con modo de alineación estricto, el correo de ese subdominio debe alinearse exactamente. Si el subdominio envía a través de un servicio de terceros que usa su propio dominio para SPF o DKIM, la alineación estricta falla.

Ejemplo:

  • Dominio organizacional: v=DMARC1; p=reject; aspf=s; adkim=s
  • Subdominio: marketing.example.com envía a través de Mailchimp
  • Mailchimp usa [email protected] para remitente de sobre
  • Mailchimp firma DKIM con d=mcdlv.net
  • DMARC evalúa alineación estricta: tanto SPF como DKIM fallan en alineación
  • Resultado: DMARC falla, la política instruye rechazar

Opciones de solución:

  1. Cambiar política del dominio organizacional a modo relajado: aspf=r; adkim=r
  2. Publicar política explícita de subdominio con modo relajado: v=DMARC1; p=reject; aspf=r; adkim=r
  3. Configurar Mailchimp para firmar DKIM con selector de dominio organizacional o subdominio

V. Patrones de Ataque de Apropiación de Subdominios y Brechas DMARC

La apropiación de subdominios ocurre cuando un atacante reclama el control de un subdominio que una organización registró pero ya no gestiona activamente. Los vectores de ataque comunes incluyen:

  1. Hosting DNS expirado: El CNAME del subdominio apunta a una cuenta de proveedor de hosting que expiró. El atacante registra una nueva cuenta con el mismo proveedor y reclama el subdominio.
  2. CNAME colgante: El CNAME del subdominio apunta a un servicio (GitHub Pages, AWS S3, Heroku, etc.) que ya no existe. El atacante registra el nombre del servicio y sirve contenido desde el subdominio.
  3. Compromiso de cuenta del proveedor DNS: El atacante obtiene acceso a la cuenta del proveedor DNS mediante reutilización de credenciales, phishing o vulnerabilidad del proveedor. El atacante modifica registros de subdominio para apuntar a infraestructura controlada por el atacante.

La herencia DMARC no previene la apropiación de subdominios. Si un atacante controla la infraestructura del subdominio, el atacante puede configurar SPF y DKIM para alinearse con el subdominio, pasando DMARC incluso cuando el dominio organizacional aplica p=reject.

Detección y prevención:

  1. Políticas explícitas de subdominio: Publicar registros DMARC en cada subdominio para obtener visibilidad sobre la actividad de autenticación.
  2. Monitoreo DNS: Monitorear registros DNS para cambios inesperados en registros A, AAAA, CNAME, MX o TXT de subdominios.
  3. Análisis de informes DMARC: Revisar informes DMARC para autenticación desde subdominios que no deberían enviar correo.
  4. Registros MX nulos: Publicar MX nulo para subdominios que no envían ni reciben correo:
inactive.example.com. IN MX 0 .
  1. Eliminar registros DNS no utilizados: Eliminar registros A, AAAA y CNAME para subdominios que ya no sirven contenido o envían correo.

VI. Depuración de Fallos de Política DMARC Heredada

Cuando un subdominio hereda una política DMARC pero el correo falla la aplicación inesperadamente, sigue este proceso de diagnóstico:

Paso 1: Verificar la Sintaxis de la Política del Dominio Organizacional

Consultar el registro DMARC del dominio organizacional:

dig TXT _dmarc.example.com +short

Salida esperada:

"v=DMARC1; p=reject; rua=mailto:[email protected]"

Errores de sintaxis comunes que rompen la herencia:

  • Falta v=DMARC1
  • Valor p= inválido (debe ser none, quarantine o reject)
  • Dirección rua= mal formada
  • Inclusión de etiqueta obsoleta pct=

Si existen errores de sintaxis, el registro puede ser ignorado, causando que los subdominios no hereden ninguna política.

Paso 2: Verificar Ausencia o Presencia de Registro de Subdominio

Consultar el registro DMARC del subdominio:

dig TXT _dmarc.marketing.example.com +short

Salida esperada (si está heredando):

(sin salida)

Salida esperada (si hay anulación explícita):

"v=DMARC1; p=none; rua=mailto:[email protected]"

Si existe un registro en el subdominio, la herencia no ocurre. El subdominio usa su propia política.

Paso 3: Verificar Alineación SPF

Verificar el resultado SPF y la alineación en informes DMARC o encabezados de correo.

Fallo común de alineación SPF:

  • Dominio de remitente de sobre: [email protected]
  • Dominio From del encabezado: [email protected]
  • SPF pasa para mail.thirdpartyservice.com
  • La alineación SPF falla porque el dominio del remitente de sobre no coincide con el dominio From del encabezado

Solución:

  • Configurar el servicio de terceros para usar el dominio organizacional o subdominio como remitente de sobre
  • Usar modo de alineación relajado a nivel de dominio organizacional o subdominio

Paso 4: Verificar Alineación DKIM

Verificar el dominio de firma DKIM en los encabezados de correo:

DKIM-Signature: v=1; a=rsa-sha256; d=thirdpartyservice.com; s=selector; ...

Si d=thirdpartyservice.com y el From del encabezado es [email protected], la alineación DKIM falla en modo estricto.

Solución:

  • Configurar el servicio de terceros para firmar DKIM con d=marketing.example.com o d=example.com
  • Usar modo de alineación relajado a nivel de dominio organizacional o subdominio

Paso 5: Revisar Informes DMARC para Actividad de Subdominio

Los informes agregados DMARC incluyen resultados de autenticación de subdominios. Buscar:

  • Subdominios que no reconoces
  • Altas tasas de fallo desde subdominios conocidos
  • Autenticación desde direcciones IP que no controlas

Si un subdominio aparece en informes pero no controlas la infraestructura del subdominio, investiga apropiación de subdominios.

En una implementación gestionada de Skysnag, usa el destino de informes generado por Skysnag. Lo siguiente es solo un ejemplo manual:

v=DMARC1; p=none; rua=mailto:[email protected]

Un registro estático tradicional puede funcionar, pero solo si los informes son activamente recibidos, analizados, procesados y se actúa sobre ellos.

VII. Estrategia Recomendada de Configuración DMARC para Subdominios

  1. Publicar política de dominio organizacional:
v=DMARC1; p=reject; rua=mailto:[email protected]; sp=quarantine

Esto aplica p=reject para el dominio organizacional y p=quarantine para todos los subdominios por defecto.

  1. Publicar políticas explícitas para subdominios activos:
_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
_dmarc.support.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Esto proporciona visibilidad sobre la actividad de autenticación y permite aplicación escalonada por subdominio.

  1. Eliminar registros DNS para subdominios inactivos.
  2. Publicar MX nulo para subdominios que no envían ni reciben correo:
inactive.example.com. IN MX 0 .
  1. Monitorear informes DMARC para actividad inesperada de subdominios.

Usa Skysnag Protect para identificar remitentes legítimos, detectar fuentes no autorizadas y avanzar hacia la aplicación:

VIII. Conclusiones Clave

La herencia DMARC de subdominios funciona solo cuando el dominio organizacional publica un registro DMARC válido y el subdominio no publica su propio registro. La herencia falla cuando la política del dominio organizacional contiene errores de sintaxis, el subdominio envía correo a través de servicios de terceros que no se alinean, o el subdominio está registrado pero no gestionado activamente, creando oportunidades de apropiación de subdominios.

Publica políticas DMARC explícitas para todos los subdominios activos para obtener visibilidad y control. Elimina registros DNS para subdominios inactivos. Usa registros MX nulos para subdominios que no envían ni reciben correo. Monitorea informes DMARC para actividad de autenticación de subdominios inesperada.

Comienza el monitoreo DMARC con Skysnag y obtén tu registro DMARC gratuito: