Tentativas de tomada de subdomínios agora comumente ignoram a autenticação de e-mail porque as organizações presumem que a herança de política DMARC funciona automaticamente. Mas não funciona. Quando um subdomínio não possui um registro DMARC explícito, o subdomínio herda a política do domínio organizacional—mas apenas se a política do domínio organizacional existir e estiver configurada corretamente. Se a herança falhar, atacantes podem enviar e-mails não autenticados de marketing.exemplo.com, suporte.exemplo.com ou qualquer subdomínio não reivindicado, mesmo quando exemplo.com aplica DMARC com p=reject.

A herança de DMARC em subdomínios cria três condições de falha que as equipes de segurança comumente perdem: (1) a política do domínio organizacional existe mas está mal configurada, então os subdomínios herdam uma política mais fraca do que o pretendido, (2) o subdomínio envia e-mails através de um serviço de terceiros que não se alinha com a autenticação do domínio organizacional, então a política herdada falha nas verificações de alinhamento, ou (3) o subdomínio está registrado no DNS mas não é gerenciado ativamente, criando uma lacuna explorável onde atacantes podem reivindicar o subdomínio através de vulnerabilidades no provedor de hospedagem ou provedor de DNS e enviar e-mails antes da detecção.

Campanhas de phishing baseadas em IA agora escaneiam essas lacunas usando enumeração automatizada de DNS e validação de políticas. Se um subdomínio retorna NXDOMAIN ou um registro DMARC nulo, o atacante testa se e-mails falsificados daquele subdomínio passam pelo DMARC. Se passar, o subdomínio se torna um vetor persistente de phishing.

Este guia explica como a herança de DMARC em subdomínios realmente funciona, onde a herança falha silenciosamente e como configurar uma aplicação que fecha lacunas exploráveis antes que os atacantes as encontrem.

I. Como Funciona a Herança de Política DMARC (e Onde Ela Falha)

Quando um servidor de e-mail receptor avalia DMARC para [email protected], ele consulta o DNS por um registro DMARC em _dmarc.marketing.exemplo.com. Se nenhum registro existir, o servidor consulta _dmarc.exemplo.com. Se um registro existir no domínio organizacional, o subdomínio herda a política definida naquele registro.

Este mecanismo de herança funciona corretamente quando:

• O domínio organizacional (exemplo.com) publica um registro DMARC
• O subdomínio (marketing.exemplo.com) não publica um registro DMARC
• O subdomínio envia e-mails que se alinham com a configuração SPF ou DKIM do domínio organizacional

A herança falha quando:

• O registro DMARC do domínio organizacional contém erros de sintaxe, então o registro é ignorado e o subdomínio efetivamente herda nenhuma política
• O subdomínio envia e-mails através de um serviço de terceiros que usa seu próprio domínio de remetente de envelope, quebrando o alinhamento SPF
• O serviço de terceiros não assina com um seletor DKIM sob o domínio organizacional, quebrando o alinhamento DKIM
• O subdomínio está registrado no DNS mas não é gerenciado ativamente, então atacantes podem reivindicá-lo através de recuperação de conta do provedor de hospedagem, vulnerabilidades do provedor de DNS ou registro de domínio expirado

Quando a herança falha, o e-mail do subdomínio ou falha DMARC silenciosamente (se a política organizacional for p=none ou p=quarantine) ou falha DMARC visivelmente mas ainda chega à caixa de entrada (se o servidor receptor não honrar a aplicação ou aplicar substituições de reputação).

II. Cenários Comuns de Falha de DMARC em Subdomínios

Cenário 1: Política do Domínio Organizacional Existe mas a Autenticação do Subdomínio está Desalinhada

Configuração:

• exemplo.com publica v=DMARC1; p=reject; aspf=s; adkim=s
• marketing.exemplo.com envia e-mails através do Mailchimp
• Remetente de envelope Mailchimp: [email protected]
• Assinatura DKIM Mailchimp: d=mcdlv.net

O que acontece:

• DMARC consulta _dmarc.marketing.exemplo.com → sem registro
• DMARC consulta _dmarc.exemplo.com → encontra p=reject; aspf=s; adkim=s
• SPF avalia [email protected] → passa SPF para mcdlv.net, não marketing.exemplo.com
• DKIM avalia assinatura com d=mcdlv.net → passa DKIM para mcdlv.net, não marketing.exemplo.com
• Verificação de alinhamento DMARC falha porque nem SPF nem DKIM se alinham com marketing.exemplo.com no modo estrito
• Resultado: A política herdada instrui receptores a rejeitar a mensagem, mas porque a política foi herdada e não explicitamente definida para o subdomínio, alguns receptores podem aplicar aplicação mais frouxa

Correção:
Publique um registro DMARC explícito em _dmarc.marketing.exemplo.com:

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

Depois configure o Mailchimp para assinar DKIM com d=marketing.exemplo.com ou d=exemplo.com, para que o alinhamento DKIM passe no modo relaxado.

Alternativamente, use aspf=r; adkim=r no domínio organizacional para permitir alinhamento relaxado para subdomínios.

Cenário 2: Subdomínio Registrado no DNS mas Não Gerenciado Ativamente

Configuração:

• exemplo.com publica v=DMARC1; p=reject
• dev.exemplo.com existe no DNS mas não envia mais e-mails e não hospeda mais serviços
• Atacante descobre dev.exemplo.com através de enumeração DNS
• Atacante reivindica dev.exemplo.com através de recuperação de conta do provedor de hospedagem, vulnerabilidade do provedor DNS ou expiração de domínio

O que acontece:

• Atacante configura infraestrutura de e-mail em dev.exemplo.com
• Atacante envia e-mail de phishing de [email protected]
• DMARC consulta _dmarc.dev.exemplo.com → sem registro
• DMARC consulta _dmarc.exemplo.com → encontra p=reject
• Infraestrutura de e-mail controlada pelo atacante usa SPF e DKIM controlados pelo atacante, ambos se alinham com dev.exemplo.com no modo de alinhamento relaxado
• DMARC passa porque o atacante controla o subdomínio e pode configurar autenticação compatível
• E-mail chega à caixa de entrada apesar da aplicação do domínio organizacional

Correção:
Publique explicitamente p=reject em _dmarc.dev.exemplo.com:

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

Remova registros DNS para subdomínios inativos. Se o subdomínio deve permanecer registrado, publique um registro MX nulo para sinalizar que o subdomínio não envia ou recebe e-mails:

dev.exemplo.com. IN MX 0 .

Monitore relatórios DMARC para autenticação inesperada de subdomínios.

Cenário 3: Erro de Sintaxe na Política do Domínio Organizacional Quebra a Herança

Configuração:

• exemplo.com publica:

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

• newsletter.exemplo.com envia e-mails
• Nenhum registro DMARC explícito existe para newsletter.exemplo.com

O que acontece:

• DMARC consulta _dmarc.newsletter.exemplo.com → sem registro
• DMARC consulta _dmarc.exemplo.com → encontra registro com pct=50
• Muitas implementações DMARC modernas ignoram pct= ou tratam aplicação baseada em porcentagem de forma inconsistente
• Subdomínio herda uma política que pode não ser aplicada de forma previsível
• Atacantes enviam e-mails falsificados de newsletter.exemplo.com e observam se a aplicação se aplica

Correção:
Remova pct= da política do domínio organizacional:

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

Estabeleça aplicação por subdomínio ou grupo de remetente, não por porcentagem.

III. Padrões de Configuração Explícita de Política de Subdomínio

Padrão 1: Herdar Política do Domínio Organizacional (Comportamento Padrão)

Registro do domínio organizacional:

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

Comportamento do subdomínio:

• marketing.exemplo.com herda p=reject
• suporte.exemplo.com herda p=reject
• Todos os subdomínios herdam p=reject a menos que um registro explícito exista

Quando usar:

• Você controla todos os subdomínios
• Todos os subdomínios enviam e-mails através de infraestrutura que se alinha com SPF ou DKIM do domínio organizacional

Padrão 2: Substituir Política Herdada para Subdomínios Específicos

Registro do domínio organizacional:

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

Substituição do subdomínio:

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

Resultado:

• marketing.exemplo.com usa p=none
• Todos os outros subdomínios herdam p=reject

Quando usar:

• Um subdomínio específico envia e-mails através de serviços de terceiros que ainda não podem se alinhar com a autenticação do domínio organizacional
• Você precisa de visibilidade dos resultados de autenticação antes de aplicar política no subdomínio

Padrão 3: Definir Política de Subdomínio no Nível do Domínio Organizacional

Registro do domínio organizacional:

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

Resultado:

• exemplo.com usa p=reject
• Todos os subdomínios herdam p=quarantine (definido por sp=)

Quando usar:

• Você quer aplicação diferente para domínio organizacional vs. subdomínios
• Subdomínios enviam e-mails de menor volume ou menor risco

Padrão 4: Aplicação Explícita para Cada Subdomínio

Registro do domínio organizacional:

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

Registros explícitos de subdomínio:

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

Quando usar:

• Você quer máxima visibilidade e controle
• Você quer eliminar ambiguidade sobre qual política se aplica
• Você quer detectar tentativas de tomada de subdomínio através de anomalias nos relatórios

IV. Interação entre Modo de Alinhamento e Herança de Subdomínio

O modo de alinhamento DMARC (aspf= para SPF, adkim= para DKIM) controla se o alinhamento requer uma correspondência exata de domínio (modo estrito) ou permite correspondência de domínio organizacional (modo relaxado).

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

• SPF passa se o domínio do remetente de envelope for mail.exemplo.com e o From do cabeçalho for [email protected]
• DKIM passa se o domínio da assinatura DKIM for mail.exemplo.com e o From do cabeçalho for [email protected]

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

• SPF passa apenas se o domínio do remetente de envelope corresponder exatamente ao domínio do From do cabeçalho
• DKIM passa apenas se o domínio da assinatura DKIM corresponder exatamente ao domínio do From do cabeçalho

Interação de herança de subdomínio:
Quando um subdomínio herda uma política com modo de alinhamento estrito, e-mails daquele subdomínio devem se alinhar exatamente. Se o subdomínio envia através de um serviço de terceiros que usa seu próprio domínio para SPF ou DKIM, o alinhamento estrito falha.

Exemplo:

• Domínio organizacional: v=DMARC1; p=reject; aspf=s; adkim=s
• Subdomínio: marketing.exemplo.com envia através do Mailchimp
• Mailchimp usa [email protected] para remetente de envelope
• Mailchimp assina DKIM com d=mcdlv.net
• DMARC avalia alinhamento estrito: tanto SPF quanto DKIM falham no alinhamento
• Resultado: DMARC falha, política instrui rejeição

Opções de correção:

1. Mudar política do domínio organizacional para modo relaxado: aspf=r; adkim=r
2. Publicar política explícita de subdomínio com modo relaxado: v=DMARC1; p=reject; aspf=r; adkim=r
3. Configurar Mailchimp para assinar DKIM com domínio organizacional ou seletor de subdomínio

V. Padrões de Ataque de Tomada de Subdomínio e Lacunas DMARC

A tomada de subdomínio ocorre quando um atacante obtém controle de um subdomínio que uma organização registrou mas não gerencia mais ativamente. Vetores de ataque comuns incluem:

1. Hospedagem DNS expirada: CNAME do subdomínio aponta para uma conta de provedor de hospedagem que expirou. Atacante registra nova conta com o mesmo provedor e reivindica o subdomínio.
2. CNAME pendente: CNAME do subdomínio aponta para um serviço (GitHub Pages, AWS S3, Heroku, etc.) que não existe mais. Atacante registra o nome do serviço e serve conteúdo do subdomínio.
3. Comprometimento de conta do provedor DNS: Atacante obtém acesso à conta do provedor DNS através de reutilização de credenciais, phishing ou vulnerabilidade do provedor. Atacante modifica registros de subdomínio para apontar para infraestrutura controlada pelo atacante.

A herança DMARC não previne a tomada de subdomínio. Se um atacante controla a infraestrutura do subdomínio, o atacante pode configurar SPF e DKIM para se alinhar com o subdomínio, passando DMARC mesmo quando o domínio organizacional aplica p=reject.

Detecção e prevenção:

1. Políticas explícitas de subdomínio: Publique registros DMARC em cada subdomínio para obter visibilidade da atividade de autenticação.
2. Monitoramento DNS: Monitore registros DNS para mudanças inesperadas em registros A, AAAA, CNAME, MX ou TXT de subdomínio.
3. Análise de relatórios DMARC: Revise relatórios DMARC para autenticação de subdomínios que não deveriam enviar e-mails.
4. Registros MX nulos: Publique MX nulo para subdomínios que não enviam ou recebem e-mails:

inativo.exemplo.com. IN MX 0 .

5. Remover registros DNS não utilizados: Exclua registros A, AAAA e CNAME para subdomínios que não servem mais conteúdo ou enviam e-mails.

VI. Depurando Falhas de Política DMARC Herdada

Quando um subdomínio herda uma política DMARC mas e-mails falham na aplicação inesperadamente, siga este processo de diagnóstico:

Etapa 1: Verificar Sintaxe da Política do Domínio Organizacional

Consulte o registro DMARC do domínio organizacional:

dig TXT _dmarc.exemplo.com +short

Saída esperada:

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

Erros de sintaxe comuns que quebram a herança:

• Falta v=DMARC1
• Valor p= inválido (deve ser none, quarantine ou reject)
• Endereço rua= malformado
• Inclusão da tag descontinuada pct=

Se erros de sintaxe existirem, o registro pode ser ignorado, fazendo com que subdomínios herdem nenhuma política.

Etapa 2: Verificar Ausência ou Presença de Registro do Subdomínio

Consulte o registro DMARC do subdomínio:

dig TXT _dmarc.marketing.exemplo.com +short

Saída esperada (se herdando):

(sem saída)

Saída esperada (se substituição explícita):

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

Se um registro existe no subdomínio, a herança não ocorre. O subdomínio usa sua própria política.

Etapa 3: Verificar Alinhamento SPF

Verifique o resultado SPF e alinhamento em relatórios DMARC ou cabeçalhos de e-mail.

Falha comum de alinhamento SPF:

• Domínio do remetente de envelope: [email protected]
• Domínio do From do cabeçalho: [email protected]
• SPF passa para mail.servicodeterceiros.com
• Alinhamento SPF falha porque o domínio do remetente de envelope não corresponde ao domínio do From do cabeçalho

Correção:

• Configure serviço de terceiros para usar domínio organizacional ou subdomínio como remetente de envelope
• Use modo de alinhamento relaxado no nível de domínio organizacional ou subdomínio

Etapa 4: Verificar Alinhamento DKIM

Verifique o domínio da assinatura DKIM nos cabeçalhos do e-mail:

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

Se d=servicodeterceiros.com e o From do cabeçalho for [email protected], o alinhamento DKIM falha no modo estrito.

Correção:

• Configure serviço de terceiros para assinar DKIM com d=marketing.exemplo.com ou d=exemplo.com
• Use modo de alinhamento relaxado no nível de domínio organizacional ou subdomínio

Etapa 5: Revisar Relatórios DMARC para Atividade de Subdomínio

Relatórios agregados DMARC incluem resultados de autenticação de subdomínio. Procure por:

• Subdomínios que você não reconhece
• Altas taxas de falha de subdomínios conhecidos
• Autenticação de endereços IP que você não controla

Se um subdomínio aparece em relatórios mas você não controla a infraestrutura do subdomínio, investigue para tomada de subdomínio.

Em uma implantação gerenciada do Skysnag, use o destino de relatórios gerado pelo Skysnag. O seguinte é apenas um exemplo manual:

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

Um registro estático tradicional pode funcionar, mas apenas se os relatórios forem ativamente recebidos, analisados, interpretados e aplicados.

VII. Estratégia Recomendada de Configuração DMARC de Subdomínio

1. Publique política do domínio organizacional:

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

Isso aplica p=reject para o domínio organizacional e p=quarantine para todos os subdomínios por padrão.

2. Publique políticas explícitas para subdomínios ativos:

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

Isso fornece visibilidade da atividade de autenticação e permite aplicação escalonada por subdomínio.

3. Remova registros DNS para subdomínios inativos.
4. Publique MX nulo para subdomínios que não enviam ou recebem e-mails:

inativo.exemplo.com. IN MX 0 .

5. Monitore relatórios DMARC para atividade inesperada de subdomínio.

Use o Skysnag Protect para identificar remetentes legítimos, detectar fontes não autorizadas e avançar para aplicação:

VIII. Principais Conclusões

A herança de DMARC de subdomínio funciona apenas quando o domínio organizacional publica um registro DMARC válido e o subdomínio não publica seu próprio registro. A herança falha quando a política do domínio organizacional contém erros de sintaxe, o subdomínio envia e-mails através de serviços de terceiros que não se alinham, ou o subdomínio está registrado mas não gerenciado ativamente, criando oportunidades de tomada de subdomínio.

Publique políticas DMARC explícitas para todos os subdomínios ativos para obter visibilidade e controle. Remova registros DNS para subdomínios inativos. Use registros MX nulos para subdomínios que não enviam ou recebem e-mails. Monitore relatórios DMARC para atividade de autenticação de subdomínio inesperada.

Comece o monitoramento DMARC com Skysnag e obtenha seu registro DMARC gratuito: