Você investe pesado em firewall, atualiza sistemas e treina sua equipe contra engenharia social, mas um único clique errante pode derrubar meses de trabalho. A maioria dos ataques de phishing não quebra criptografia; ela se aproveita da confiança humana e da falta de verificação técnica no nível do protocolo. Se o seu email corporativo parece legítimo para o Gmail, mas não passa nos filtros de segurança mais rigorosos, você já perdeu a batalha pela reputação da sua marca.
A segurança de email deixou de ser apenas uma questão de senha forte. Hoje, é um problema de infraestrutura de confiança. Os provedores de email (Gmail, Outlook, Yahoo) exigem validação rigorosa para impedir que domínios legítimos sejam usados em campanhas de spam e fraude. Sem essa camada técnica, suas mensagens corporativas caem no spam ou são rejeitadas, afetando diretamente sua comunicação com clientes e parceiros.
Neste guia técnico, vamos destrinchar como configurar SPF, DKIM e DMARC para blindar seu domínio contra sequestro de identidade via email. Não se trata apenas de seguir boas práticas; é uma necessidade operacional para manter a entregabilidade e a integridade da sua infraestrutura de TI.
Por que falhas no DNS expõem seu email
O Domain Name System (DNS) é o sistema telefônico da internet. Ele traduz nomes legíveis em endereços IP, mas também carrega registros que definem como um domínio se comporta. Quando você configura um email, está essencialmente dizendo ao mundo: "Eu permito que este servidor envie mensagens em meu nome".
O problema surge quando essa permissão é ambígua ou inexistente. Se não há registros específicos validando a origem do email, qualquer pessoa com acesso a uma ferramenta de envio pode falsificar o cabeçalho From: e enviar mensagens parecendo vir de voc@suempresa.com.br. Isso é a base do spoofing.
Os ataques de phishing evoluíram. Em vez de apenas enganar o usuário, os atacantes hoje exploram brechas na validação inicial. Se seu domínio não possui políticas claras de quem pode enviar email, os provedores de destino tratam suas mensagens como suspeitas por padrão. Isso resulta em:
- Queda de entregabilidade: Seus emails transacionais e comerciais vão para a caixa de spam.
- Roubo de marca: Golpistas usam seu domínio para enganar seus clientes, prejudicando sua reputação.
- Perda de confiança: Parceiros de negócio podem bloquear seu domínio se ele for associado a campanhas maliciosas.
A solução não é bloquear tudo, mas fornecer evidências criptográficas e políticas claras. É aqui que entram os três pilares da segurança de email moderna: SPF, DKIM e DMARC.
SPF: A lista de endereços IP autorizados
O Sender Policy Framework (SPF) foi o primeiro protocolo a ser implementado amplamente. Ele funciona como uma lista branca de endereços IP. Você publica um registro TXT no DNS do seu domínio que declara quais servidores são autorizados a enviar emails em seu nome.
Quando um servidor receptor recebe um email, ele verifica o endereço IP de origem contra o registro SPF do domínio remetente. Se o IP estiver na lista, o email passa. Se não estiver, ele falha.
Como funciona na prática
Um registro SPF típico se parece com isto:
v=spf1 mx ip4:200.100.50.25 include:_spf.google.com ~all
Vamos dissecar essa linha técnica:
- v=spf1: Indica a versão do protocolo.
- mx: Permite que os servidores MX (Mail Exchange) definidos no DNS enviem email. Útil para domínios simples, mas limitado.
- ip4:... Autoriza um endereço IPv4 específico ou uma faixa de rede.
- include:_spf.google.com: Uma diretiva crucial. Ela delega a verificação para o Google, dizendo "confie em todos os IPs que o Google disser que são oficiais". Isso é vital se você usa Gmail para Business ou Microsoft 365.
- ~all: A política de "Soft Fail". Emails vindos de IPs não autorizados são marcados como suspeitos, mas aceitos. Para produção segura, recomenda-se migrar para
-all(Hard Fail), que rejeita explicitamente.
O erro mais comum das empresas é esquecer de incluir os serviços de terceiros. Se você usa uma ferramenta de marketing por email ou um sistema de CRM que envia notificações em seu nome, e não adicionar o include correspondente ao seu SPF, esses emails serão rejeitados como phishing.
DKIM: A assinatura criptográfica do conteúdo
Enquanto o SPF verifica a origem (o servidor), o DomainKeys Identified Mail (DKIM) verifica a integridade do conteúdo. Ele adiciona uma assinatura digital criptográfica ao cabeçalho do email.
Ao enviar o email, seu servidor de mail usa uma chave privada para gerar um hash do conteúdo e o anexa ao cabeçalho. O servidor receptor busca a chave pública correspondente no DNS do seu domínio para validar que a assinatura é legítima e, crucialmente, que o email não foi alterado em trânsito.
A diferença crítica entre SPF e DKIM
Muitos administradores confundem as duas funções. Pense da seguinte forma:
- SPF prova que você é o dono do servidor que enviou a mensagem.
- DKIM prova que a mensagem foi enviada por você e não foi modificada depois.
Se um atacante interceptar seu email e mudar apenas uma vírgula no corpo da mensagem para alterar o link de um boleto, o DKIM falhará. O SPF ainda passará (pois veio do mesmo servidor), mas a falta da assinatura válida sinalizará violação de integridade.
A configuração do DKIM exige que você gere um par de chaves (pública e privada). A chave pública é publicada no DNS, e a privada fica configurada no seu servidor de email ou na plataforma do provedor de serviços (como AWS SES, SendGrid ou Microsoft 365). Sem essa assinatura, seus emails corporativos perdem uma camada vital de autenticidade que os algoritmos de spam modernos priorizam.
DMARC: Governança e reporte de violações
O Domain-based Message Authentication, Reporting & Conformance (DMARC) é a cola que une SPF e DKIM. Ele não valida emails diretamente; ele diz ao servidor receptor o que fazer quando uma falha de validação ocorre e solicita relatórios sobre como seu domínio está sendo usado.
Antes do DMARC, se um email falhava no SPF ou DKIM, cada provedor tomava uma decisão arbitrária. Alguns bloqueavam, outros marcavam como spam, outros entregavam. O DMARC padroniza essa resposta através de políticas definidas pelo dono do domínio.
Políticas de Ação
Você define sua política no registro DNS usando a tag p=:
- none: Apenas monitore. Se falhar, o email é entregue, mas você recebe um relatório.
- quarantine: O receptor deve tratar o email como spam (geralmente movendo para a pasta de lixo eletrônico).
- reject: O receptor rejeita o email completamente, nunca chegando à caixa de entrada do destinatário.
A recomendação de segurança é começar com p=none por 30 dias para analisar os relatórios e garantir que nenhum email legítimo está sendo bloqueado acidentalmente. Após validar a cobertura, migre para quarantine e, finalmente, para reject.
O aspecto mais poderoso do DMARC são os relatórios de agregação (RUA) e instantâneos (RUF). Você recebe emails diários detalhando:
- Quantos emails foram enviados em seu nome.
- Quais IPs enviaram esses emails.
- Se passaram ou falharam nas verificações SPF e DKIM.
Isso permite detectar se um atacante está tentando usar seu domínio para phishing, mesmo que você não tenha recebido o email. Você vê a tentativa de spoofing nos logs antes que ela cause dano.
Implementação gradual e monitoramento
Configurar esses registros parece simples, mas os trade-offs são reais. Uma configuração errada pode paralisar sua comunicação empresarial. O erro clássico é ativar o DMARC em modo reject antes de ter cobertura total de SPF e DKIM.
Se você tiver um email interno que não passa por um servidor de saída validado, ou se usar um sistema legado que não suporta DKIM, esse email será bloqueado. A estratégia correta segue este fluxo:
- Fase 1: Auditoria. Identifique todos os sistemas que enviam email em nome do domínio (CRM, ERP, marketing, desenvolvimento).
- Fase 2: SPF Limpo. Crie um registro SPF que inclua apenas os IPs e
includesconhecidos. Remova duplicatas e exceda o limite de 10 mecanismos DNS. - Fase 3: Ativação do DKIM. Configure a assinatura em todos os pontos de saída. Verifique se a chave está publicada corretamente no DNS.
- Fase 4: DMARC Monitoramento. Publique o registro DMARC com
p=none. Aguarde a geração dos primeiros relatórios. - Fase 5: Refinamento. Analise os relatórios. Se houver falhas legítimas, ajuste o SPF/DKIM. Se não houver falhas indesejadas, mude para
p=quarantine. - Fase 6: Hardening. Mude para
p=reject. Seu domínio agora está blindado contra spoofing.
É importante notar que a validação de domínio não impede o usuário de clicar em links maliciosos. Ela impede que o atacante
Perguntas frequentes sobre validação de domínio
1. Preciso configurar SPF, DKIM e DMARC se uso apenas Gmail ou Outlook?
Sim, absolutamente. Mesmo quando você usa o painel web do Gmail ou Outlook para ler emails, os servidores deles enviam as mensagens em nome do seu domínio corporativo. Se não houver registros DNS validando isso, o Gmail pode marcar seus próprios envios como spam para outros usuários ou bloquear o envio. A responsabilidade da configuração recai sobre o administrador do domínio, não apenas sobre a plataforma de email.
2. O que acontece se eu ultrapassar o limite de 10 mecanismos no SPF?
O protocolo SPF define um limite rígido de dez verificações (includes, mx, ip4, etc.). Se você exceder esse limite, a verificação retorna um erro "Softfail" para todos os emails subsequentes, independentemente de serem legítimos ou não. Isso quebra a entregabilidade. A solução é usar o mecanismo redirect ou refatorar sua lista para agrupar faixas de IP ou consolidar includes.
3. Posso usar apenas DMARC sem SPF e DKIM?
Não. O DMARC depende das verificações de SPF e/ou DKIM para tomar decisões. Se nenhum dos dois passar, o DMARC não tem base para aplicar a política (none, quarantine ou reject). Você precisa ter pelo menos um dos mecanismos operando corretamente para que o DMARC seja eficaz.
4. Como vejo se meu registro DMARC está funcionando?
Após publicar o registro, você deve receber relatórios de agregação no endereço de email especificado na tag rua=. Esses relatórios são em formato XML e podem ser difíceis de ler manualmente. Ferramentas de visualização de DMARC ou painéis de segurança de email podem processar esses XMLs e apresentar gráficos simples de "passou/falhou".
5. O DMARC protege contra ataques de spear phishing?
O DMARC protege contra o spoofing do seu domínio (falsificar que a mensagem veio de voc@empresa.com). Ele não protege contra um atacante que cria um domínio novo e similar (empresalogo.com). No entanto, ao implementar DMARC rigoroso, você sinaliza aos provedores de email que leva a segurança a sério, o que melhora a reputação geral do seu domínio legítimo, dificultando a vida dos golpistas.
Conclusão: Segurança ativa vs. reativa
A prevenção de phishing via validação de domínio não é um luxo para grandes corporações; é uma necessidade básica para qualquer empresa que leve sua reputação digital a sério. Configurar SPF, DKIM e DMARC transforma seu email de um canal aberto para ataques em um sistema autenticado e verificável.
A diferença entre um email entregue na caixa de entrada e um bloqueado como spam muitas vezes reside apenas nessas três linhas de código no seu DNS. Ignorá-las é abrir porta para que atacantes sequestrem sua identidade digital, comprometendo a confiança de seus clientes e a segurança de sua infraestrutura.
A implementação requer cuidado técnico inicial, mas o retorno em estabilidade e proteção é imediato. Ao monitorar os relatórios e ajustar suas políticas gradualmente, você cria uma barreira automática contra fraudes que funciona 24 horas por dia, sem depender da atenção humana do seu usuário final.
Se sua infraestrutura atual não contempla essa camada de validação ou se você enfrenta problemas recorrentes de entregabilidade, revisar seus registros DNS é o primeiro passo técnico mais impactante que sua equipe de TI pode tomar. A segurança começa na origem, e no caso do email corporativo, a origem é definida pelo DNS.