SPF, DKIM e DMARC no Exchange Online: como impedir que usem o domínio da sua empresa

Um e-mail chega ao seu cliente parecendo vir do endereço da sua empresa, com o seu domínio depois do @, cobrando um boleto que você não emitiu. Não houve invasão: qualquer servidor no mundo pode escrever “de” um domínio que ninguém protegeu como remetente. SPF, DKIM e DMARC são os três registros de DNS que fecham essa porta no Exchange Online, e o Microsoft 365 configura só um deles por você. A Global Data, empresa de TI em São Paulo, publica e administra os três dentro do Microsoft 365 gerenciado, porque o Exchange Online está no escopo do serviço.

Três registros, três perguntas diferentes

Os três costumam aparecer juntos e por isso se confundem, mas cada um responde a uma pergunta distinta.

O SPF é a lista de quem pode enviar em nome do domínio: os servidores e serviços autorizados a mandar e-mail com o seu nome depois do @. O DKIM é uma assinatura digital que viaja com cada mensagem e prova duas coisas ao destinatário: que ela saiu mesmo de onde diz ter saído e que não foi alterada no caminho. O DMARC é a política que diz ao servidor do destinatário o que fazer quando o SPF e o DKIM falham — deixar passar, mandar para o spam ou rejeitar — e para onde enviar os relatórios do que aconteceu. Dá para pensar assim: o SPF e o DKIM verificam a mensagem, e o DMARC decide o que fazer com o resultado.

O que o Microsoft 365 configura sozinho e o que deixa para você

Aqui está a parte que engana. Contratar o Microsoft 365 e apontar o domínio não deixa os três de pé; só o primeiro, e mesmo assim pela metade.

O SPF você já criou sem perceber: o processo de conectar o domínio ao Microsoft 365 pediu o registro que aponta o spf.protection.outlook.com como fonte autorizada de e-mail. Esse está de pé. O DKIM para o seu domínio próprio, ao contrário, não vem ligado. Só o domínio onmicrosoft.com, que pertence à Microsoft, é assinado automaticamente; para o seu domínio de verdade, é preciso publicar dois registros CNAME (o selector1 e o selector2) e ativar a assinatura no portal. Enquanto isso não acontece, o painel mostra o DKIM como pendente. E o DMARC o Microsoft 365 não cria em nenhuma hipótese para um domínio próprio: não existe tela nem comando para isso no serviço. O registro precisa ser publicado por você, no provedor de DNS onde o domínio está hospedado.

Os erros que derrubam e-mail legítimo

Configurar errado esses registros não deixa a empresa exposta só ao golpista; derruba o e-mail que ela mesma manda. Quatro erros aparecem com frequência.

O primeiro é estourar o limite de dez consultas de DNS no SPF. Cada ferramenta que envia pelo domínio — o ERP, a plataforma de e-mail marketing, o sistema de nota fiscal — costuma pedir mais uma entrada no registro, e passar de dez consultas faz o SPF falhar por completo, de forma silenciosa. O segundo é deixar o DMARC em p=none para sempre: nesse modo ele só observa e envia relatório, nunca bloqueia nada, o que dá uma falsa sensação de proteção. O terceiro é o oposto: pular direto para p=reject antes de autenticar todas as fontes legítimas. Se o CRM ou a plataforma de disparo ainda não passam no SPF ou no DKIM, o reject derruba o e-mail verdadeiro junto com o falso. O quarto é publicar o registro com o endereço de relatório (rua) e nunca ler o que chega, quando é justamente o relatório que mostra quem está enviando pelo seu domínio antes de você apertar o reject.

O que o DMARC não resolve

O DMARC em reject, bem configurado, impede o uso do seu domínio exato. Ninguém consegue mandar e-mail escrevendo @suaempresa.com.br sem estar autorizado. O que ele não impede é o domínio parecido: suaempresa-rh.com.br, com um hífen a mais, ou uma letra trocada que passa despercebida na pressa. Esse domínio é outro, não é o seu, e o seu DMARC não tem autoridade sobre ele.

É aí que o problema deixa de ser técnico e vira monitoramento de marca e canais oficiais. Foi assim no golpe da vaga falsa que usou o nome da Global Data: o criminoso não precisou do nosso domínio, usou um endereço gratuito e a nossa razão social. A defesa, nesse caso, é ter uma página de canais oficiais que diz publicamente por onde a empresa fala de verdade. O DMARC protege o domínio; a página de canais protege o nome.

Como a Global Data faz isso no Microsoft 365 gerenciado

O primeiro passo, para nós, não é publicar registro nenhum. É inventariar quem envia e-mail pelo domínio da empresa: o Microsoft 365, claro, mas também o ERP, o sistema de cobrança, a ferramenta de marketing, o formulário do site. Cada fonte legítima precisa passar no SPF ou no DKIM antes de qualquer bloqueio entrar em cena. Com o inventário na mão, autenticamos fonte por fonte e subimos o DMARC em etapas — de none para quarantine e só então reject —, lendo os relatórios a cada passo para não derrubar e-mail bom.

Depois que os três estão de pé, o registro não fica parado: fonte nova que entra, ferramenta que sai, tudo passa por revisão, porque um SPF esquecido volta a falhar sozinho com o tempo. Essa administração contínua faz parte do Microsoft 365 gerenciado, com o Exchange Online e a autenticação de e-mail sob gestão da Global Data. A camada técnica trava a fraude no transporte; o que ela não pega, o comportamento das pessoas, tratamos com simulação de phishing.

Perguntas frequentes

Meu Microsoft 365 já tem DMARC?

Para o seu domínio próprio, quase certamente não. O Microsoft 365 configura o SPF durante a conexão do domínio e assina automaticamente apenas o domínio onmicrosoft.com. O DMARC do seu domínio de verdade não é criado pela Microsoft: alguém precisa publicá-lo no seu provedor de DNS. Dá para checar consultando o registro TXT em _dmarc.suaempresa.com.br; se não houver resposta, você não tem DMARC.

Posso ir direto para p=reject?

Não é recomendado. O reject manda o servidor do destinatário rejeitar todo e-mail que falha na autenticação, e se alguma fonte legítima (o ERP, o CRM, a plataforma de disparo) ainda não passa no SPF ou no DKIM, você derruba o próprio e-mail junto com o falso. O caminho seguro é começar em p=none, ler os relatórios para mapear todas as fontes, passar por quarantine e só então chegar ao reject.

DMARC impede o golpe da vaga falsa?

Só em parte. O DMARC impede que usem o seu domínio exato para mandar e-mail, o que corta uma das variantes do golpe. Ele não impede que criem um domínio parecido ou usem um e-mail gratuito com o nome da sua empresa, como aconteceu no golpe da vaga falsa em que fomos usados de isca. Contra isso, o que vale é o monitoramento da marca e uma página de canais oficiais divulgando por onde a empresa realmente fala.