Se você administra o Microsoft 365, provavelmente já ouviu falar em SPF, DKIM e DMARC. Esses três recursos são a base da autenticação de e-mails moderna e tem como objetivo evitar spoofing, phishing e melhorar a reputação do seu domínio.
Apesar de normalmente aparecerem juntos, cada um resolve um problema diferente. Vamos entender o que é cada um deles, como funcionam na prática e como o Microsoft 365 usa esses recursos.
O que é SPF (Sender Policy Framework)
O SPF é o mecanismo mais simples de entender. Ele responde a uma pergunta básica:
“Este servidor está autorizado a enviar e-mails em nome deste domínio?”
É como o remetente de uma carta, você confirma o endereço do remetente antes de abrir a carta
O SPF funciona por meio de um registro TXT no DNS do seu domínio. Nesse registro, você lista quais servidores ou serviços podem enviar e-mails usando aquele domínio.
Exemplo prático de SPF no Microsoft 365
Quando você usa apenas o Microsoft 365 para envio de e-mails, um registro SPF comum seria algo assim:
v=spf1 include:spf.protection.outlook.com -all
Vamos quebrar isso em partes:
- v=spf1 indica a versão do SPF
- include:spf.protection.outlook.com autoriza os servidores do Microsoft 365 a enviar e-mails pelo seu domínio
- -all indica que qualquer outro servidor que tentar enviar e-mail deve ser rejeitado
Se você também usa outros serviços, como uma ferramenta de disparo de e-mails (RD Station, Sendgrid, etc), eles também precisam estar listados no SPF.
Nesse exemplo, no servidor DNS do Azure, criei um registro TXT para meu domínio. Note que eu libero outros servidores além da Microsoft:
CUIDADO! É bem comum esquecer de atualizar o SPF quando se adiciona um novo serviço, fazendo com que e-mails legítimos comecem a cair em spam ou sejam rejeitados.
O que é DKIM (DomainKeys Identified Mail)
Enquanto o SPF valida de onde o e-mail foi enviado, o DKIM valida se o conteúdo do e-mail foi alterado no caminho.
O DKIM funciona como uma assinatura digital. O servidor que envia o e-mail assina a mensagem usando uma chave privada, e o servidor que recebe valida essa assinatura usando uma chave pública publicada no DNS.
Se o conteúdo do e-mail for modificado depois do envio, a assinatura deixa de ser válida.
Imagine que o DKIM é um selo. Se esse selo estiver violado, a mensagem não é mais confiável.
DKIM no Microsoft 365, na prática
No Microsoft 365, o DKIM para o domínio é configurado no portal do Defender (https://security.microsoft.com):
Menu “Email e Colaboração” > “Políticas e Regras” > “Políticas de Ameaças”
Na sessão “Regras”, há a configuração “Configurações de Autenticação de E-mail”. Na guia “DKIM” você consegue habilitar o recurso para cada domínio cadastrado no seu Tenant:
Quando você ativa o DKIM para um domínio, a Microsoft pede que você crie dois registros CNAME no DNS, normalmente parecidos com estes:
selector1._domainkey.seudominio.com.br
selector2._domainkey.seudominio.com.br
Esses registros apontam para domínios gerenciados pela Microsoft, onde ficam as chaves públicas.
Depois de criados, o Exchange Online passa a assinar automaticamente os e-mails enviados pelo seu domínio.
Um ponto importante: diferente do SPF, o DKIM não costuma quebrar envio de e-mails se estiver mal configurado, mas faz muita diferença na reputação do domínio e na entrega em caixas como Outlook, Gmail e Yahoo.
O que é DMARC (Domain-based Message Authentication, Reporting and Conformance)
O DMARC é o mecanismo que orienta ações. Ele usa os resultados do SPF e do DKIM para decidir o que deve ser feito quando um e-mail falha na autenticação.
Além disso, o DMARC permite que você receba relatórios sobre quem está enviando e-mails em nome do seu domínio, inclusive tentativas de fraude.
Imagine que o DMARC são as instruções que o carteiro recebe sobre o que fazer com mensagens inválidas ou suspeitas:
Com o DMARC, você consegue dizer algo como:
“Se um e-mail falhar no SPF e no DKIM, faça isso com ele.”
As ações possíveis são:
- none: apenas monitora, não bloqueia nada
- quarantine: envia o e-mail para spam
- reject: rejeita o e-mail
Exemplo de DMARC para Microsoft 365
Um registro DMARC inicial, focado em monitoramento, pode ser assim:
v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com.br; ruf=mailto:dmarc@seudominio.com.br; fo=1
O que isso significa:
v=DMARC1 indica a versão do DMARC utilizada
- p=none indica que nenhuma ação será tomada, apenas monitoramento
- rua define para onde vão os relatórios agregados
- ruf define para onde vão os relatórios forenses (quando suportados)
- fo=1 indica que relatórios devem ser enviados em qualquer falha
Depois de analisar os relatórios e ajustar SPF e DKIM, o ideal é evoluir para algo mais restritivo, como:
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@seudominio.com.br
E, em um cenário maduro:
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@seudominio.com.brRecebendo relatórios e como analisar
Quando você tem um registro DMARC válido no seu DNS, o e-mail indicado no campo RUA e RUF, passa a receber e-mails periódicos de outros servidores de e-mail. Esses e-mails contém relatórios em formato XML sobre a autenticação SPF e DKIM dos seus e-mails. Existem algumas ferramentas gratuitas na Internet para ler esses relatórios, como o MXToolbox (https://mxtoolbox.com/DmarcReportAnalyzer.aspx)
Relatório em XML:
O mesmo relatório analisado no MXToolbox (bem melhor, não?)
Além disso, existem ferramentas mais profissionais, como o PowerDMARC (https://powerdmarc.com/), onde você pode apontar seu relatórios e todos são analisados, inclusive com relatórios personalizados, alertas, etc. Um prato cheio para auditorias de segurança.
Como SPF, DKIM e DMARC trabalham juntos
Uma boa forma de visualizar isso é pensar em camadas:
- SPF valida o servidor de origem
- DKIM valida a integridade da mensagem
- DMARC define a política e gera visibilidade
Um e-mail passa no DMARC quando pelo menos um dos mecanismos (SPF ou DKIM) passa e está alinhado com o domínio do remetente.
No Microsoft 365, quando os três estão corretamente configurados, você melhora significativamente:
- a entrega dos e-mails
- a proteção contra spoofing do seu domínio
- a confiança dos provedores de e-mail no seu ambiente
Algumas boas práticas no Microsoft 365
- Nunca use vários registros SPF; sempre consolide em um único TXT
- Evite usar +all no SPF; isso basicamente desativa a proteção
- Ative o DKIM para todos os domínios aceitos no tenant
- Comece o DMARC em modo none e evolua gradualmente
- Leia os relatórios DMARC ou use ferramentas que facilitem essa análise
