Dia 10: SPF, DKIM e DMARC — Autenticação de Email em Produção
SPF, DKIM e DMARC são os três pilares da autenticação de email. Sem eles, qualquer pessoa pode enviar emails em nome do seu domínio, comprometendo a reputação e abrindo a porta ao phishing. Neste Dia 10 do curso de Microsoft 365, vamos configurar os três protocolos no Exchange Online, criar os registos DNS correctos, alinhar os domínios e implementar políticas DMARC progressivas — de monitorização a rejeição.
Neste artigo
- 1. Introdução à Autenticação de Email
- 2. SPF — Sender Policy Framework
- 3. DKIM — DomainKeys Identified Mail
- 4. DMARC — Domain-based Message Authentication
- 5. Configuração Prática no M365
- 6. Resolução de Problemas e Relatórios
- 7. Erros Comuns e Lista de Verificação
1. Introdução à Autenticação de Email
O protocolo SMTP, desenvolvido em 1982, não tem qualquer mecanismo de autenticação do remetente. O campo MAIL FROM é preenchido pelo servidor que envia — não há validação de que esse servidor está autorizado a enviar em nome do domínio declarado. Isto significa que qualquer pessoa pode enviar emails aparentando vir de [email protected] sem ter acesso à mailbox.
A autenticação de email resolve este problema com três protocolos complementares:
| Protocolo | Função | Valida | Registo DNS |
|---|---|---|---|
| SPF | Lista os servidores autorizados a enviar | IP de origem | TXT no domínio |
| DKIM | Assina digitalmente cada mensagem | Conteúdo + cabeçalhos | TXT no selector |
| DMARC | Alinha SPF/DKIM e define política | From: vs MAIL FROM/DKIM | TXT em _dmarc |
No contexto do Microsoft 365, o Exchange Online já configura SPF e DKIM parcialmente, mas o administrador tem de completar os registos DNS e implementar o DMARC. Sem estes passos, os emails legítimos da organização podem ser marcados como spam ou recusados pelos destinatários — e emails falsificados chegam à caixa de entrada dos colaboradores.
2. SPF — Sender Policy Framework
O SPF (Sender Policy Framework) é um registo TXT no DNS que indica quais os endereços IP e servidores autorizados a enviar email em nome do domínio. Quando um servidor de email recebe uma mensagem, consulta o registo SPF do domínio do remetente e verifica se o IP de origem está listado.
A sintaxe do SPF é composta por mecanismos e qualificadores. O mecanismo include: permite referenciar os servidores de um fornecedor (ex: Exchange Online), e o qualificador -all rejeita todos os IPs não listados. A sintaxe completa está documentada no artigo de autenticação de email para PME.
Para o Microsoft 365, o registo SPF mínimo é:
# Registo SPF para M365 (DNS do domínio)
# TXT @ v=spf1 include:spf.protection.outlook.com -allSe a organização envia email através de outros serviços (Mailgun, SendGrid, newsletters), cada fornecedor deve ser adicionado com include:. Atenção: o SPF tem um limite de 10 consultas DNS aninhadas — exceder este limite faz o SPF falhar silenciosamente.
# SPF com múltiplos fornecedores
# TXT @ v=spf1 include:spf.protection.outlook.com include:mailgun.org -all
# Verificar SPF includes no PowerShell
Resolve-DnsName -Type TXT exemplo.pt | Where-Object Strings -like "v=spf1*"
# Verificar conectores que afectam SPF
Get-OutboundConnector | Where-Object {$_.Enabled -eq $true} | Select-Object Name, SmartHosts3. DKIM — DomainKeys Identified Mail
O DKIM adiciona uma assinatura digital a cada email enviado. Ao contrário do SPF (que valida apenas o IP de origem), o DKIM garante que o conteúdo da mensagem não foi alterado em trânsito. O Exchange Online gera duas chaves (selector1 e selector2) e publica-as como registos CNAME no DNS que apontam para registos TXT com a chave pública.
No M365, o DKIM é activado por domínio. O processo tem dois passos: (1) criar os registos CNAME no DNS público que apontam para os selectores do Exchange Online, e (2) activar a assinatura DKIM no portal ou via PowerShell.
# Activar DKIM no Exchange Online
Connect-ExchangeOnline
New-DkimSigningConfig -DomainName "exemplo.pt" -Enabled $true
# Verificar DKIM
Get-DkimSigningConfig -Identity "exemplo.pt" | Select-Object Domain, Enabled, Selector1CNAME, Selector2CNAME
# Verificar registos DNS do DKIM
Resolve-DnsName -Type TXT selector1._domainkey.exemplo.ptOs registos CNAME necessários no DNS do domínio são:
| Nome (CNAME) | Aponta para | Função |
|---|---|---|
| selector1._domainkey | selector1.exemplo-pt._domainkey.exemplo.pt.onmicrosoft.com | Chave activa |
| selector2._domainkey | selector2.exemplo-pt._domainkey.exemplo.pt.onmicrosoft.com | Chave de rotação |
A Microsoft rota as chaves automaticamente. O selector2 serve para que a rotação ocorra sem interrupção — enquanto uma chave é renovada, a outra continua a assinar as mensagens.
4. DMARC — Domain-based Message Authentication
O DMARC une SPF e DKIM através do conceito de alinhamento. O alinhamento verifica que o domínio no cabeçalho From: (visível ao utilizador) corresponde ao domínio validado por SPF ou DKIM. Sem alinhamento, um email pode passar SPF mas ser falsificado — o DMARC fecha essa brecha.
O DMARC define três políticas progressivas, que se aplicam quando um email falha a autenticação:
| Política | Comportamento | Quando usar |
|---|---|---|
| nenhuma | Não actua — apenas reporta | Fase inicial (2-4 semanas) |
| quarentena | Envia para spam/quarentena | Após analisar relatórios |
| rejeição | Rejeita na porta SMTP | Objectivo final |
ℹ O DMARC com política rejeição bloqueia emails falsificados antes de chegarem aos destinatários — é a defesa mais eficaz contra phishing do próprio domínio.
⚠️ Começar DMARC com política nenhuma (monitorização) antes de quarentena ou rejeição — caso contrário emails legítimos podem ser bloqueados.
O registo DMARC é publicado como TXT em _dmarc.exemplo.pt e inclui a política (p=), o endereço para relatórios agregados (rua=) e forenses (ruf=), e a percentagem de aplicação (pct=). Mais detalhes em dmarc.org.
# DMARC XML reports — exemplo de registo
# _dmarc.exemplo.pt TXT: v=DMARC1; p=quarentena; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100
# Verificar registo DMARC no DNS
Resolve-DnsName -Type TXT _dmarc.exemplo.pt5. Configuração Prática no M365
A implementação no Microsoft 365 segue uma sequência obrigatória: SPF primeiro, DKIM a seguir, DMARC por último. Saltar passos provoca falsos negativos. O portal M365 (Defender > Email Authentication) mostra o estado de cada protocolo, mas os registos DNS têm de ser criados manualmente no gestor de DNS do domínio.
Passo a passo para a implementação completa:
# 1. Verificar registos DNS existentes
Resolve-DnsName -Type TXT exemplo.pt | Where-Object Strings -like "v=spf1*"
Resolve-DnsName -Type TXT selector1._domainkey.exemplo.pt
Resolve-DnsName -Type TXT _dmarc.exemplo.pt
# 2. Activar DKIM no Exchange Online
Connect-ExchangeOnline
New-DkimSigningConfig -DomainName "exemplo.pt" -Enabled $true
# 3. Confirmar configuração DKIM
Get-DkimSigningConfig -Identity "exemplo.pt" | Select-Object Domain, Enabled, Selector1CNAME, Selector2CNAME
# 4. Verificar SPF includes (depois de adicionar registo DNS)
# TXT record: v=spf1 include:spf.protection.outlook.com include:mailgun.org -all
# 5. Verificar conectores que afectam SPF
Get-OutboundConnector | Where-Object {$_.Enabled -eq $true} | Select-Object Name, SmartHosts
# 6. Verificar mail flow rules que afectam autenticação
Get-TransportRule | Where-Object {$_.State -eq "Enabled"} | Select-Object Name, PriorityO alinhamento de domínios é o aspecto mais crítico do DMARC. Existem dois modos: flexível (pré-definido) aceita subdomínios — mail.exemplo.pt alinha com exemplo.pt; rigoroso exige correspondência exacta. Para a maioria das PME, o modo flexível é suficiente e evita falsos positivos.
6. Resolução de Problemas e Relatórios
Os relatórios DMARC (enviados via rua=) são ficheiros XML enviados diariamente pelos fornecedores de email (Google, Microsoft, Yahoo) com dados agregados sobre mensagens que passaram ou falharam a autenticação. Estes relatórios são essenciais para detectar fontes legítimas não autorizadas antes de mudar de nenhuma para quarentena ou rejeição.
No Exchange Online, o Get-MessageTrace permite rastrear mensagens enviadas nos últimos 10 dias e identificar falhas de entrega associadas a problemas de autenticação.
# Verificar falhas de entrega
Get-MessageTrace -SenderAddress "[email protected]" -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) | Where-Object {$_.Status -eq "Failed"}
# Analisar cabeçalhos de email
# Receber email → View source → Procurar Authentication-Results
# PowerShell: analisar cabeçalho
$header = "Authentication-Results: spf=pass dkim=pass dmarc=pass"O cabeçalho Authentication-Results mostra o resultado de cada protocolo. Os valores possíveis são:
| Resultado | SPF | DKIM | DMARC |
|---|---|---|---|
| pass | IP autorizado | Assinatura válida | Alinhamento OK |
| fail | IP não autorizado | Assinatura inválida | Sem alinhamento |
| nenhuma | Sem registo | Sem assinatura | Sem política |
Para analisar os relatórios XML do DMARC de forma estruturada, ferramentas como o DMARC Analyzer ou serviços gratuitos como o Valimail Monitor permitem converter os XML em painéis legíveis com origens de tráfego, volume de falhas e domínios não alinhados.
7. Erros Comuns e Lista de Verificação
Os problemas mais frequentes na implementação de SPF, DKIM e DMARC no M365 resultam de configurações DNS incorrectas ou pressa em avançar a política DMARC. Aqui estão os erros típicos e como os evitar:
| Problema | Causa | Solução |
|---|---|---|
| SPF fail | IP não listado ou ~all em vez de -all | Adicionar include do fornecedor; usar -all |
| DKIM fail | CNAME em falta ou DKIM desactivado | Criar CNAMEs e activar no Exchange |
| DMARC rejeição legítimos | Saltar fase nenhuma; pct=100 logo no início | Começar com p=nenhuma pct=10 |
| SPF too many DNS lookups | Mais de 10 includes aninhados | Consolidar includes ou usar consolidação SPF |
| Emails legítimos na quarentena | Mailings sem alinhamento DMARC | Autorizar IPs no SPF; usar subdomínio |
Lista de verificação para implementação completa:
- ✓ Registo SPF publicado com
include:spf.protection.outlook.come-all - ✓ CNAMEs DKIM (selector1 e selector2) criados no DNS público
- ✓ DKIM activado no Exchange Online via
New-DkimSigningConfig - ✓ Registo DMARC em
_dmarc.exemplo.ptcomp=nenhumainicial - ✓ Endereço
rua=configurado para receber relatórios agregados - ✓ Verificação de
Authentication-Results: spf=pass dkim=pass dmarc=passem emails de teste - ✓ 2-4 semanas de relatórios analisados antes de mudar para
p=quarentena - ✓ Progressão para
p=rejeiçãoapenas sem falsos positivos
A implementação de SPF, DKIM e DMARC é progressiva. O objectivo final é p=rejeição, mas saltar etapas coloca em risco a entrega de emails legítimos. Monitorizar os relatórios, corrigir fontes não autorizadas e só depois avançar a política — é a diferença entre segurança efectiva e interrupção de comunicação.
Artigos relacionados:
- Exchange Online em 2026: Configuração, Protecção e Troubleshooting
- DKIM, DMARC e SPF: Autenticação de Email para PME em 2026
- Dia 8: DNS em Profundidade — Zonas, Forward/Reverse, DNSSEC e Caching
- Dia 8: Exchange Online — Configuração Inicial para PME
- DKIM, DMARC e SPF: Autenticação de Email para PME em 2026