⚠ Requisito novo — Microsoft, Maio de 2025

Desde 5 de Maio de 2025, a Microsoft exige SPF, DKIM e DMARC (mínimo p=none) configurados para domínios que enviam mais de 5 000 emails por dia para contas Outlook.com, Hotmail e Live. Email sem autenticação correcta começa a ir para Junk; a Microsoft anunciou que passará a rejeitar mensagens não conformes em breve. Mesmo para volumes menores, configurar SPF + DKIM + DMARC é hoje uma obrigação de entregabilidade, não uma opção.

SPF, DKIM e DMARC são os três protocolos de autenticação de email que formam a defesa fundamental contra spoofing e phishing. Juntos respondem a três perguntas críticas que os servidores de email destino fazem sobre cada mensagem recebida: Este servidor está autorizado a enviar email por este domínio? (SPF), Esta mensagem foi alterada em trânsito? (DKIM), e O que fazer se as verificações falharem? (DMARC).

Este artigo cobre a implementação completa dos três protocolos para um domínio .pt gerido com Microsoft 365, com os registos DNS exactos, o procedimento de activação DKIM no portal M365, a estratégia gradual de implementação DMARC e os erros mais comuns.

1. Como os três protocolos funcionam em conjunto

Protocolo Função Tipo de registo DNS Quem define
SPF Lista os IPs/servidores autorizados a enviar email pelo domínio TXT no apex do domínio (@) Administrador DNS
DKIM Assina digitalmente cada mensagem enviada — o destinatário verifica que não foi alterada 2× CNAME (selector1 e selector2) Portal M365 gera; admin publica no DNS
DMARC Define o que fazer quando SPF ou DKIM falha: none, quarantine ou reject TXT em _dmarc.dominio.pt Administrador DNS

Sequência correcta de implementação: SPF → DKIM → DMARC. Esta ordem é obrigatória — o DMARC depende de SPF e DKIM estarem correctamente configurados e a passar antes de activar qualquer política de enforcement.

ℹ O que o DMARC faz que o SPF e DKIM sozinhos não fazem

SPF e DKIM não exigem que o domínio verificado coincida com o endereço From visível ao destinatário. Um atacante pode fazer SPF e DKIM passar com o seu próprio domínio e colocar o teu domínio no campo From — técnica chamada de display name spoofing. O DMARC introduz o conceito de alinhamento: exige que o domínio que passou SPF ou DKIM seja o mesmo do endereço From visível. Sem DMARC, SPF e DKIM protegem a infraestrutura mas não o utilizador final.

2. SPF — configurar o registo TXT

O SPF é publicado como um único registo TXT na raiz do domínio. Só pode existir um registo SPF por domínio — se já existir um (ex: de um hosting anterior), actualiza-lo; não criar um segundo.

Registo SPF para Exchange Online puro (domínio só com M365)

# Registo DNS a criar na zona do domínio
Tipo:  TXT
Nome:  @ (apex do domínio, ex: empresa.pt)
Valor: v=spf1 include:spf.protection.outlook.com -all
TTL:   3600 (1 hora)

Registo SPF com serviços adicionais (M365 + servidor on-premises + serviço de newsletter)

# Exemplo: M365 + servidor SMTP on-premises + Mailchimp
Valor: v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 include:servers.mcsv.net -all

# Estrutura de um registo SPF
v=spf1              # versão — sempre v=spf1
include:...         # inclui SPF de outro domínio (conta como 1 lookup DNS)
ip4:1.2.3.4        # autoriza IP específico
ip4:1.2.3.0/24     # autoriza range de IPs (CIDR)
mx                  # autoriza os servidores MX do domínio (evitar — consome lookups)
-all                # hard fail — rejeitar tudo o que não passou (RECOMENDADO)
~all                # soft fail — marcar como suspeito mas entregar (usar só em testes)

⚠ Limite crítico — máximo 10 DNS lookups

Um registo SPF não pode ter mais de 10 pesquisas DNS (cada include:, a:, mx: conta como 1 lookup). Quando o limite é excedido, o SPF retorna PermError e a verificação falha automaticamente — o que é idêntico a não ter SPF. Verificar com MXToolbox → SPF Record Lookup → verificar o campo “DNS Lookups”.

3. DKIM — activar assinatura digital no M365

O Microsoft 365 gera automaticamente as chaves DKIM para o domínio *.onmicrosoft.com. Para domínios personalizados (empresa.pt), é necessário activar manualmente. O processo tem dois passos: publicar registos CNAME no DNS e activar no portal M365.

Passo 1 — Obter os registos CNAME no portal M365

Caminho: security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → DKIM

  1. Seleccionar o domínio personalizado (empresa.pt)
  2. No painel que abre, o M365 mostra os dois registos CNAME a publicar — copiar os valores exactos
  3. O estado inicial mostra “Status: No DKIM keys saved for this domain” — é esperado

Passo 2 — Publicar os registos CNAME no DNS do domínio

Os valores exactos são gerados pelo M365, mas têm sempre este formato:

# Registo 1 — Selector1
Tipo:  CNAME
Nome:  selector1._domainkey.empresa.pt
Valor: selector1-empresa-pt._domainkey.empresa.onmicrosoft.com
TTL:   3600

# Registo 2 — Selector2
Tipo:  CNAME
Nome:  selector2._domainkey.empresa.pt
Valor: selector2-empresa-pt._domainkey.empresa.onmicrosoft.com
TTL:   3600

# NOTA: Os valores exactos são gerados pelo portal M365 para o teu tenant específico.
# Copia os valores directamente do portal — não os construas manualmente.

⚠ DNS com hífens no nome do domínio: Se o domínio tem hífens (ex: minha-empresa.pt), os registos CNAME gerados pelo M365 substituem os hífens por traços duplos. Copia sempre do portal — não edites manualmente.

Passo 3 — Activar DKIM no portal M365

  1. Aguardar a propagação DNS — pode demorar de minutos a 48 horas (geralmente <1 hora para zona .pt em servidores como Cloudflare ou PT/Sapo)
  2. Regressar ao portal M365 → DKIM → seleccionar o domínio
  3. Clicar em Enable (o botão só fica disponível após detectar os CNAME no DNS)
  4. Confirmar que o estado muda para “DKIM signatures enabled for this domain”

✓ Verificação imediata

Após activar, enviar um email de teste do domínio para uma conta Gmail. Na mensagem recebida no Gmail, clicar nos três pontos → Show original → procurar por dkim=pass no cabeçalho Authentication-Results. Se aparecer dkim=pass, o DKIM está operacional.

Rotação de chaves DKIM

O M365 usa dois selectores (selector1 e selector2) precisamente para permitir rotação sem downtime. A Microsoft recomenda rodar as chaves DKIM a cada 1–2 anos. No portal DKIM, o botão Rotate DKIM keys gera novas chaves automaticamente e alterna entre os dois selectores de forma transparente.

4. DMARC — implementação gradual com relatórios

O DMARC deve ser implementado de forma gradual — activar directamente p=reject sem monitorizar primeiro é um erro que pode bloquear email legítimo de sistemas que não conhecias. A sequência correcta é: none → quarantine → reject, com períodos de monitorização em cada etapa.

Etapa 1 — Monitorização (p=none) — Semanas 1 a 4

# Registo TXT a criar no DNS
Tipo:  TXT
Nome:  _dmarc.empresa.pt
Valor: v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1
TTL:   3600

# Parâmetros:
# p=none          — monitorizar apenas, sem acção sobre falhas
# rua=mailto:...  — endereço para relatórios agregados (diários)
# ruf=mailto:...  — endereço para relatórios forenses (individuais por falha)
# fo=1            — gerar relatório forense quando SPF ou DKIM falha (qualquer um)

Durante esta fase, todos os emails continuam a ser entregues normalmente. Os relatórios chegam ao endereço configurado em rua= e permitem identificar todos os sistemas que enviam email como o teu domínio — tanto legítimos (newsletters, CRM, helpdesk) como suspeitos.

Etapa 2 — Quarentena parcial (p=quarantine; pct=25) — Semanas 5 a 8

Valor: v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; fo=1

# pct=25 — aplicar a política apenas a 25% das mensagens que falham
# Aumentar progressivamente: 25% → 50% → 75% → 100%
# Se aparecerem falsos positivos, recuar para p=none e investigar

Etapa 3 — Rejeição total (p=reject) — Semana 9+

Valor: v=DMARC1; p=reject; rua=mailto:[email protected]; fo=1

# p=reject — rejeitar definitivamente mensagens que falham DMARC
# Este é o objectivo final — máxima protecção contra spoofing do domínio
# Só avançar para reject quando tiveres confiança nos relatórios DMARC:
# - SPF e DKIM a passar em todos os sistemas legítimos
# - Nenhum sistema legítimo a falhar nos relatórios há 2+ semanas

Referência de todos os parâmetros DMARC

Parâmetro Valores Descrição
p= none / quarantine / reject Política para mensagens que falham DMARC — obrigatório
rua= mailto:[email protected] Destino de relatórios agregados (XML diários) — fundamental para monitorização
ruf= mailto:[email protected] Destino de relatórios forenses (por mensagem falhada) — nem todos os provedores enviam
pct= 1–100 Percentagem de mensagens à qual aplicar a política — omitir em produção (equivale a 100)
adkim= r (relaxed) / s (strict) Alinhamento DKIM. Relaxed (por defeito): aceita subdomínios. Strict: domínio exacto
aspf= r (relaxed) / s (strict) Alinhamento SPF. Relaxed (por defeito): mais permissivo para cenários de relay
fo= 0 / 1 / d / s Quando gerar relatório forense. fo=1 (recomendado): quando SPF ou DKIM falha

5. Cenários comuns — múltiplos remetentes e serviços terceiros

A maioria das organizações usa mais do que o Exchange Online para enviar email — newsletters, CRM, helpdesk, ERP, sistemas de faturação. Cada sistema adicional tem de ser incluído na autenticação ou vai falhar DMARC.

Serviço adicional Solução recomendada
Mailchimp / Brevo / SendGrid (newsletter) Usar subdomínio dedicado: newsletter.empresa.pt. Configurar SPF e DKIM do serviço nesse subdomínio. O DMARC do domínio principal aplica-se em cascata mas o subdomínio pode ter a sua própria política mais permissiva (sp=quarantine)
Zendesk / Freshdesk / HubSpot (helpdesk/CRM) O serviço fornece DKIM próprio — seguir a documentação do fornecedor para publicar os CNAME DKIM no teu DNS. Adicionar o include: do serviço ao SPF do domínio
Sistema de faturação / ERP on-premises Configurar o sistema para enviar via Exchange Online (SMTP relay com autenticação) — assim usa o DKIM e SPF do M365. Alternativa: adicionar o IP do servidor ao SPF com ip4:
Servidor Exchange on-premises em coexistência Adicionar o IP público do servidor on-premises ao SPF. Configurar DKIM no Exchange on-premises ou enviar via M365 como smarthost

6. Verificar a configuração — ferramentas e testes

Ferramenta URL Verifica
MXToolbox Email Health mxtoolbox.com/emailhealth SPF, DKIM, DMARC, MX, blacklists — relatório completo em simultâneo
Google Admin Toolbox toolbox.googleapps.com/apps/checkmx Configuração DNS e email — vista do ponto de entregabilidade Google
Mail Tester mail-tester.com Envia um email real para o endereço fornecido e analisa SPF, DKIM, DMARC, spam score — excelente para teste end-to-end
DMARC Analyzer (dmarcian) dmarcian.com Analisa relatórios DMARC XML — transforma relatórios ilegíveis num dashboard visual
Remote Connectivity Analyzer (ExRCA) testconnectivity.microsoft.com Testes específicos de Exchange Online incluindo SPF e Autodiscover
Message Header Analyzer kbase.pt/mha.html Analise headers de email, visualize hops e diagnostique bloqueios Anubis

Verificar no cabeçalho de email recebido

Enviar um email de teste e verificar o cabeçalho Authentication-Results na mensagem recebida — o resultado esperado quando tudo está correctamente configurado:

# Exemplo de cabeçalho Authentication-Results com tudo a passar
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [email protected] designates 40.92.x.x as permitted sender)
             [email protected];
       dkim=pass [email protected] header.s=selector1 header.b=AbCdEfGh;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=empresa.pt;
       arc=pass (i=1 spf=pass spfdomain=empresa.pt dkim=pass dkdomain=empresa.pt dmarc=pass)

# Todos a "pass" = configuração correcta e completa

7. Erros comuns e como resolvê-los

Sintoma / Erro Causa provável Resolução
spf=fail Servidor de envio não está no SPF, ou existem dois registos SPF Verificar que existe um único registo TXT SPF; adicionar o servidor em falta
spf=permerror Limite de 10 DNS lookups excedido Simplificar o SPF — substituir includes aninhados por IPs directos; usar SPF flattening
dkim=fail (key not found) Registos CNAME ainda não propagados, ou DKIM não activado no portal M365 Verificar propagação DNS com MXToolbox; aguardar até 48h; confirmar activação no portal
dkim=fail (body hash mismatch) Email modificado em trânsito (ex: assinatura de disclaimer adicionada por gateway) Verificar se há gateway ou serviço de email a modificar mensagens após assinatura DKIM
dmarc=fail (alignment failed) O domínio no From não coincide com o domínio que passou SPF ou DKIM Confirmar que os serviços de envio usam o mesmo domínio no From; configurar DKIM no serviço terceiro
DKIM não pode ser activado no portal M365 CNAME ainda não propagados — o botão Enable fica desactivado Verificar os CNAME com: nslookup -type=cname selector1._domainkey.empresa.pt — aguardar propagação

8. PowerShell — gestão DKIM no Exchange Online

Connect-ExchangeOnline -UserPrincipalName [email protected]

# Ver estado DKIM de todos os domínios do tenant
Get-DkimSigningConfig | Select-Object Domain, Enabled, Status, Selector1PublicKey, Selector2PublicKey

# Ver DKIM de um domínio específico
Get-DkimSigningConfig -Identity empresa.pt | Format-List

# Activar DKIM para um domínio (após publicar os CNAME)
Set-DkimSigningConfig -Identity empresa.pt -Enabled $true

# Rodar chaves DKIM (recomendado a cada 1–2 anos)
Rotate-DkimSigningConfig -Identity empresa.pt -KeySize 2048

# Verificar registos CNAME que precisas de publicar no DNS
Get-DkimSigningConfig -Identity empresa.pt |
    Select-Object Selector1CNAME, Selector2CNAME

Verificar SPF e DKIM via DNS (nslookup)

# Verificar registo SPF
nslookup -type=txt empresa.pt
# Procurar a linha que começa com "v=spf1"

# Verificar CNAME do DKIM (selector1)
nslookup -type=cname selector1._domainkey.empresa.pt

# Verificar registo DMARC
nslookup -type=txt _dmarc.empresa.pt
# Procurar a linha que começa com "v=DMARC1"

# PowerShell equivalente (mais legível)
Resolve-DnsName empresa.pt -Type TXT | Where-Object { $_.Strings -like "v=spf1*" }
Resolve-DnsName _dmarc.empresa.pt -Type TXT

Este artigo foi útil?

Duarte Spínola

Deixe um Comentário