Migração DMARC para DMARCbis

Guia de migração de DMARC para DMARCbis

Por que migrar?

A migração de DMARC para DMARCbis não impõe nenhum prazo. Seus registros DMARC atuais continuam funcionando. No entanto, usar uma ferramenta de migração permite:

• Proteger subdomínios inexistentes com a tag np, fechando uma brecha explorada por atacantes
• Simplificar a gestão removendo tags ignoradas pelos receptores modernos
• Declarar seu escopo organizacional com psd=n, clarificando a hierarquia DNS para os receptores

Etapas da migração

1. Remover as tags obsoletas

2. Adicionar a tag np

Escolha uma política para subdomínios inexistentes:

• np=reject: recomendado se p=reject (proteção máxima)
• np=quarantine: abordagem intermediária
• np=none: apenas monitoramento

Se np estiver ausente, aplica-se a política de sp (depois a de p).

3. Avaliar a tag t

• Se você usa atualmente pct=0 para o modo de teste, mude para t=y
• Se sua política está plenamente aplicada, nenhuma ação necessária (o padrão t=n é equivalente)
• Não combine pct e t: t sempre tem precedência

4. Declarar psd se pertinente

• Domínio organizacional (captaindns.com): psd=n declara que você não é um sufixo público
• Registry (.bank, .gov.uk): psd=y permite a publicação de uma política para todos os registrantes
• Padrão: psd=u (indeterminado), o tree walk DNS determina o domínio organizacional

Exemplo de migração

Antes:

v=DMARC1; p=reject; sp=quarantine; pct=100; ri=86400; rua=mailto:dmarc@captaindns.com

Depois:

v=DMARC1; p=reject; sp=quarantine; np=reject; psd=n; rua=mailto:dmarc@captaindns.com

Modificações:

• pct=100 removido (equivalente ao padrão t=n)
• ri=86400 removido (ignorado pelos receptores)
• np=reject adicionado (proteção de subdomínios inexistentes)
• psd=n adicionado (declaração do escopo organizacional)

Exemplos reais de migração

Aqui estão três cenários representativos que você pode encontrar ao migrar seu registro DMARC para DMARCbis.

Cenário 1: registro com pct parcial

Antes:

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@captaindns.com

Depois:

v=DMARC1; p=quarantine; t=y; np=quarantine; rua=mailto:dmarc@captaindns.com

O valor pct=50 significa que a política era aplicada apenas à metade das mensagens. No DMARCbis, essa abordagem granular é substituída por um modo binário. A tag t=y ativa o modo de teste: receptores DMARCbis aplicam a política um nível abaixo (quarantine se torna none). A tag np=quarantine herda da política p para proteger os subdomínios inexistentes.

Cenário 2: registro rigoroso sem tags obsoletas

Antes:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@captaindns.com

Depois:

v=DMARC1; p=reject; sp=reject; np=reject; psd=n; rua=mailto:dmarc@captaindns.com

Este registro já está limpo: nenhuma tag obsoleta para remover. Basta adicionar np=reject para cobrir os subdomínios inexistentes e psd=n para declarar que o domínio não é um sufixo público. A migração consiste em adicionar duas tags sem alterar a política existente.

Cenário 3: registro com todas as tags obsoletas

Antes:

v=DMARC1; p=reject; pct=100; ri=86400; rf=afrf; rua=mailto:dmarc@captaindns.com

Depois:

v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@captaindns.com

Aqui, três tags obsoletas são removidas de uma vez. pct=100 corresponde ao comportamento padrão (aplicação completa), portanto nenhuma tag t é necessária. ri=86400 nunca influenciou realmente a frequência dos relatórios. rf=afrf era o único valor possível, agora implícito. A tag np=reject é adicionada para proteção completa.

O que acontece durante a transição?

O período de transição entre DMARC e DMARCbis não apresenta nenhum risco para a entregabilidade dos seus emails. Eis o motivo:

• Tags desconhecidas são ignoradas: receptores que ainda não suportam DMARCbis simplesmente ignoram as tags np, t e psd. Continuam aplicando p, sp e rua como antes.
• A versão permanece v=DMARC1: DMARCbis não altera o identificador de versão. Nenhum receptor rejeitará seu registro por causa da atualização.
• A tag t na prática: um receptor DMARCbis aplica o modo de teste se t=y estiver presente. Um receptor DMARC v1 não reconhece t e aplica a política p diretamente a 100%. Isso significa que durante a transição, seus emails se beneficiam do nível de proteção mais elevado dos dois padrões.
• Adoção gradual: os grandes provedores (Google, Microsoft, Yahoo) adotam as novas especificações de forma progressiva. A coexistência dos dois comportamentos deve durar vários anos.
• Nenhuma ação urgente necessária: seus registros DMARC atuais permanecem funcionais. A migração pode ser feita no seu próprio ritmo, sem janela de manutenção nem interrupção de serviço.

Estratégia de rollout recomendada

Para migrar com segurança, siga estas quatro etapas na ordem:

Etapa 1: Auditar o registro atual. Use nosso DMARCbis Checker para analisar seu registro DMARC publicado. A ferramenta identifica as tags obsoletas e avalia a conformidade com DMARCbis.

Etapa 2: Remover as tags obsoletas. Exclua pct, rf e ri do seu registro. Essas tags não têm efeito no DMARCbis e sua presença adiciona complexidade desnecessária à sua configuração DNS.

Etapa 3: Adicionar as novas tags. Adicione np=reject (ou a política de sua escolha) para proteger os subdomínios inexistentes. Adicione psd=n para declarar explicitamente seu escopo organizacional. Ambas as adições reforçam sua postura de segurança de email sem modificar a política principal.

Etapa 4: Testar antes de aplicar. Se você está migrando de uma política flexível (none ou quarantine) para uma política rigorosa (reject), use t=y por algumas semanas. Monitore seus relatórios agregados DMARC para verificar que nenhum fluxo legítimo é impactado. Após validar os relatórios, remova a tag t (o padrão t=n aplica a política integralmente).

Erros comuns a evitar

Esquecer de desativar o modo de teste. A tag t=y é útil durante a fase de validação, mas reduz intencionalmente o nível de proteção. Defina um lembrete para mudar para t=n (ou remover a tag) após seu período de teste.

Confundir np com sp. A tag sp define a política para subdomínios existentes. A tag np visa exclusivamente subdomínios inexistentes, aqueles que os atacantes fabricam para contornar as proteções. Ambas as tags desempenham papéis distintos e complementares.

Remover acidentalmente a tag rua. Ao limpar seu registro, certifique-se de manter a tag rua apontando para seu endereço de relatórios agregados. Sem relatórios, você perde toda a visibilidade sobre tentativas de spoofing e problemas de alinhamento.

Declarar psd=y sem ser um registry. A tag psd=y é reservada para registries de sufixos públicos (como .bank ou .gov.uk). Se você é proprietário de um domínio organizacional padrão, use psd=n. Uma declaração incorreta poderia enviar um sinal errado aos receptores e complicar o tree walk DNS.

Migrar sem revisar os relatórios existentes. Antes de modificar seu registro, analise seus relatórios agregados DMARC recentes. Eles revelam quais remetentes legítimos ainda não estão alinhados com SPF ou DKIM. Migrar sem essa verificação arrisca bloquear fluxos de email legítimos ao mudar para uma política mais rigorosa.

Ferramentas relacionadas

Antes de migrar, verifique a compatibilidade DMARCbis atual do seu domínio com o DMARCbis Checker. O checker realiza uma análise tree walk DNS completa e deteta todas as tags obsoletas.

Para uma auditoria DMARC completa, explore estas ferramentas:

• Validador DMARC para validar a sintaxe do seu registro DMARC
• Inspetor DMARC para consultar e analisar o registro DMARC publicado no seu domínio
• Gerador DMARC para criar um novo registro DMARC
• Leitor de relatórios DMARC para descodificar relatórios agregados XML

Saiba mais sobre as alterações do protocolo: DMARCbis: todas as alterações e como se preparar.