DMARC está público desde 2012, mas a maioria dos domínios das empresas ainda não o impõe

Artigo original ↗ Discussão no Hacker News ↗

Apesar de ser um padrão desde 2012, o protocolo de autenticação de e-mail DMARC ainda não é imposto pela maioria dos domínios, deixando espaço para endereços remetentes falsificados e ataques de personificação. Comentadores descrevem como o DMARC, combinado com SPF e DKIM, pode reduzir o backscatter e melhorar a verificação da identidade do remetente, mas também destacam a complexidade operacional, a baixa qualidade das ferramentas, as configurações incorretas até em grandes empresas e o impacto limitado sobre spam que já passa pela autenticação. Muitos observam que os sistemas opacos de reputação dos grandes provedores de e-mail e sua indiferença a denúncias de abuso agora representam um obstáculo maior para um e-mail confiável e digno da confiança do usuário do que a simples ausência de registros DMARC.

O que o DMARC adiciona além de SPF/DKIM

  • Vários comentários explicam o DMARC como uma camada de política e alinhamento sobre SPF/DKIM: ele diz aos destinatários o que fazer quando as verificações falham (none/quarantine/reject) e garante que o “From” visível esteja alinhado com os domínios autenticados.
  • Benefícios citados:
    • Reduz spoofing e backscatter (por exemplo, menos bounces falsos e respostas automáticas de ausência).
    • Torna mais difícil a personificação de grandes marcas e domínios bem configurados.
    • Alguns provedores supostamente tratam domínios com DMARC aplicado de forma mais favorável para colocação na caixa de entrada; outros são céticos.

Desafios práticos e configurações incorretas

  • Muitas pequenas organizações e indivíduos não têm tempo nem conhecimento; o DNS costuma ser feito por copiar e colar, com registros de exemplo p=none deixados sem تغيير.
  • O DMARC é descrito como simples em teoria, mas complicado na prática (subdomínios, múltiplos remetentes, encaminhamento, ferramentas de marketing).
  • Erros de configuração são comuns até em grandes empresas; alguns administradores ignoram falhas de SPF/DKIM/DMARC para evitar perder e-mails de clientes.
  • Outros se recusam a colocar em whitelist e, em vez disso, pressionam a TI remota para corrigir as configurações, com sucesso misto e grande frustração.

Relatórios e ferramentas

  • Relatórios agregados de DMARC (RUA) são vistos por alguns como barulhentos ou inúteis, especialmente quando todo o e-mail vem de um único servidor.
  • Outros usam ferramentas ou scripts personalizados para analisar relatórios e verificar se todos os serviços de envio estão configurados.
  • Vários comentaristas relatam usar LLMs ou ferramentas online para analisar a configuração de DNS/DMARC e até automatizar alterações.

Efetividade contra spam e abuso

  • Há forte discordância sobre o valor:
    • Pró: o DMARC “resolve” a identificação (quem realmente enviou isto), o que é pré-requisito para outras defesas; ele impede o spoofing direto de domínio.
    • Contra: a maior parte do spam e phishing hoje passa por SPF/DKIM/DMARC via grandes provedores ou SaaS; o DMARC faz pouco pela confiança do usuário, e o conteúdo ainda determina o filtro.
  • Alguns argumentam que o DMARC é ruído que bloqueia e-mails legítimos quando as pessoas configuram sistemas incorretamente ou rotacionam chaves de forma ruim.

Problemas mais amplos do ecossistema de e-mail

  • Reclamações de que grandes provedores ignoram denúncias de abuso, mas dominam o volume de spam e os sistemas de reputação.
  • Quem hospeda o próprio e-mail, especialmente remetentes de baixo volume, relata boa configuração, mas má entregabilidade por causa de reputação de IP e heurísticas de volume.
  • Alguns propõem e-mail comunitário/federado ou até um novo protocolo com criptografia e identidade integradas; outros veem isso como impraticável dado o uso atual.