Em resumo
- SPF, DKIM e DMARC são três registros no DNS do domínio que provam que um e-mail veio de quem diz ter enviado; sem eles, qualquer pessoa pode se passar pela sua empresa.
- O DMARC é o que une os outros dois, define o que fazer com e-mails falsos (monitorar, quarentena ou rejeitar) e envia relatórios de abuso do domínio.
- Google e Microsoft já exigem autenticação de quem envia grandes volumes (5.000 mensagens por dia ou mais), e mensagens fora do padrão vão para o spam ou são recusadas.
- Dá para checar a situação do seu domínio em poucos minutos, consultando o DNS e o cabeçalho de um e-mail de teste.
A segurança de e-mail corporativo depende de três registros no DNS do seu domínio: SPF, DKIM e DMARC. Juntos, eles provam que uma mensagem realmente saiu da sua empresa e dizem ao servidor do destinatário o que fazer quando ela é falsa. Sem eles, alguém pode enviar um e-mail com o endereço diretoria@suaempresa.com.br, e o seu cliente ou o seu financeiro não tem como perceber a diferença.
Isso alimenta golpes como a fraude do falso CEO (BEC, do inglês business email compromise): um e-mail que parece vir da diretoria ou de um fornecedor pede uma transferência urgente. O mesmo problema também age no sentido contrário, já que e-mails legítimos da sua empresa podem cair no spam por falta de autenticação.
Qual o tamanho do problema?
O e-mail continua sendo a porta de entrada preferida dos golpistas, e o risco é concreto, inclusive no Brasil.
- 68% das organizações brasileiras pesquisadas relataram ataques de BEC em 2023, segundo o relatório State of the Phish 2024, da Proofpoint (fonte).
- O FBI registrou 24.768 queixas de BEC em 2025, com perdas declaradas de cerca de US$ 3,05 bilhões, o segundo maior valor entre todos os tipos de crime cibernético no relatório do IC3 (FBI IC3, relatório de 2025). Esses são só os casos reportados nos Estados Unidos.
O que são SPF, DKIM e DMARC?
Cada um cobre uma parte do problema. Os três precisam funcionar juntos.
SPF (Sender Policy Framework)
O SPF é um registro DNS do tipo TXT que lista quais servidores podem enviar e-mails em nome do seu domínio. Quando um e-mail chega ao destinatário, o servidor confere se o IP de origem está nessa lista. É como a portaria de um prédio: quem não está na lista não entra.
O SPF tem limites. Ele verifica o domínio técnico do envelope da mensagem (o endereço de retorno) e não o endereço que a pessoa vê no campo "De". Também não garante que o conteúdo não foi alterado e costuma falhar quando o e-mail é encaminhado automaticamente.
DKIM (DomainKeys Identified Mail)
O DKIM adiciona uma assinatura digital ao cabeçalho de cada mensagem. A chave privada fica no servidor de envio, e a chave pública é publicada no DNS do domínio, para que o servidor receptor valide a assinatura. Funciona como um lacre de correspondência: se estiver intacto, ninguém mexeu no conteúdo no caminho.
O DKIM resiste melhor ao encaminhamento do que o SPF. Mas, sozinho, ele também não diz o que fazer quando a validação falha, e o domínio que assina a mensagem nem sempre é o mesmo que aparece no "De".
DMARC (Domain-based Message Authentication, Reporting and Conformance)
O DMARC é a política que amarra SPF e DKIM. O dono do domínio publica no DNS uma instrução para os servidores receptores: se uma mensagem enviada em meu nome falhar nas verificações, entregue assim mesmo, mande para a quarentena (spam) ou rejeite.
O DMARC também exige alinhamento: o domínio que aparece no "De" precisa coincidir com o domínio validado pelo SPF ou pelo DKIM. Com isso, o golpista não consegue autenticar um domínio qualquer e exibir o seu. Por fim, o registro pode indicar um endereço para receber relatórios sobre quem está enviando e-mails em nome do seu domínio.
Resumo dos três protocolos
| Protocolo | Função principal | O que ganha quem implementa | Risco de não ter |
|---|---|---|---|
| SPF | Lista os servidores autorizados a enviar e-mail pelo domínio | Dificulta o uso de servidores não autorizados e melhora a entrega | Domínio fácil de falsificar; e-mails legítimos de servidores não listados podem ir para o spam |
| DKIM | Assina cada e-mail com uma chave ligada ao domínio | Prova que a mensagem não foi alterada e confirma a origem | Sem prova criptográfica de autoria; menor reputação nos filtros anti-spam |
| DMARC | Define a ação para e-mails que falham e exige alinhamento do domínio; gera relatórios | Bloqueia e-mails falsos antes de chegarem ao destinatário e dá visibilidade do abuso | Golpistas se passam pela sua marca sem que você saiba |
Por que a autenticação de e-mail é essencial?
Configurar os três protocolos traz dois ganhos: segurança contra fraude e phishing e melhor entrega dos e-mails legítimos.
Proteção contra fraude. Sem autenticação, um criminoso pode enviar mensagens com o seu domínio para clientes, fornecedores e funcionários, sem ser barrado. Com o DMARC em modo rigoroso, a maioria desses e-mails falsos nem chega à caixa de entrada.
Reputação e marca. Provedores como Gmail e Outlook consideram a autenticação ao decidir o que entregar. Se o seu domínio é usado em ataques, ele pode entrar em listas de bloqueio, e aí até os e-mails legítimos passam a ser recusados. Recuperar a reputação dá trabalho.
Entrega. E-mails autenticados passam melhor pelos filtros. Quem configura bem costuma ouvir menos o clássico "não recebi a sua proposta".
O que Google e Microsoft exigem hoje
A autenticação deixou de ser só boa prática e virou requisito de entrega para quem envia volume.
- Google (Gmail): desde 1º de fevereiro de 2024, todo remetente precisa de SPF ou DKIM. Quem envia mais de 5.000 mensagens por dia para contas Gmail precisa de SPF, DKIM e DMARC (a política pode ser
p=none), com alinhamento do domínio do "De" e cancelamento de inscrição em um clique para e-mails de marketing. Também é exigido TLS e taxa de spam abaixo de 0,3% (Google, diretrizes para remetentes). - Microsoft (Outlook.com, Hotmail e Live): quem envia 5.000 mensagens por dia ou mais a partir do mesmo domínio precisa ter SPF e DKIM válidos, um registro DMARC publicado (
p=none,quarantineoureject) e alinhamento de SPF ou DKIM com o domínio do "De". Mensagens que não cumprem são recusadas com o erro 550 5.7.515 (Microsoft, erro 550 5.7.515).
Quais os riscos de uma configuração incorreta?
Sem SPF, DKIM e DMARC funcionando juntos, a empresa fica com o pior dos mundos: os e-mails bons não chegam e os falsos chegam como se fossem seus.
- E-mails legítimos no spam. Quando um cliente diz que não recebeu a proposta, o domínio falhando na validação pode ser a causa. Isso afeta vendas e a imagem de profissionalismo.
- Phishing e spoofing contra a sua marca. Um golpista pode se passar por você ou por um fornecedor, pedir que um cliente pague em uma conta fraudulenta ou levar o financeiro a quitar boletos adulterados.
- Domínio em lista negra. Se alguém usa o seu domínio para enviar spam ou vírus, ele pode ser associado a phishing nos sistemas de reputação, com efeito cascata em toda a sua comunicação.
- Fraude do falso CEO. Sem política de rejeição, um e-mail "do CEO" às 17h pedindo uma transferência urgente parece autêntico para o financeiro. Um DMARC com
p=rejectbarra boa parte desse ataque antes que ele chegue.
Como saber se o e-mail da minha empresa está protegido?
Quatro verificações rápidas mostram a situação do seu domínio.
- Consulte os registros no DNS. Use uma ferramenta online de consulta de SPF, DKIM e DMARC, como o MXToolbox, ou comandos como
nslookupedig. Se algum registro não existe ou tem erro, é um sinal claro de que precisa de atenção. O Google Postmaster Tools também mostra a reputação do domínio no Gmail.
- Envie um e-mail de teste. Mande uma mensagem do endereço corporativo para uma conta pessoal e abra o cabeçalho completo. Procure
spf=pass,dkim=passedmarc=pass. Se aparecerfailounone, aquela validação não passou. O Gmail também avisa quando a mensagem não é autenticada. - Observe a entrega. Clientes dizendo que seus e-mails caem no spam, devoluções (bounces) citando falha de SPF ou DKIM e relatos de "e-mails estranhos" em seu nome que você não enviou indicam problema de autenticação ou falsificação em andamento.
- Leia os relatórios DMARC. Se o seu registro tem o campo
rua, os provedores enviam relatórios (em XML, em geral diários) com os IPs que usaram o seu domínio e o resultado das verificações. Ferramentas especializadas ajudam a ler esses arquivos. Sem DMARC, não há relatório, e isso já é um motivo para implementar.
O que conferir na configuração do seu domínio
SPF completo e atualizado. O registro deve existir (apenas um por domínio) e incluir todas as fontes legítimas de envio: o provedor de e-mail, o serviço de e-mail marketing, o CRM e qualquer sistema que dispare mensagens. Um erro de sintaxe pode invalidar o registro inteiro, e o SPF aceita no máximo 10 consultas de DNS. O Microsoft 365 orienta começar com ~all (soft fail) enquanto você identifica todas as origens de envio e migrar para -all (hard fail) depois (Microsoft Learn, autenticação de e-mail).
DKIM ativo em cada origem de envio. Habilite o DKIM no provedor (Microsoft 365, Google Workspace, hospedagem) e publique no DNS a chave exatamente como o provedor informar. Cada serviço de envio pode ter a sua própria chave, inclusive a plataforma de newsletter. Prefira chaves de 2048 bits quando o provedor oferecer: o Google exige no mínimo 1024.
DMARC com evolução gradual. Comece com p=none para monitorar sem afetar entregas, leia os relatórios, ajuste SPF e DKIM e avance para p=quarantine e depois p=reject. Garanta que o endereço rua aponta para uma caixa que alguém acompanha. Colocar reject antes de o SPF e o DKIM estarem corretos pode bloquear os seus próprios e-mails.
Manutenção contínua. Troque de provedor, adicione um domínio ou contrate uma ferramenta que envia e-mail? Atualize os três registros. Marque uma revisão a cada trimestre para remover entradas antigas e conferir as chaves.
Por onde começar
A segurança de e-mail costuma virar prioridade só depois de um incidente, como um cliente que depositou em uma conta errada por causa de um e-mail falso. Dá para se antecipar: consulte hoje os registros do seu domínio, faça o teste do cabeçalho e corrija o que faltar.
SPF, DKIM e DMARC formam a base da autenticação de e-mail e fazem parte de qualquer estratégia séria de segurança da informação. Para ver o que mais entra nessa estratégia, leia como proteger sua empresa contra ameaças cibernéticas e as dicas de segurança de dados para empresas. Se o seu e-mail está em migração, a migração de e-mails para o Microsoft 365 é uma boa hora para ajustar os registros.
Perguntas frequentes
O que são SPF, DKIM e DMARC em palavras simples?
SPF é a lista de servidores autorizados a enviar e-mail pelo seu domínio. DKIM é a assinatura digital que prova que a mensagem não foi alterada. DMARC é a política que diz o que fazer quando o SPF ou o DKIM falham e envia relatórios sobre o uso do domínio.
Preciso de DMARC mesmo sendo uma empresa pequena?
Sim. Qualquer domínio pode ser falsificado, independentemente do tamanho da empresa. O DMARC também protege seus clientes e melhora a entrega dos seus e-mails. Para quem envia mais de 5.000 mensagens por dia a Gmail ou Outlook.com, ele é obrigatório.
Qual a diferença entre DMARC p=none, quarantine e reject?
Com p=none, o DMARC só monitora e gera relatórios, sem bloquear nada. Com p=quarantine, e-mails que falham vão para o spam. Com p=reject, eles são recusados. O caminho recomendado é começar em none, analisar os relatórios e subir o nível aos poucos.
Como saber se alguém está falsificando o e-mail da minha empresa?
Os relatórios DMARC mostram quais IPs enviaram mensagens usando o seu domínio, inclusive os não autorizados. Outros sinais são clientes recebendo e-mails que você não enviou e devoluções de mensagens que você nunca mandou.
O Microsoft 365 já configura SPF, DKIM e DMARC por mim?
Parcialmente. Em domínios próprios, o administrador precisa publicar o SPF, ativar e publicar o DKIM e criar o registro DMARC no DNS. O Microsoft 365 não faz isso automaticamente. A Brizmo pode ajudar com essa configuração.
Fontes
- Proofpoint, State of the Phish
- FBI IC3, Internet Crime Report 2025
- Google, diretrizes para remetentes de e-mail
- Microsoft, erro NDR 550 5.7.515 no Outlook.com
- Microsoft Learn, como a autenticação de e-mail funciona no Microsoft 365
Lidera os projetos técnicos da Brizmo: migrações para o Microsoft 365, segurança com Defender, Entra ID e Intune, e governança de dados.
Conheça a Brizmo
