Existe uma categoria de problema que aparece assim: “o cliente disse que não recebeu nosso e-mail, mas a gente mandou”. Ou pior: “um fornecedor recebeu uma cobrança falsa com o nosso nome”.
Nos dois casos a causa costuma ser a mesma, e ela mora em três registros de DNS que quase ninguém olha: SPF, DKIM e DMARC.
Este artigo explica os três sem jargão, porque a decisão sobre eles é de negócio, não de TI.
O problema que eles resolvem
O e-mail foi inventado sem nenhuma verificação de remetente. Do jeito que o protocolo funciona, qualquer servidor do mundo pode mandar uma mensagem dizendo que é você. Não é falha de configuração: é o desenho original.
Os três registros são a correção que veio depois. Cada um resolve uma parte:
| O que faz | Analogia | |
|---|---|---|
| SPF | Lista quais servidores podem enviar pelo seu domínio | A portaria tem a lista de quem pode entrar |
| DKIM | Assina a mensagem para provar que não foi alterada | O lacre no envelope |
| DMARC | Diz o que fazer quando a verificação falha | A ordem para o porteiro: barrar ou deixar passar |
Nenhum funciona sozinho. SPF sem DMARC é lista sem porteiro.
SPF: quem pode falar pela sua empresa
O SPF é um registro de texto no seu DNS que diz, em linguagem de máquina: “as mensagens do meu domínio saem destes servidores”.
Quando um e-mail seu chega ao servidor do destinatário, ele consulta essa lista. Se o remetente não estiver nela, a mensagem fica sob suspeita.
O erro mais comum, e o mais caro: ter dois registros SPF. É o que acontece quando alguém contrata um serviço novo de e-mail marketing, o fornecedor manda “adicione este SPF”, e a pessoa adiciona um segundo registro em vez de editar o que já existe.
Dois SPF equivalem a nenhum: a validação falha de imediato e todo o seu e-mail passa a ser tratado com desconfiança. Precisa existir um único registro, contendo todas as origens legítimas.
A outra armadilha é esquecer alguém da lista. O ERP que emite nota, o sistema de RH, a plataforma de campanha, o formulário do site, a impressora que digitaliza e envia. Se não estiver no SPF, não passa.
DKIM: a prova de que ninguém mexeu
O DKIM assina cada mensagem que sai com uma chave criptográfica. O servidor que recebe confere a assinatura contra a chave pública publicada no seu DNS.
Se bater, duas coisas ficam provadas: a mensagem saiu mesmo de quem diz, e o conteúdo não foi alterado no caminho.
É mais robusto que o SPF por um motivo prático: o DKIM sobrevive ao encaminhamento. Quando alguém repassa o seu e-mail, o SPF quebra (o servidor que encaminha não está na sua lista), mas a assinatura DKIM continua válida.
No Microsoft 365 o DKIM existe, mas em muitos ambientes vem desligado. Vale conferir — é um dos ajustes mais fáceis e mais esquecidos. A Microsoft documenta o processo em autenticação de e-mail no Microsoft 365.
DMARC: a decisão
Com SPF e DKIM configurados, falta a parte que ninguém faz: dizer o que o mundo deve fazer quando a verificação falhar.
É o DMARC. Ele tem três posturas:
p=none— “verifique, me informe, mas entregue mesmo assim”. É o modo de observação.p=quarantine— “se falhar, mande para o spam”.p=reject— “se falhar, recuse a entrega”.
Quase todo domínio que tem DMARC está em p=none e ficou lá. Isso significa que a empresa montou o sistema de verificação inteiro e deixou a porta destrancada: quem se passar por você continua sendo entregue.
p=nonenão protege ninguém. Ele só informa. É um ponto de partida, nunca um destino.
O DMARC também manda relatórios diários para um endereço que você escolhe. É ali que você descobre quem está enviando pelo seu domínio — inclusive os sistemas que você esqueceu que existiam.
O caminho certo, em três etapas
A ordem importa. Apertar o DMARC antes de a casa estar em ordem derruba e-mail legítimo.
Etapa 1 — Inventário e observação. Levante todo mundo que envia pelo seu domínio, monte um SPF único com todos, ative o DKIM e publique DMARC em p=none com relatórios. Fique assim por algumas semanas.
Etapa 2 — Leia os relatórios. Eles vão mostrar envios que você não esperava. Para cada um: ou é legítimo e entra no SPF, ou não é e você acabou de descobrir que alguém usa o seu nome.
Etapa 3 — Aperte. Quando os relatórios estiverem limpos, suba para p=quarantine. Depois de mais algumas semanas sem surpresa, p=reject.
A etapa 2 é a que todo mundo pula, e é a única que impede o tiro no pé.
Por que isso vale o trabalho
Dois motivos, e o segundo é o que costuma convencer:
Entregabilidade. Provedores grandes tratam domínio sem autenticação com desconfiança crescente. Não é mais “fica melhor com”: é “fica ruim sem”.
Golpe com o seu nome. Sem DMARC em p=reject, qualquer pessoa pode mandar um e-mail que parece seu para os seus clientes. O golpe clássico — “mudamos de banco, paguem nesta conta” — depende exatamente disso. O prejuízo não é seu: é do seu cliente, com o seu nome na mensagem.
O teste de cinco minutos
Três perguntas para a sua TI:
- Quantos registros SPF o nosso domínio tem? Se a resposta não for “um”, há um problema agora.
- O DKIM está ativo? No Microsoft 365 ele frequentemente não está.
- Em que postura está o nosso DMARC? Se for
p=noneou não existir, qualquer um pode se passar por você hoje.
Se as três respostas não vierem rápidas, vale meia hora de conversa — é dos ajustes de maior retorno e menor custo que existem em e-mail corporativo.