Você implementou SPF. Você configurou DKIM. Seus emails estão autenticados e você se sente bem com sua postura de segurança. Então você descobre que alguém tem enviado milhares de emails de phishing do seu domínio há meses, e nada da sua autenticação importou porque você nunca disse a ninguém o que fazer diante das falhas.
Essa é a lacuna que o DMARC preenche. SPF e DKIM são mecanismos de verificação — eles podem dizer a um servidor de recebimento se um email é legítimo. Mas eles não especificam o que deve acontecer quando a verificação falha. O email deve ser entregue mesmo assim? Colocado em quarentena? Rejeitado de imediato? Sem instruções explícitas, a maioria dos servidores decide entregar o email, talvez com um aviso que os usuários ignoram.
DMARC—Domain-based Message Authentication, Reporting, and Conformance—é a camada de política. Ele diz ao mundo: 'Eis o que eu quero que você faça com emails que falham na autenticação. Ah, e me envie relatórios sobre o que você está vendo.'
As três políticas de DMARC
As políticas de DMARC são especificadas com a tag 'p=' no seu registro DMARC. Há três opções, e escolher a certa depende de onde você está na sua jornada de autenticação de email.
'p=none' é modo de monitoramento. Ele diz aos servidores de recebimento: 'Não faça nada especial com falhas, mas me envie relatórios sobre o que você vê.' É aqui que todos devem começar. Você ganha visibilidade sobre seu ecossistema de email sem correr o risco de bloquear emails legítimos.
'p=quarantine' é o meio-termo. Ele diz aos servidores: 'Se a autenticação falhar, trate o email como suspeito.' Na prática, isso normalmente significa que o email vai para as pastas de spam ou lixo. Os usuários ainda podem encontrá-lo se procurarem, mas ele não vai para a caixa de entrada.
'p=reject' é aplicação total. Ele diz aos servidores: 'Se a autenticação falhar, não entregue o email.' Esse é o objetivo — proteção completa contra spoofing de domínio. Mas também é o mais perigoso se sua autenticação não estiver corretamente configurada, porque emails legítimos serão bloqueados.
A trajetória de 'none' para 'reject' normalmente leva semanas ou meses. Você começa com monitoramento, analisa os relatórios para encontrar todas as fontes legítimas de email, garante que estão devidamente autenticadas e então aumenta a aplicação gradualmente. Correr para 'reject' antes de estar pronto é uma ótima maneira de quebrar seu email.
Entendendo o alinhamento do DMARC
Aqui é onde o DMARC fica sutil, e onde muita gente se confunde. DMARC não apenas verifica se SPF e DKIM passam — ele verifica se eles 'se alinham' com o endereço From visível.
Considere este cenário: Um atacante envia um email com um endereço From de [email protected]. Ele envia pelo próprio servidor, que tem SPF válido para attackerdomain.com. O email passa em SPF — mas para o domínio errado. Sem verificação de alinhamento, esse ataque seria bem-sucedido.
O alinhamento de DMARC exige que o domínio autenticado por SPF ou DKIM corresponda ao domínio no cabeçalho From. 'Corresponde' pode significar uma correspondência exata (alinhamento estrito) ou uma correspondência no nível do domínio organizacional (alinhamento relaxado).
Com alinhamento relaxado (o padrão), mail.yourcompany.com alinha com yourcompany.com. Com alinhamento estrito, não — apenas correspondências exatas contam. A maioria das organizações usa alinhamento relaxado porque é mais prático, especialmente se você usa subdomínios para diferentes fluxos de email.
Para que o DMARC passe, ou o SPF deve passar e alinhar, ou o DKIM deve passar e alinhar (ou ambos). É por isso que ter ambos SPF e DKIM configurados é importante — se um falhar (digamos, SPF falhar devido a encaminhamento), o outro ainda pode fornecer um resultado de aprovação.
Relatórios de DMARC: sua janela para o abuso de email
O recurso de relatórios do DMARC é, de forma discutível, tão valioso quanto a aplicação de política. Quando você publica um registro DMARC com a tag 'rua=', os servidores de recebimento lhe enviam relatórios agregados sobre os emails que viram alegando ser do seu domínio.
Esses relatórios são arquivos XML que chegam diariamente (geralmente). Eles contêm dados sobre volume de email, resultados de autenticação e fontes de envio. Para cada IP de origem, você verá quantos emails foram enviados, se SPF e DKIM passaram e qual política foi aplicada.
Na primeira vez que você olhar os relatórios de DMARC, provavelmente ficará surpreendido. Você verá emails vindo de fontes que você esqueceu — aquela ferramenta de marketing antiga que você parou de usar mas nunca descomissionou, o sistema de faturamento que envia recibos, o serviço de monitoramento que envia alertas. Você também provavelmente verá fontes não autorizadas: spammers, phishers, ou apenas sistemas mal configurados que de alguma forma acabaram enviando como seu domínio.
Relatórios DMARC em bruto são difíceis de ler. A maioria das organizações usa um serviço de análise de DMARC (há opções gratuitas e pagas) que agrega relatórios, visualiza os dados e alerta você sobre problemas. Isso é altamente recomendado — tentar analisar relatórios XML manualmente não escala.
Há também 'ruf=' para relatórios forenses, que enviam informações detalhadas sobre emails individuais que falharam. Eles são mais sensíveis em termos de privacidade (podem incluir conteúdo de email) e muitos recebedores não os enviam, mas podem ser úteis para investigar incidentes específicos.
O caminho para a aplicação
Mover de p=none para p=reject é um processo, não um evento. Veja como normalmente funciona na prática.
Você começa publicando um registro DMARC com p=none e um endereço rua para relatórios. Você não precisa de SPF e DKIM perfeitos neste ponto — você está apenas coletando dados. Espere pelo menos duas semanas, de preferência um mês, para reunir relatórios suficientes e ver o quadro completo.
Analise os relatórios. Identifique todas as fontes legítimas de email do seu domínio. Para cada uma, verifique se SPF e DKIM estão devidamente configurados. É aqui que geralmente você descobre serviços esquecidos ou más configurações. Corrija-os.
Quando suas fontes legítimas estiverem passando autenticação de forma consistente, mova para p=quarantine. Mas não vá com tudo de imediato — use a tag 'pct=' para aplicar a política apenas a um percentual dos emails com falha. Comece com pct=10, significando que 10% das falhas são colocadas em quarentena enquanto 90% ainda são entregues normalmente.
Monitore os relatórios. Se você vir email legítimo sendo colocado em quarentena, investigue e corrija. Se tudo parecer bom, aumente gradualmente a porcentagem: 25%, 50%, 75%, 100%.
Quando você estiver em p=quarantine com pct=100 e tudo estiver estável, repita o processo para p=reject. Novamente, comece com uma porcentagem baixa e aumente gradualmente. Quando você chegar a p=reject com pct=100 (ou sem a tag pct, que tem padrão de 100%), você terá aplicação total de DMARC.
Esse processo normalmente leva de 2 a 6 meses, dependendo da complexidade do seu ecossistema de email. Apressar-se arrisca bloquear email legítimo. Ir devagar demais deixa você vulnerável a spoofing. Encontre o ritmo certo para sua organização.
Erros comuns de DMARC
O erro mais comum é pular direto para p=reject sem monitorar antes. Você vai quebrar alguma coisa. Talvez seja o sistema de RH que envia cartas de oferta, a ferramenta de finanças que envia faturas, ou a aplicação legada que ninguém lembra que existe. Comece com p=none, sempre.
Outro erro frequente é configurar DMARC mas nunca olhar os relatórios. Os relatórios são todo o propósito da fase de monitoramento. Se você não os analisa, está voando às cegas. Configure uma ferramenta de análise de DMARC e realmente revise os dados.
Esquecer dos subdomínios pega muitas organizações. Por padrão, a política de DMARC se aplica apenas ao domínio exato, não aos subdomínios. Se você quer proteger marketing.yourcompany.com, você precisa de um registro DMARC separado para esse subdomínio ou de uma tag 'sp=' no seu registro principal especificando a política de subdomínio.
A má configuração de serviços de terceiros é endêmica. Quando você adiciona um novo serviço de email, você precisa atualizar o SPF (para autorizar seus servidores) e garantir que ele está assinando com DKIM no seu domínio (não no domínio padrão deles). Muitos serviços exigem configuração explícita para usar o DKIM do seu domínio.
Por fim, tratar DMARC como 'configurar e esquecer' leva a problemas. Seu ecossistema de email muda ao longo do tempo. Novos serviços são adicionados, antigos são removidos, configurações derivam. Revise seus relatórios de DMARC regularmente, mesmo após atingir aplicação total.
Frequently asked questions
Posso usar DMARC sem SPF ou DKIM?
Tecnicamente, sim, mas é inútil. A política do DMARC é baseada nos resultados de SPF e DKIM. Sem pelo menos um deles configurado, todo email vai falhar em DMARC. Você precisa de SPF, DKIM ou ambos para que DMARC tenha significado.
Qual é a diferença entre os relatórios rua e ruf?
Relatórios rua (agregados) são resumos diários dos resultados de autenticação—volumes e taxas de aprovação/falha por fonte. Relatórios ruf (forenses) são informações detalhadas sobre emails individuais que falharam. A maioria das organizações usa apenas rua; relatórios ruf são menos comumente enviados e levantam preocupações de privacidade.
Por quanto tempo devo ficar em p=none antes de mover para quarantine?
Pelo menos 2-4 semanas, mais se você tiver um ecossistema de email complexo. Você precisa de dados suficientes para identificar todas as fontes legítimas de email e verificar que estão devidamente autenticadas. Apressar essa fase é a causa mais comum de problemas de email relacionados a DMARC.
DMARC vai parar todo phishing?
Não. DMARC previne spoofing de domínio exato (alguém enviando como @yourcompany.com), mas não impede domínios parecidos (yourcompany-secure.com) ou spoofing de nome de exibição ('Your Company `<[email protected]>`'). É uma camada importante, mas não uma solução anti-phishing completa.