Porque 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 aplica-se a 100% do tráfego por predefinição, resta apenas um formato de relatório definido e o intervalo de remessa fica imposto por predefiniçã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 percentagem. Mais simples, mais previsível, mais alinhado com o comportamento real dos recetores. - Tree walk DNS para identificar o domínio organizacional, substituindo a Public Suffix List.
O seu registo DMARC atual continua a funcionar durante a transição. Migrar agora significa estar pronto na publicação oficial e beneficiar imediatamente da proteção de subdomínios inexistentes via np.
Como funciona o analisador
A ferramenta analisa o seu registo 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 em falta). |
| Migração maior | 50 a 74 | Quatro alterações ou mais. Várias tags depreciadas presentes e política fraca. |
| Registo inválido | 0 a 49 ou estado inválido | Erros de sintaxe a corrigir antes da migração. |
| Sem registo | N/A | Campo vazio. Cole primeiro um registo DMARC antes da análise. |
As seis dimensões da pontuação
| Dimensão | Ponderação | O que a dimensão mede |
|---|---|---|
| Tags depreciadas em falta | 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 estiver em falta. |
| 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 | Registo 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 | Porquê |
|---|---|---|
pct | Remover | A política aplica-se a 100% por predefiniçã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 recetores impõem um intervalo de relatório predefinido. |
Tag adicionada
| Tag | Valor | Porquê |
|---|---|---|
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 registo atual. Execute a análise com o seu registo DMARC publicado. Anote a pontuação, o veredicto e as recomendações.
Passo 2: aplicar as alterações propostas. Copie o registo migrado e publique-o na sua zona DNS em _dmarc.captaindns.com. Mantenha o registo anterior por 48 horas com um TTL curto (300 segundos) para permitir um rollback rápido, se necessário.
Passo 3: monitorizar os relatórios rua. Durante duas a quatro semanas, verifique os 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, reponha o TTL em 3600 ou 86400 segundos. A migração está concluída.
Se também estiver a mudar de uma política flexível para p=reject, use t=y por algumas semanas. Os recetores 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 o seu endereço dedicado) no registo migrado.
Migrar sem rever 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 registo DMARC a partir do DNS |
| DMARC Validator | Validar a sintaxe de um registo DMARC v1 antes da publicação |
| Gerador DMARC | Criar um registo DMARC ou DMARCbis do zero |
| Leitor de relatórios DMARC | Descodificar relatórios agregados XML |
| Monitoring DMARC | Receba e analise automaticamente os seus relatórios DMARC agregados |