SPF, DKIM e DMARC são três registros no DNS do seu domínio que provam que um e-mail com o endereço da sua empresa foi mesmo enviado por você. O SPF diz quais servidores podem enviar em nome do domínio, o DKIM coloca uma assinatura digital em cada mensagem e o DMARC diz ao Gmail, ao Outlook e aos outros provedores o que fazer quando uma mensagem não passa nessas verificações.
Sem esses registros, o e-mail da empresa fica parecido com uma mensagem falsificada. O resultado aparece no dia a dia: orçamento que o cliente diz não ter recebido, nota fiscal que cai no lixo eletrônico, resposta que nunca chega. Na maior parte dos casos que atendemos, a causa é um desses três registros faltando ou escrito errado.
Resumo: o que cada registro faz
| Registro | Pergunta que responde | Onde fica no DNS | Exemplo |
|---|---|---|---|
| SPF | “Este servidor pode enviar e-mail por este domínio?” | TXT no próprio domínio (suaempresa.com.br) |
v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all |
| DKIM | “Esta mensagem foi assinada pelo dono do domínio e chegou sem alteração?” | TXT em seletor._domainkey.suaempresa.com.br |
v=DKIM1; k=rsa; p=MIIBIjAN... |
| DMARC | “Se falhar, o que o provedor deve fazer, e para onde mando o relatório?” | TXT em _dmarc.suaempresa.com.br |
v=DMARC1; p=none; rua=mailto:dmarc@suaempresa.com.br |
Os três trabalham juntos. O SPF e o DKIM fazem a verificação; o DMARC exige que pelo menos um deles passe com o mesmo domínio que aparece no “De:” da mensagem (o chamado alinhamento) e define a política para o que falhar.
Por que isso ficou mais importante desde 2024
O Gmail passou a exigir autenticação de quem envia e-mail para contas pessoais a partir de fevereiro de 2024, e apertou a fiscalização em novembro de 2025: mensagem fora das regras pode ser atrasada ou recusada. Quem envia grande volume (por volta de 5.000 mensagens por dia para o Gmail) precisa ter SPF, DKIM e DMARC. A Microsoft adotou regra parecida para o Outlook.com e o Hotmail em maio de 2025.
Uma empresa pequena raramente chega a esse volume, mas o efeito aparece mesmo assim. Os filtros anti-spam dão pontos negativos para mensagem sem assinatura ou com SPF falhando. Junte isso a um assunto em caixa alta ou a um anexo de nota fiscal e a mensagem legítima vai para o spam.
SPF: a lista de quem pode enviar pelo seu domínio
O SPF é um registro TXT que começa com v=spf1 e lista os servidores autorizados. Cada serviço que envia e-mail com o seu domínio precisa estar ali: o servidor de e-mail da hospedagem, o Google Workspace ou o Microsoft 365, a ferramenta de e-mail marketing, o sistema que emite nota fiscal.
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:spf.protection.outlook.com ~allip4:autoriza um endereço IP específico (o do servidor de e-mail).include:autoriza todos os servidores de um serviço (Google, Microsoft, plataforma de e-mail marketing).- O final define o que fazer com o resto:
~all(falha “leve”, a mensagem é marcada como suspeita) ou-all(falha “dura”, a mensagem deve ser recusada).
Erros de SPF que mais vemos:
- Dois registros SPF no mesmo domínio. Só pode existir um. Quando alguém cria um segundo para “acrescentar o Google”, os dois passam a ser ignorados. O certo é juntar tudo numa linha só.
- Esquecer um serviço que também envia. O site, o ERP ou o sistema de boletos manda e-mail com o seu domínio, mas não está no SPF.
- Usar
-allsem ter certeza da lista. Com a falha dura, qualquer servidor esquecido passa a ter as mensagens recusadas. - Passar de 10 consultas. Cada
include:conta. Com muitos serviços, o SPF estoura o limite e falha inteiro.
DKIM: a assinatura de cada mensagem
O DKIM funciona com um par de chaves. O servidor de e-mail guarda a chave privada e assina cada mensagem enviada; a chave pública fica publicada no DNS, num endereço com um “seletor” (por exemplo x._domainkey.suaempresa.com.br ou google._domainkey.suaempresa.com.br). O provedor que recebe a mensagem busca a chave pública e confere a assinatura. Se o texto foi alterado no caminho, ou se a chave publicada não bate com a usada para assinar, o DKIM falha.
Na prática, você não cria a chave à mão. O painel da hospedagem, o Google Workspace ou o Microsoft 365 geram a chave e mostram o registro que precisa ir para o DNS. O trabalho é copiar o registro exatamente como foi gerado e publicar no lugar certo.
DMARC: a regra e o relatório
O DMARC é um TXT em _dmarc.suaempresa.com.br. A parte mais importante é a política (p=):
p=none: só monitora. Nada muda na entrega, mas você passa a receber relatórios.p=quarantine: o que falhar vai para o spam.p=reject: o que falhar é recusado.
O caminho seguro é gradual: comece com p=none e um endereço em rua= para receber os relatórios, confira por algumas semanas se todos os seus serviços legítimos passam e só então suba para quarantine e depois reject. Pular direto para reject sem conferir é a forma mais rápida de bloquear o próprio sistema de nota fiscal.
O DMARC também protege a marca: com quarantine ou reject, fica bem mais difícil alguém mandar golpe usando o endereço da sua empresa.
Como conferir se o seu e-mail está autenticado
O teste mais simples leva dois minutos:
- Envie um e-mail da conta da empresa para uma conta pessoal do Gmail.
- No Gmail, abra a mensagem, clique nos três pontinhos e em Mostrar original.
- No topo aparecem três linhas: SPF, DKIM e DMARC. O esperado é
PASSnas três.
Se aparecer FAIL, SOFTFAIL ou NONE em alguma, o registro correspondente está faltando ou errado. Repita o teste a partir de cada sistema que envia e-mail com o seu domínio (formulário do site, ERP, e-mail marketing), porque cada um pode ter um resultado diferente.
Passo a passo para configurar
- Liste tudo o que envia e-mail com o seu domínio: caixas de e-mail, site, sistemas, e-mail marketing.
- Descubra onde está o DNS do domínio. Pode ser o Registro.br, a Cloudflare ou o painel da hospedagem. É lá que os registros são criados, não no servidor de e-mail.
- Monte um único registro SPF com todos os serviços da lista.
- Ative o DKIM em cada serviço e publique o registro que ele gerar.
- Crie o DMARC com
p=nonee um endereço para os relatórios. - Teste com o “Mostrar original” e, depois de algumas semanas sem falhas, endureça a política do DMARC.
Três casos reais que atendemos
Notas fiscais no lixo eletrônico. Uma indústria cliente percebeu que as notas fiscais emitidas pelo próprio sistema estavam caindo no lixo eletrônico dos destinatários, inclusive dos colegas da mesma empresa. Ao investigar, encontramos quase 800 mensagens legítimas presas no lixo eletrônico. A causa: depois de uma migração, a chave DKIM existia no servidor e assinava as mensagens, mas o registro com a chave pública nunca tinha sido publicado no DNS. O DKIM falhava em toda mensagem. Publicado o registro, a verificação passou a dar PASS e as notas voltaram para a caixa de entrada.
SPF que só autorizava a Microsoft. Uma empresa usava o Microsoft 365, com um SPF que autorizava apenas os servidores da Microsoft e terminava em -all. Parte das mensagens passava por outro servidor antes de chegar ao destino, e esse servidor não estava no SPF. Para o Outlook, aquilo parecia falsificação em massa, e as entregas começaram a ser seguradas. A correção foi incluir o IP do servidor no SPF e ajustar a configuração do lado do Microsoft 365.
O problema era do fornecedor. Um cliente reclamou que os códigos de acesso de um fornecedor sempre caíam no spam. O servidor do fornecedor não assinava DKIM e não tinha DMARC: tecnicamente, a mensagem era indistinguível de uma falsificação. Do nosso lado dá para liberar o remetente, mas a solução definitiva era o fornecedor configurar os registros.
Quando vale pedir ajuda
Se o “Mostrar original” mostra falha e você não sabe onde está o DNS do domínio, se há vários sistemas enviando com o mesmo domínio ou se você vai migrar o e-mail de lugar, vale ter alguém fazendo e testando a configuração. Um registro errado não dá aviso: as mensagens simplesmente param de chegar.
Na hospedagem de e-mail da W2, SPF, DKIM e DMARC são configurados e testados na criação das contas e na migração, junto com webmail e anti-spam. Se o e-mail da sua empresa já está em outro lugar e está caindo no spam, fale com a gente pelo WhatsApp e conferimos os registros do seu domínio.
Leia também: Como criar e usar e-mail corporativo com o domínio da empresa.
Perguntas frequentes
O que é SPF no e-mail?
SPF (Sender Policy Framework) é um registro TXT no DNS do domínio que lista quais servidores podem enviar e-mail em nome dele. O provedor que recebe a mensagem confere se o servidor de origem está na lista; se não estiver, a mensagem perde pontos ou é recusada.
Posso ter dois registros SPF no mesmo domínio?
Não. O domínio só pode ter um registro que começa com v=spf1. Com dois, os provedores consideram o SPF inválido. Para autorizar mais de um serviço, junte todos no mesmo registro, com um include: ou ip4: para cada.
O que é DMARC e qual política usar?
DMARC é o registro que diz ao provedor o que fazer quando uma mensagem falha no SPF e no DKIM, e para onde mandar relatórios. Comece com p=none para monitorar; depois de confirmar que todos os seus serviços passam, suba para p=quarantine e, por fim, p=reject.
Configurei SPF, DKIM e DMARC e o e-mail ainda vai para o spam. Por quê?
A autenticação é a base, mas os filtros também avaliam a reputação do servidor, o conteúdo (assunto em caixa alta, só imagem, muitos links), anexos e se os destinatários abrem ou marcam como spam. Confira primeiro se as três verificações dão PASS no “Mostrar original”; se derem, o problema está em outro desses pontos.
Preciso de SPF, DKIM e DMARC se uso Google Workspace ou Microsoft 365?
Sim. O Google e a Microsoft fornecem a infraestrutura, mas os registros ficam no DNS do seu domínio e precisam ser publicados por quem administra esse DNS. O DKIM, em especial, vem desligado até alguém ativar no painel e publicar o registro.
