O protocolo SMTP foi criado nos anos 80 sem nenhum mecanismo de autenticação. Sem três registros DNS configurados, qualquer servidor no mundo pode enviar e-mail fingindo ser o seu domínio: e o destinatário não tem como diferenciar.
O SMTP foi projetado para confiança, não para segurança. Qualquer servidor de e-mail pode declarar que está enviando em nome de qualquer domínio, e o protocolo aceita essa declaração sem questionar. Os campos visíveis ao destinatário (From, Reply-To, Subject) são separados do envelope técnico de envio, e atacantes manipulam os dois de forma independente.
O resultado: um e-mail que aparece com remetente ceo@suaempresa.com.br pode ter sido enviado de um servidor em outro país, sem que nenhuma vulnerabilidade de software tenha sido explorada: apenas ausência de configuração de DNS.
Em 2023, o FBI registrou mais de US$ 2,9 bilhões em perdas confirmadas por Business Email Compromise (BEC) só nos EUA: ataques que dependem principalmente de spoofing de domínio corporativo.
Lista os IPs autorizados a enviar e-mail em nome do domínio via registro TXT no DNS.
Cada mensagem recebe uma assinatura digital verificável. Garante integridade e origem.
Define o que acontece quando SPF/DKIM falham e exige alinhamento com o From visível.
SPF, DKIM e DMARC protegem contra tipos diferentes de ataque. Entender a distinção define o que cada configuração realmente bloqueia:
Usa domínio diferente mas coloca o nome de um executivo no campo exibido. Não é bloqueado por SPF/DMARC: o domínio real passa.
Usa exatamente o domínio da empresa no campo From. Parece idêntico ao legítimo. É contra esse tipo que SPF/DKIM/DMARC atuam diretamente.
Registra domínio visualmente parecido (caractere Unicode, letra duplicada). SPF/DMARC no seu domínio não ajudam aqui: o domínio falso é "legítimo".
O SPF (Sender Policy Framework) publica no DNS uma lista de IPs autorizados a enviar e-mail em nome do domínio. Quando um servidor recebe uma mensagem de @suaempresa.com.br, ele consulta o registro TXT do domínio e verifica se o IP de origem está na lista.
O sufixo final define o que acontece com e-mails de IPs não autorizados:
Limitação crítica: o SPF verifica o endereço técnico do envelope (Mail From), não o campo From visível ao usuário. Um atacante pode passar no SPF usando seu domínio no envelope enquanto exibe o domínio da vítima no campo visível. Por isso SPF sozinho não basta para prevenir exact domain spoofing.
O DKIM adiciona uma assinatura criptográfica a cada mensagem. O servidor de envio usa a chave privada para assinar; o servidor receptor busca a chave pública no DNS e verifica. Se a mensagem foi alterada em trânsito, mesmo um único caractere, a verificação falha.
O prefixo google é o seletor: identifica qual par de chaves usar. Uma empresa pode ter múltiplos seletores ativos (um por provedor de e-mail, um para rotação de chaves). Seletores comuns: google, mail, default, k1, s1.
Limitação: o DKIM não impede alguém de enviar mensagem não assinada do seu domínio. A ausência de assinatura precisa ser tratada como falha, e isso é definido pelo DMARC.
O DMARC exige alinhamento: o domínio no campo From visível ao usuário deve coincidir com o domínio que passou no SPF ou que assinou o DKIM. Isso fecha a brecha de "passar no SPF com envelope diferente". E define o que o servidor receptor deve fazer quando a verificação falha.
Os três valores de política (p=):
O campo sp= define a política para subdomínios que não têm DMARC próprio. Sem ele, um atacante pode enviar e-mail falso como @newsletter.suaempresa.com.br ou @marketing.suaempresa.com.br (subdomínios herdados) sem restrição.
O campo rua= configura um endereço que recebe relatórios XML diários de todos os servidores do mundo que tentaram entregar e-mail do seu domínio. Esses relatórios revelam:
A configuração mais comum em auditorias: SPF existe (porque o Google Workspace pediu no setup), DMARC ausente ou em p=none. O resultado: spoofing exato do domínio continua possível e ninguém está monitorando.
Fase 1: atacante envia e-mail falsificado do "CEO" para o RH pedindo lista de funcionários e dados fiscais. Confiança estabelecida por e-mail com domínio legítimo. Fase 2: pedido de transferência bancária urgente "para fechar negociação confidencial antes do fechamento do mês". Sem DMARC em reject, nenhuma camada técnica bloqueou o e-mail de fase 1: a engenharia social fez o resto.
Em qualquer cliente de e-mail é possível ver os cabeçalhos completos de uma mensagem. Dois campos revelam se a autenticação passou:
Se _dmarc retornar vazio, ou retornar p=none, o domínio está vulnerável a spoofing exato. A análise do WS Vicentin verifica SPF, DKIM (por força bruta de seletores comuns) e DMARC, retornando um score de proteção com diagnóstico detalhado.
1. Configure SPF com todos os remetentes legítimos mapeados. 2. Ative DKIM no seu provedor. 3. Implante DMARC com p=none e analise relatórios rua= por 2–4 semanas. 4. Avance para p=quarantine. 5. Após confirmar que nenhum remetente legítimo falha, avance para p=reject.
