Autenticação de e-mail explicada: SPF, DKIM e DMARC para defensores

O e-mail continua sendo o veículo de entrega número um para phishing, comprometimento de e-mail corporativo e malware, e quase tudo depende de uma única fraqueza: o endereço From: que o destinatário vê é trivial de forjar a menos que você publique os registros de autenticação corretos. Este artigo é para o blue team. Ele explica SPF, DKIM e DMARC sob um ângulo puramente defensivo: o que cada controle prova, como os três se entrelaçam, como ler a telemetria que produzem e como levar seu domínio a uma política de aplicação sem quebrar o correio legítimo.

Por que a falsificação de e-mail é tão fácil por padrão#

O SMTP foi projetado numa era de confiança mútua e não tem verificação de identidade embutida. Cada mensagem tem duas identidades de remetente: o remetente de envelope (o MAIL FROM usado na transação SMTP, também chamado de Return-Path) e o From de cabeçalho que os clientes de e-mail realmente exibem. Um atacante pode definir ambos como quiser. Sem registros de autenticação, um servidor receptor não tem base criptográfica nem de política para rejeitar uma mensagem que afirma vir do seu domínio. Os três padrões abaixo adicionam essa base, cada um cobrindo uma lacuna diferente.

SPF: autorizar a infraestrutura de envio#

Sender Policy Framework (SPF) é um registro TXT de DNS que lista quais endereços IP e hosts podem enviar e-mail usando seu domínio no remetente de envelope. Um receptor consulta v=spf1 ... para o domínio de envelope e verifica se o IP conectante está autorizado. O registro termina com um mecanismo all: -all significa falha rígida (rejeitar o não listado), ~all falha branda (aceitar mas marcar) e +all é perigoso e nunca deve ser usado. O SPF tem dois limites importantes: valida o remetente de envelope, não o From visível, e quebra no encaminhamento porque o encaminhador vira o novo IP conectante. Também tem um teto de dez consultas DNS, então cadeias include: exageradas podem levar um registro a permerror silenciosamente.

DKIM: assinar a mensagem criptograficamente#

DomainKeys Identified Mail (DKIM) anexa uma assinatura digital às mensagens de saída. Sua plataforma de e-mail assina cabeçalhos selecionados e o corpo com uma chave privada; a chave pública correspondente é publicada no DNS em seletor._domainkey.seudominio. Um receptor recalcula o hash e verifica a assinatura, provando que o conteúdo assinado não foi alterado em trânsito e que foi assinado por uma chave que seu domínio controla. Como a assinatura viaja dentro da mensagem, o DKIM sobrevive à maioria dos encaminhamentos, diferente do SPF. Rotacione seletores periodicamente, use chaves de pelo menos 2048 bits e aposente seletores antigos para que uma chave histórica vazada não possa ser abusada.

DMARC: alinhamento, política e relatórios#

O DMARC amarra SPF e DKIM ao From de cabeçalho que os usuários realmente veem, por um conceito chamado alinhamento. Uma mensagem passa no DMARC se passa no SPF e o domínio SPF se alinha ao From, ou se passa no DKIM e o domínio DKIM se alinha: apenas um é necessário. A política DMARC é um registro TXT de DNS em _dmarc.seudominio com política p=none (só monitorar), p=quarantine (enviar ao spam) ou p=reject (recusar). É crucial que o DMARC também solicita relatórios: agregados XML via rua= e, onde oferecido, amostras forenses via ruf=. Esses relatórios são sua telemetria primária de detecção.

A superfície de ataque que estes controles endereçam#

Entender contra o que você se defende ajuda a ajustar a política. O spoofing de domínio exato forja seu próprio domínio no From e é exatamente o que o DMARC em aplicação impede. Domínios primos ou parecidos (registrar um nome visualmente similar) não são cobertos pelo seu registro DMARC e exigem monitoramento de marca e conscientização. A imitação de nome de exibição mantém um endereço legítimo no envelope mas define um nome enganoso, algo que a autenticação não pega e que precisa de avisos no cliente. Conhecer esses limites evita uma falsa sensação de segurança quando o DMARC está em reject.

Detecção: ler os relatórios agregados do DMARC#

Relatórios agregados (RUA) chegam diariamente como XML de cada receptor, resumindo contagens de mensagens agrupadas por IP de origem, resultado SPF, resultado DKIM e disposição DMARC. Alimente-os num parser ou painel hospedado em vez de ler XML cru. Fique atento a três sinais: IPs de envio desconhecidos passando ou falhando pelo seu domínio (uma ferramenta de marketing que ninguém avisou, ou um atacante), fontes legítimas falhando o alinhamento (um serviço que assina com o domínio errado) e picos de volume para reject, que podem indicar uma campanha de spoofing ativa. No seu gateway e SIEM, indexe o cabeçalho Authentication-Results para consultar dmarc=fail, dkim=fail e spf=softfail e alertar sobre imitação dos seus executivos.

Detecção: sinais de cabeçalho e de logs#

Além dos relatórios DMARC, defensores devem estabelecer uma linha de base dos resultados normais de autenticação. No Microsoft 365, o rastreamento de mensagens e o valor compauth expõem decisões de autenticação composta; no Google Workspace, os logs de e-mail no BigQuery e a Ferramenta de Investigação de Segurança mostram os veredictos SPF/DKIM/DMARC. Crie detecções para e-mail de entrada que falha o DMARC mas afirma vir de um domínio interno ou parceiro, para o surgimento súbito de um novo seletor no seu próprio DNS que você não criou, e para e-mail de saída do seu domínio reportado como falho por receptores externos: o último costuma ser o primeiro sinal de que um sistema de shadow IT ou uma conta comprometida está enviando em seu nome.

Mitigação e hardening: implantar até a aplicação#

Implante em etapas para não descartar correio real. Primeiro, inventarie cada remetente legítimo: sua plataforma de e-mail, ferramentas de marketing, sistemas de tickets, CRM e folha de pagamento. Publique um registro SPF preciso terminando em -all, mantendo-se abaixo do limite de dez consultas achatando ou removendo includes não usados. Habilite assinatura DKIM em cada fonte com chaves de 2048 bits e seletores únicos. Depois publique p=none com rua= e colete relatórios por algumas semanas até que cada fluxo legítimo mostre alinhamento aprovado. Passe para p=quarantine com um pct baixo e suba até 100, e finalmente para p=reject. Defina sp=reject para subdomínios e considere publicar um MX nulo e DMARC reject em domínios que não enviam para que não possam ser abusados.

Controles complementares: MTA-STS, TLS-RPT e BIMI#

A autenticação responde quem enviou isto; a segurança de transporte responde foi entregue de forma privada. O MTA-STS permite que seu domínio exija TLS para o SMTP de entrada e resista a ataques de downgrade, e o TLS-RPT reporta falhas de entrega. O BIMI permite exibir um logotipo de marca verificado, mas só depois que você está em aplicação DMARC, o que o torna um incentivo útil para concluir a implantação. Nenhum substitui o DMARC; eles endurecem as camadas ao redor. Trate-os como a segunda onda depois que sua política de aplicação estiver estável.

Armadilhas comuns#

As falhas mais frequentes são autoinfligidas. Publicar dois registros SPF causa um permerror e invalida o SPF por completo: você só pode ter um. Exceder as dez consultas DNS quebra o SPF silenciosamente para ecossistemas grandes. Pular direto para p=reject sem período de monitoramento descarta de forma confiável o correio legítimo de um remetente esquecido. Esquecer a política de subdomínio deixa marketing.seudominio passível de spoofing mesmo com o domínio pai bloqueado. E tratar ~all como equivalente à aplicação é um erro: falha branda mais p=none não impede nada. Por fim, nunca conte com relatórios forenses ruf disponíveis: muitos receptores não os enviam mais por privacidade, então construa sua detecção sobre dados agregados.

Checklist de hardening#

Use isto como auditoria rápida. 1. Exatamente um registro SPF por domínio, terminando em -all, abaixo de dez consultas. 2. DKIM habilitado em cada fonte de envio, chaves de 2048 bits, seletores rotacionados e antigos aposentados. 3. DMARC em p=reject com sp=reject e rua fluindo para uma caixa ou plataforma monitorada. 4. Domínios estacionados e sem envio bloqueados com SPF -all e DMARC reject. 5. Gateway de entrada indexa Authentication-Results e alerta sobre imitação de executivos e falhas DMARC de domínio interno. 6. MTA-STS em modo enforce e TLS-RPT publicados. 7. Monitoramento de domínios parecidos à marca e treinamento de usuários para ataques de nome de exibição e semelhança que a autenticação não consegue impedir.

FAQ: o DMARC em reject impede todo o phishing?#

Não, e acreditar nisso é perigoso. O DMARC em reject impede que atacantes forjem o seu domínio exato no From de cabeçalho, o que é uma vitória grande e valiosa porque protege sua marca e seus próprios usuários de spoofs com aparência interna. Ele não faz nada contra domínios parecidos, truques de nome de exibição, contas legítimas comprometidas ou phishing a partir de domínios alheios. Combine a aplicação com filtragem de entrada, proteção de links, reporte de usuários e conscientização para que as técnicas restantes continuem sendo detectadas.

FAQ: a aplicação vai quebrar encaminhamento e listas de discussão?#

Pode quebrar, e é por isso que o DKIM importa. O SPF quebra no encaminhamento simples porque o encaminhador é um novo IP de origem, mas uma assinatura DKIM válida geralmente sobrevive, então um DKIM alinhado mantém a mensagem conforme ao DMARC. Listas que modificam o assunto ou o corpo podem quebrar o DKIM; listas bem configuradas mitigam isso com ARC (Authenticated Received Chain), que permite a um intermediário confiável atestar a autenticação original. Monitore seus relatórios agregados em busca de falhas relacionadas a encaminhamento durante a implantação para colocar em lista branca os intermediários bons conhecidos antes de chegar ao reject.

Conclusão#

SPF, DKIM e DMARC não são três opções concorrentes; são três camadas que só entregam proteção quando combinadas e levadas à aplicação. O SPF autoriza infraestrutura, o DKIM prova integridade e o DMARC amarra ambos ao From visível e lhe dá o relatório que transforma a autenticação de e-mail numa capacidade de detecção. O manual defensivo é direto: inventarie seus remetentes, publique registros precisos, monitore relatórios agregados até que cada fluxo legítimo se alinhe, e então suba para reject com cobertura de subdomínios. Faça isso, adicione MTA-STS e monitoramento por cima, e você fecha a porta mais fácil que os atacantes usam para se passar pela sua organização.