Por que migrar para DMARCbis?
O DMARCbis sucede à RFC 7489 publicada em 2015. O rascunho introduz quatro mudanças estruturais:
- Remoção de
pct,rf,ri: a política agora se aplica a 100% do tráfego por padrão, resta apenas um formato de relatório definido e o intervalo de remessa fica imposto por padrão. A tagfoé mantida. - Adição de
np: a política dos subdomínios inexistentes torna-se explícita, fechando uma brecha explorada por atacantes que inventam subdomínios fictícios. - Conversão de
pct<100emt=y: o modo de teste substitui a porcentagem. Mais simples, mais previsível, mais alinhado com o comportamento real dos receptores. - Tree walk DNS para identificar o domínio organizacional, substituindo a Public Suffix List.
Seu registro DMARC atual continua funcionando durante a transição. Migrar agora significa estar pronto na publicação oficial e beneficiar-se imediatamente da proteção de subdomínios inexistentes via np.
Como funciona o analisador
A ferramenta analisa seu registro DMARC v1, aplica as transformações DMARCbis e calcula uma pontuação de compatibilidade DMARCbis em 100. O cálculo é local, sem resolução DNS nem chamada externa.
Os cinco veredictos possíveis
| Veredicto | Pontuação | Significado |
|---|---|---|
| Já conforme | 90 a 100 | Nenhuma alteração necessária ou ajuste menor. Acompanhe a publicação oficial do RFC. |
| Migração parcial | 75 a 89 | Uma a três modificações menores (tipicamente pct=100 redundante ou np ausente). |
| Migração maior | 50 a 74 | Quatro alterações ou mais. Várias tags depreciadas presentes e política fraca. |
| Registro inválido | 0 a 49 ou estado inválido | Erros de sintaxe a corrigir antes da migração. |
| Sem registro | N/A | Campo vazio. Cole primeiro um registro DMARC antes da análise. |
As seis dimensões da pontuação
| Dimensão | Ponderação | O que a dimensão mede |
|---|---|---|
| Tags depreciadas ausentes | 40 pontos | Presença de pct, rf, ri. Quanto mais, maior a dedução. |
Tag np presente | 15 pontos | Política de subdomínios inexistentes explícita. Herda de sp ou p se ausente. |
| Força da política | 20 pontos | reject obtém o máximo, quarantine uma fração, none um crédito mínimo. |
| Alinhamento DKIM e SPF | 10 pontos | adkim=s e aspf=s obtêm o máximo, r mantém uma parte. |
rua configurado | 10 pontos | URI mailto válida para a remessa agregada. |
| Higiene sintática | 5 pontos | Registro bem formado e analisável. |
Três fatores prioritários são exibidos no topo do resultado para explicar a pontuação imediatamente, antes do detalhe dimensão por dimensão.
As mudanças-chave DMARC para DMARCbis
Tags removidas
| Tag | Ação | Por quê |
|---|---|---|
pct | Remover | A política se aplica a 100% por padrão. Se pct<100, a ferramenta converte o valor em t=y. |
rf | Remover | Resta apenas um formato de relatório definido no DMARCbis. |
ri | Remover | Os receptores impõem um intervalo de relatório padrão. |
Tag adicionada
| Tag | Valor | Por quê |
|---|---|---|
np | herda de sp ou p | Política para os subdomínios inexistentes. Deve ser explícita no DMARCbis. |
Tags mantidas inalteradas
v=DMARC1, p, sp, adkim, aspf, rua, ruf. A semântica permanece idêntica.
Plano de migração recomendado
Passo 1: auditar o registro atual. Execute a análise com seu registro DMARC publicado. Anote a pontuação, o veredicto e as recomendações.
Passo 2: aplicar as alterações propostas. Copie o registro migrado e publique-o em sua zona DNS em _dmarc.captaindns.com. Mantenha o registro anterior por 48 horas com um TTL curto (300 segundos) para permitir um rollback rápido, se necessário.
Passo 3: monitorar os relatórios rua. Durante duas a quatro semanas, verifique seus relatórios DMARC agregados para confirmar a ausência de impacto sobre os fluxos legítimos. A passagem para np pode revelar subdomínios ativos não documentados.
Passo 4: estabilizar o TTL. Após validar os relatórios, retorne o TTL para 3600 ou 86400 segundos. A migração está concluída.
Se você também estiver mudando de uma política flexível para p=reject, use t=y por algumas semanas. Os receptores DMARCbis aplicam então uma política um nível abaixo, o que serve de rede de segurança durante a fase de validação.
Erros comuns a evitar
Manter pct=100. Esse valor é redundante no DMARCbis. A tag inteira pode ser removida sem alterar o comportamento.
Confundir np e sp. sp visa os subdomínios existentes, np visa exclusivamente os subdomínios inexistentes. Ambas as tags são complementares, não intercambiáveis.
Combinar pct e t. No DMARCbis, t sempre tem precedência. Não faz sentido manter pct quando t=y está presente.
Remover rua durante a limpeza. O reporting agregado é a única fonte de verdade sobre a eficácia da sua política. Mantenha rua=mailto:reports@captaindns.com (ou seu endereço dedicado) no registro migrado.
Migrar sem revisar os relatórios existentes. Antes de endurecer a política, verifique quais remetentes legítimos ainda não estão alinhados com SPF ou DKIM. Migrar para p=reject sem essa etapa pode bloquear fluxos internos.
Declarar psd=y sem ser um registry. A tag psd=y é reservada para operadores de sufixos públicos como .bank ou .gov.uk. Para um domínio organizacional padrão, omita a tag ou use psd=n se quiser torná-la explícita.
Ferramentas relacionadas
| Ferramenta | Utilidade |
|---|---|
| DMARCbis Checker | Auditar um domínio publicado contra DMARCbis com tree walk DNS |
| DMARC Checker | Verificar a publicação e resolver o registro DMARC a partir do DNS |
| DMARC Validator | Validar a sintaxe de um registro DMARC v1 antes da publicação |
| Gerador DMARC | Criar um registro DMARC ou DMARCbis do zero |
| Leitor de relatórios DMARC | Decodificar relatórios agregados XML |
| Monitoring DMARC | Receba e analise automaticamente seus relatórios DMARC agregados |