Melhores ferramentas de validação de registros DMARC

DMARC significa Domain-based Message Authentication, Reporting, and Conformance. É um registro TXT de DNS publicado em `_dmarc.yourdomain.com` que diz aos servidores de correo recetores o que fazer quando um e-mail que afirma ser do seu domínio falha nas verificações de autenticação. Sem DMARC, qualquer pessoa pode enviar e-mails que parecem vir do seu domínio - uma técnica chamada falsificação de domínio usada em ataques de phishing e de comprometimento de e-mail empresarial (BEC).

Um registro DMARC faz duas coisas: define uma política (que ação tomar com mensagens que falham) e configura os relatórios (para onde enviar resumos dos resultados de autenticação). A política pode ser `none` (monitorizar sem agir), `quarantine` (entregar no spam) ou `reject` (bloquear a mensagem por completo). As tags de relatório especificam os endereços de e-mail que recebem relatórios agregados XML diários dos principais fornecedores de correo.

A estrutura do registro DMARC

# Registro apenas de monitorização (ponto de partida seguro)
v=DMARC1; p=none; rua=mailto:[email protected]

# Quarentena com aplicação parcial e relatórios forenses
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=r; aspf=r

# Rejeição total - use apenas depois de confirmar que todos os remetentes passam
v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:[email protected]; adkim=s; aspf=s

• v=DMARC1: Tag de versão - obrigatória, deve vir primeiro, exatamente como está escrita.
• p=: Política aplicada ao domínio - `none`, `quarantine` ou `reject`.
• sp=: Política de subdomínios - sobrepõe-se a p= para subdomínios se definida.
• rua=: Destino do relatório agregado - um URI mailto: (ou URI de um serviço de relatórios).
• ruf=: Destino do relatório forense - relatórios individuais de falhas (menos comum, implicações de privacidade).
• pct=: Percentagem de mensagens a que se aplica a política - útil para lançamento gradual (1-100).
• adkim=: Modo de alinhamento DKIM - `r` (relaxado) ou `s` (estrito).
• aspf=: Modo de alinhamento SPF - `r` (relaxado) ou `s` (estrito).

O DMARC não autentica e-mail por si só - é uma camada de orquestração que se apoia no SPF e no DKIM. Quando um servidor de correo recetor recebe um e-mail que afirma ser do seu domínio, verifica duas coisas: a mensagem passou no SPF ou no DKIM, e o domínio autenticado alinha com o domínio do cabeçalho From? Se pelo menos um dos dois passar e alinhar, o DMARC passa. Se nenhum passar com alinhamento, o servidor recetor aplica a política do seu registro DMARC.

Autenticação e alinhamento SPF

SPF (Sender Policy Framework) autoriza que servidores de correo podem enviar e-mail em nome do seu domínio. A verificação é feita contra o remetente do envelope SMTP (o endereço `MAIL FROM`), não contra o cabeçalho From visível. Para o alinhamento DMARC, o domínio do `MAIL FROM` deve corresponder (ou ser um subdomínio, em modo relaxado) ao domínio do cabeçalho From. Quando envia através de um serviço de terceiros como Mailchimp ou SendGrid, o domínio de return-path deles costuma ser `mailchimp.com` - isso quebra o alinhamento SPF a menos que configure um subdomínio de return-path personalizado. Use o Validador de registros SPF para verificar o seu registro SPF quanto a erros de sintaxe e violações do limite de lookups antes de confiar nele para o alinhamento DMARC.

Autenticação e alinhamento DKIM

DKIM (DomainKeys Identified Mail) adiciona uma assinatura criptográfica aos e-mails enviados. A assinatura inclui uma tag `d=` que especifica o domínio assinante. Para o alinhamento DMARC, o domínio `d=` deve corresponder (ou ser um subdomínio, em modo relaxado) ao domínio do cabeçalho From. O alinhamento DKIM é mais robusto para remetentes de terceiros porque pode configurá-los para assinar com o seu próprio domínio em vez do deles. O Validador de registros DKIM verifica se o registro DNS da chave pública para um determinado seletor está corretamente formatado e acessível.

Para passar na autenticação DMARC, as mensagens devem ser autenticadas por SPF ou DKIM, e o domínio autenticador deve alinhar com o domínio do cabeçalho From.

Validar um registro DMARC exige verificar três coisas: que o registro DNS existe e é acessível, que a sintaxe está correta e que SPF e DKIM estão configurados para suportar o alinhamento de que o DMARC depende. Cada passo pode ser feito rapidamente com as ferramentas certas.

A maioria dos problemas de validação de DMARC enquadra-se em categorias previsíveis. Muitos são erros simples de sintaxe que um validador deteta imediatamente; outros são problemas de configuração mais subtis que exigem compreender o alinhamento para diagnosticar corretamente.

Erros de sintaxe e de tags

• v=DMARC1 em falta como primeira tag: A tag de versão deve ser o primeiro campo. Se qualquer outra tag a preceder, o registro é inválido.
• Tag p= em falta: A tag de política é obrigatória. Um registro sem p= está malformado e é ignorado pela maioria dos servidores de correo.
• Valor de p= inválido: Apenas `none`, `quarantine` e `reject` são válidos. Qualquer outro valor (p. ex. `monitor`) faz com que o registro seja rejeitado.
• Ponto e vírgula em falta entre tags: As tags devem ser separadas por ponto e vírgula. Um separador em falta faz o parser fundir duas tags numa tag inválida.
• Espaços à volta dos sinais =: `p = none` (com espaços) é inválido em alguns parsers. Use `p=none` sem espaços.
• Formato de URI rua= inválido: O valor de rua= deve ser um URI `mailto:` válido. Um endereço de e-mail simples sem `mailto:` é um erro de sintaxe.

Erros de alinhamento e autenticação

Os erros de alinhamento são mais difíceis de diagnosticar do que os erros de sintaxe porque exigem compreender os cabeçalhos do e-mail. O cenário mais comum: configurou o SPF corretamente para envios diretos do seu próprio servidor de correo, mas quando o e-mail é enviado através de uma plataforma de marketing de terceiros, o `MAIL FROM` usa o domínio da plataforma - quebrando o alinhamento SPF. A correção é configurar a assinatura DKIM com o seu próprio domínio na plataforma de terceiros, ou estabelecer um subdomínio de return-path personalizado que mapeie para o seu domínio.

O erro mais comum na implantação de DMARC é definir `p=reject` antes de confirmar que todos os fluxos de e-mail legítimos se autenticam corretamente. E-mails de serviços de envio esquecidos - plataformas de e-mail transacional, CRM, sistemas de tickets, integrações de parceiros - serão bloqueados em silêncio, e o remetente pode só dar por isso quando recebe relatórios de queixas ou quando os utilizadores avisam de e-mails que faltam.

O lançamento em três fases

Um lançamento seguro de DMARC segue três fases. Na Fase 1 (semanas 1-4), publique `p=none` com um endereço de relatório `rua=` e analise os relatórios agregados para identificar todas as fontes de envio e as suas taxas de aprovação. Na Fase 2 (semanas 5-10), passe para `p=quarantine; pct=10` e aumente gradualmente o `pct=` à medida que os relatórios confirmarem a melhoria das taxas de aprovação - começar com 10% significa que apenas 10% das mensagens que falham são postas em quarentena, limitando o raio de impacto. Na Fase 3 (semana 11 em diante), passe para `p=reject` quando todos os remetentes legítimos passarem de forma consistente e os seus relatórios agregados mostrarem falhas de autenticação mínimas ou nulas de fontes legítimas.

O que procurar nos relatórios agregados

Os relatórios agregados mostram cada fonte que enviou e-mail afirmando ser do seu domínio. Procure os seus próprios servidores de correo, os seus fornecedores de serviços de correo e qualquer remetente de terceiros autorizado - todos devem mostrar taxas de aprovação elevadas tanto para SPF como para DKIM. Qualquer fonte com volume significativo e taxas de aprovação baixas precisa de investigação: ou é um remetente legítimo que precisa de corrigir a autenticação, ou é um remetente não autorizado que a aplicação deve bloquear. O DMARC Policy Rollout Planner guia-o na interpretação destes sinais e na escolha do momento certo para cada transição de fase.

Os relatórios DMARC são o ciclo de feedback que torna a aplicação segura. Sem relatórios agregados, está a voar às cegas - não consegue saber que fontes passam ou falham na autenticação, nem se uma mudança recente na infraestrutura de envio quebrou algo. Configurar os relatórios corretamente é tão importante quanto configurar a própria política.

Relatórios agregados (rua=)

A tag `rua=` especifica um URI `mailto:` que recebe relatórios agregados XML diários de cada grande fornecedor de correo (Google, Microsoft, Yahoo, etc.) que trata e-mail do seu domínio. Cada relatório é um ficheiro XML comprimido que mostra contagens de mensagens, IPs de origem, resultados SPF/DKIM/DMARC e disposição da política. O endereço recetor deve estar no mesmo domínio que o registro DMARC, ou ser um URI entre domínios com um registro de autorização publicado no domínio do terceiro. A maioria das organizações usa um serviço dedicado de relatórios DMARC em vez de uma caixa de entrada direta, porque os relatórios XML brutos exigem ferramentas de análise para serem úteis.

Relatórios forenses (ruf=)

A tag `ruf=` configura relatórios forenses (de falha) - cópias individuais de mensagens que falham no DMARC. Contêm mais detalhe do que os relatórios agregados mas têm implicações de privacidade: podem incluir cabeçalhos de e-mail, e alguns fornecedores deixaram de os enviar por razões de RGPD. A maioria dos praticantes de DMARC usa apenas `rua=` para dados agregados e omite `ruf=` salvo quando é necessária análise forense de casos de falha específicos.

Serviços de relatórios DMARC de terceiros

• Google Postmaster Tools: Painel gratuito que mostra a reputação do seu domínio e as taxas de aprovação de autenticação de e-mail na perspetiva do Gmail.
• Postmark DMARC: Parser gratuito de relatórios agregados com painel visual - bom para começar sem um serviço pago.
• Dmarcian: Plataforma paga abrangente com análise por fonte, alertas de problemas de autenticação e orientação de lançamento.
• Valimail: Plataforma DMARC de nível empresarial com recomendações automatizadas de aplicação baseadas na análise de relatórios.
• EasyDMARC: Plataforma de monitorização e gestão DMARC mid-market com informações acionáveis por fonte de envio.

Seguir estas práticas garante que a sua implantação de DMARC fornece proteção real sem perturbar o e-mail legítimo, e que a sua configuração se mantém correta à medida que a sua infraestrutura de envio evolui.

Valide sempre a pilha completa de autenticação de e-mail

Um registro DMARC só é tão eficaz quanto os registros SPF e DKIM que o suportam. Valide os três juntos: use o DMARC Record Validator para o registro de política, o Validador de registros SPF para verificar a sintaxe dos mecanismos e o limite de 10 lookups, e o Validador de registros DKIM para confirmar que a sua chave pública está corretamente publicada para cada seletor em uso. Revalide os três após qualquer alteração na infraestrutura de correo - um novo serviço de envio, uma migração de domínio ou a renovação de um certificado SSL podem afetar a publicação das chaves DKIM.

Use alinhamento relaxado durante a transição

O modo de alinhamento predefinido tanto para SPF como para DKIM é o relaxado (`adkim=r; aspf=r`), que permite que subdomínios satisfaçam o alinhamento para o domínio pai. É o ajuste certo durante um lançamento porque muitos remetentes legítimos usam subdomínios do seu domínio para autenticar. Mude para alinhamento estrito (`adkim=s; aspf=s`) apenas se tiver um requisito de segurança específico e tiver confirmado que todos os remetentes usam correspondência exata de domínio - o alinhamento estrito com um único remetente mal configurado quebra o DMARC para cada mensagem que esse remetente transmitir.

• Comece com p=none, nunca p=reject: Ganhe confiança nas suas taxas de aprovação de autenticação antes de aplicar a aplicação.
• Configure rua= antes de qualquer outra coisa: Não pode tomar decisões de política informadas sem os dados dos relatórios agregados.
• Consulte o assistente de planeamento de seletores DKIM: Use o DKIM Selector Planning Helper ao rodar chaves DKIM para evitar erros de sobreposição.
• Use pct= para aplicação gradual: Comece em pct=10 ao passar para quarantine ou reject - isto limita o impacto se algo estiver mal configurado.
• Revalide após cada alteração de plataforma de correo: Adicionar uma nova ferramenta de marketing, CRM ou sistema de tickets normalmente exige atualizar o SPF e configurar o DKIM.
• Monitorize a propagação DNS: Após publicar ou alterar um registro DMARC, use o DNS Propagation ETA Estimator para saber quando a alteração estará visível globalmente.