Erro 550 5.7.515 Access Denied no Outlook.com: Como Resolver com SPF, DKIM e DMARC
Email · NDR · SPF · DKIM · DMARC · Outlook.com · Hotmail · Remetentes Alto Volume | ✎ Duarte Spínola | 21 de Maio de 2026
O erro 550 5.7.515 Access denied, sending domain does not meet the required authentication level é uma rejeição NDR que o Outlook.com (e os serviços Microsoft de email de consumidor — Hotmail, Live.com, MSN) passou a devolver a remetentes de alto volume sem autenticação de email correctamente configurada. A mensagem não chega ao destinatário — é devolvida ao servidor de origem.
Este erro surgiu no seguimento dos novos requisitos de autenticação que a Microsoft anunciou em 2025 para remetentes que enviam 5.000 ou mais mensagens por dia para endereços Outlook.com/Hotmail/Live. A solução passa por configurar correctamente SPF, DKIM e DMARC no DNS do domínio remetente — o que este guia explica passo a passo.
⚠ Mensagem NDR completa
550 5.7.515 Access denied, sending domain [dominio.pt] does not meet the required authentication level.
The sender’s domain in the 5322.From address doesn’t meet the authentication requirements defined for the sender.
Neste artigo
- O que é o erro 550 5.7.515 e porque acontece
- Quem é afectado — critérios de remetente de alto volume
- Requisitos obrigatórios da Microsoft
- Passo 1 — Verificar o cabeçalho do email rejeitado
- Passo 2 — Configurar o registo SPF
- Passo 3 — Configurar o registo DKIM
- Passo 4 — Publicar o registo DMARC
- Passo 5 — Verificar o alinhamento DMARC
- Verificar se está tudo correcto
- Configuração específica para Microsoft 365
- Erros comuns e como evitá-los
1. O que é o Erro 550 5.7.515 e Porque Acontece
O código 550 5.7.515 é um NDR (Non-Delivery Report) — uma rejeição permanente enviada pelo servidor de destino a indicar que a mensagem não foi aceite e não será tentada novamente. Ao contrário de um erro temporário (4xx), os erros 5xx são definitivos.
Este erro específico foi introduzido pela Microsoft em 2025 como parte de um esforço para reduzir spam e phishing nos serviços de email de consumidor. O Outlook.com passou a exigir que remetentes de alto volume tenham SPF, DKIM e DMARC correctamente configurados — à semelhança do que o Google e o Yahoo já exigem desde 2024.
ℹ O que é o 5322.From (endereço From visível)?
O 5322.From é o endereço que aparece no campo “De:” no cliente de email — o que o utilizador final vê. É diferente do 5321.MailFrom (MAIL FROM do SMTP, também chamado envelope sender ou Return-Path), que é usado pelo SPF. O DMARC valida que o domínio no 5322.From está alinhado com o domínio autenticado pelo SPF e/ou DKIM.
2. Quem é Afectado — Critérios de Remetente de Alto Volume
O erro 550 5.7.515 aplica-se quando ambas as condições seguintes são verdadeiras:
| Condição | Detalhe |
|---|---|
| Volume de envio | 5.000 ou mais mensagens enviadas para serviços Microsoft de email de consumidor (Outlook.com, Hotmail, Live.com, MSN) por dia |
| Consistência de domínio | Todas as mensagens usam o mesmo domínio no endereço 5322.From (o campo “De:” visível ao destinatário) |
Casos típicos afectados em Portugal:
| Tipo de remetente | Exemplos | Afectado? |
|---|---|---|
| Plataformas de marketing por email | Newsletter, campanhas promocionais, e-commerce | Sim — quando envia para listas com muitos endereços Hotmail/Outlook.com |
| Sistemas transaccionais | Confirmações de encomenda, facturas, notificações automáticas | Sim — se o volume diário atingir o limiar |
| Serviços de helpdesk/tickets | Notificações automáticas de tickets, updates de estado | Depende do volume |
| Email corporativo normal | Utilizadores individuais a enviar email do dia-a-dia | Geralmente não — volume abaixo do limiar |
⚠ Configurar mesmo sem atingir o limiar — uma boa prática
Mesmo que o volume actual de envio esteja abaixo dos 5.000 emails/dia, configurar SPF, DKIM e DMARC é uma boa prática de segurança e melhora a deliverability geral. O limiar pode ser atingido por picos de envio pontuais, e outros serviços de email (Gmail, Yahoo) têm requisitos semelhantes.
3. Requisitos Obrigatórios da Microsoft
Para remetentes de alto volume, o Outlook.com exige que todos os seguintes requisitos sejam cumpridos em simultâneo:
| # | Requisito | O que significa |
|---|---|---|
| 1 | SPF válido e a passar | Registo SPF publicado no DNS que inclua o servidor de envio. A verificação SPF deve resultar em pass. |
| 2 | DKIM válido e a passar | Registo DKIM publicado no DNS. As mensagens devem ser assinadas com DKIM e a verificação deve resultar em pass. |
| 3 | DMARC publicado | Registo DMARC em _dmarc.dominio.pt — mínimo aceitável: v=DMARC1; p=none. |
| 4 | Alinhamento DMARC | O domínio no 5322.From (campo “De:” visível) deve estar alinhado com o domínio autenticado pelo SPF e/ou DKIM. Pelo menos um dos dois deve alinhar. |
4. Passo 1 — Verificar o Cabeçalho do Email Rejeitado
Antes de fazer qualquer alteração, verificar os cabeçalhos do NDR para perceber exactamente o que está a falhar — se é o SPF, o DKIM, o DMARC ou o alinhamento.
Como ver os cabeçalhos no Outlook
|
1
|
Abrir o email NDR (a mensagem de erro devolvida ao remetente) |
|
2
|
No Outlook: clicar em Ficheiro → Propriedades → Cabeçalhos de internet. No Outlook Web: clicar nos três pontos (···) → Ver detalhes da mensagem. |
|
3
|
Copiar o conteúdo dos cabeçalhos e colar no Message Header Analyzer para leitura simplificada |
|
4
|
Procurar o cabeçalho Authentication-Results — identifica o resultado de cada verificação |
Exemplo de cabeçalho Authentication-Results com falhas
Authentication-Results: outlook.com;
dkim=fail (bad signature) header.d=empresa.pt;
spf=pass (domain of empresa.pt) smtp.mailfrom=empresa.pt;
dmarc=fail action=none header.from=empresa.pt
# Exemplo de cabeçalho com SPF a falhar
Authentication-Results: outlook.com;
dkim=pass header.d=empresa.pt;
spf=fail (IP não autorizado) smtp.mailfrom=empresa.pt;
dmarc=fail action=none header.from=empresa.pt
# Exemplo de cabeçalho com DMARC a falhar por alinhamento
Authentication-Results: outlook.com;
dkim=pass header.d=sendgrid.net; ← domínio diferente do From!
spf=pass smtp.mailfrom=sendgrid.net; ← domínio diferente do From!
dmarc=fail action=none header.from=empresa.pt
ℹ Ferramenta para analisar cabeçalhos
O kbase.pt disponibiliza o Message Header Analyzer — uma ferramenta gratuita que analisa cabeçalhos de email e identifica visualmente os resultados SPF, DKIM e DMARC, o percurso da mensagem e os atrasos. Colar o cabeçalho completo na ferramenta para diagnóstico imediato.
5. Passo 2 — Configurar o Registo SPF
O SPF (Sender Policy Framework) é um registo TXT no DNS que declara quais os servidores autorizados a enviar email em nome do domínio. O servidor de destino verifica se o IP que enviou a mensagem consta nessa lista.
Verificar se já existe um registo SPF
nslookup -type=TXT empresa.pt
# Linux / macOS
dig TXT empresa.pt +short
# Procurar no output uma linha que começa com “v=spf1”
# Exemplo de resultado com SPF existente:
“v=spf1 include:spf.protection.outlook.com -all”
Exemplos de registo SPF por cenário
| Plataforma de envio | Registo SPF a criar no DNS |
|---|---|
| Microsoft 365 / Exchange Online | v=spf1 include:spf.protection.outlook.com -all |
| Google Workspace | v=spf1 include:_spf.google.com -all |
| SendGrid | v=spf1 include:sendgrid.net -all |
| Mailchimp | v=spf1 include:servers.mcsv.net -all |
| Servidor próprio (IP fixo) | v=spf1 ip4:203.0.113.10 -all |
| Múltiplas plataformas | v=spf1 include:spf.protection.outlook.com include:sendgrid.net ip4:203.0.113.10 -all |
Como criar o registo no DNS: aceder ao painel de gestão DNS do domínio (registo .pt via DNS.PT ou através do operador — MEO Empresas, NOS, Claranet) e criar um registo TXT na raiz do domínio (@ ou o nome do domínio em branco) com o valor SPF correspondente.
⚠ Só pode existir um registo SPF por domínio
Ter dois registos TXT com v=spf1 no mesmo domínio causa falhas SPF. Se já existe um registo SPF, editar o existente adicionando os novos include — não criar um segundo registo. Usar a diretiva ~all (softfail) durante testes e mudar para -all (hardfail) quando tudo estiver validado.
6. Passo 3 — Configurar o Registo DKIM
O DKIM (DomainKeys Identified Mail) adiciona uma assinatura criptográfica a cada mensagem enviada. O servidor de destino usa a chave pública publicada no DNS para verificar que a mensagem não foi alterada em trânsito e que foi efectivamente enviada pelo detentor do domínio.
Configurar DKIM no Microsoft 365
|
1
|
Aceder ao Microsoft Defender → Email & Collaboration → Policies & Rules → Threat Policies → DKIM (ou via security.microsoft.com directamente) |
|
2
|
Seleccionar o domínio e clicar em Create DKIM keys — o M365 gera dois registos CNAME para publicar no DNS |
|
3
|
Publicar os dois registos CNAME no DNS do domínio com os valores fornecidos — o formato é semelhante a:selector1._domainkey.empresa.pt → selector1-empresa-pt._domainkey.empresa.onmicrosoft.com |
|
4
|
Após propagação DNS (aguardar 15-60 min), voltar ao Defender e clicar em Enable para activar a assinatura DKIM no domínio |
Verificar o DKIM via PowerShell (M365)
Connect-ExchangeOnline
# Ver o estado do DKIM para todos os domínios
Get-DkimSigningConfig | Select-Object Domain, Enabled, Status
# Activar o DKIM para um domínio específico
Set-DkimSigningConfig -Identity empresa.pt -Enabled $true
# Verificar os registos CNAME publicados no DNS
nslookup -type=CNAME selector1._domainkey.empresa.pt
7. Passo 4 — Publicar o Registo DMARC
O DMARC (Domain-based Message Authentication, Reporting and Conformance) une o SPF e o DKIM numa política: o que deve acontecer às mensagens que falhem a autenticação? O registo DMARC é publicado no DNS como um TXT em _dmarc.dominio.pt.
Registo DMARC mínimo — para cumprir o requisito da Microsoft
# Nome: _dmarc.empresa.pt (ou _dmarc em hosts que já incluem o domínio)
# Tipo: TXT
# Valor:
v=DMARC1; p=none; rua=mailto:[email protected]
# Explicação dos campos:
# v=DMARC1 → versão do DMARC
# p=none → política: não fazer nada às mensagens que falhem (só monitorização)
# rua=mailto: → endereço para receber relatórios agregados diários (opcional mas recomendado)
Evolução recomendada da política DMARC
| Fase | Política | O que faz | Quando usar |
|---|---|---|---|
| 1 — Monitorização | p=none | Entrega todas as mensagens, envia relatórios. Não bloqueia nada. | Fase inicial — começar sempre aqui. Já cumpre o requisito Microsoft. |
| 2 — Quarentena | p=quarantine | Mensagens que falham vão para spam/junk do destinatário. | Após 2-4 semanas a analisar os relatórios e confirmar que SPF/DKIM estão correctos. |
| 3 — Rejeição | p=reject | Mensagens que falham são rejeitadas na entrega. Protecção máxima contra spoofing. | Após confirmação de que todos os fluxos legítimos passam. Destino final recomendado. |
⚠ Não saltar directamente para p=reject
Começar sempre com p=none e analisar os relatórios DMARC durante pelo menos 2 semanas para identificar todos os fluxos de email legítimos do domínio (newsletters de terceiros, sistemas de CRM, plataformas de marketing, etc.). Mudar directamente para p=reject sem esta análise pode bloquear email legítimo.
8. Passo 5 — Verificar o Alinhamento DMARC
O alinhamento DMARC é a causa mais comum de falha mesmo quando o SPF e o DKIM individualmente passam. O DMARC exige que o domínio no 5322.From (campo “De:” visível) corresponda ao domínio autenticado pelo SPF ou pelo DKIM.
| Situação | 5322.From (De:) | SPF / DKIM autenticado com | DMARC |
|---|---|---|---|
| Alinhado ✅ | [email protected] | empresa.pt | Pass |
| Não alinhado ❌ | [email protected] | sendgrid.net | Fail |
| Alinhado via DKIM ✅ | [email protected] | DKIM: empresa.pt (alinhado) + SPF: sendgrid.net (não alinhado) | Pass (basta um) |
Solução quando se usa uma plataforma de envio externa (SendGrid, Mailchimp, etc.) e o DMARC falha por falta de alinhamento:
| Solução | Como implementar |
|---|---|
| Configurar DKIM personalizado na plataforma | No painel do SendGrid/Mailchimp, activar “Custom Domain Authentication” e publicar os registos CNAME/TXT fornecidos no DNS do teu domínio. A plataforma passa a assinar com o teu domínio em vez do próprio. |
| Configurar SPF com o Return-Path do domínio próprio | Algumas plataformas permitem definir um Return-Path personalizado com o teu domínio — o servidor de envio usa [email protected] em vez de [email protected]. |
9. Verificar se Está Tudo Correcto
Após publicar os registos DNS (aguardar propagação de 15 min a 24 h), validar com as ferramentas seguintes:
| O que verificar | Ferramenta | Resultado esperado |
|---|---|---|
| SPF, DKIM e DMARC | MXToolbox Email Header Analyzer | SPF: pass, DKIM: pass, DMARC: pass |
| Registo SPF | MXToolbox SPF Check | SPF record found, sem erros de sintaxe |
| Registo DKIM | MXToolbox DKIM Check | DKIM record found (inserir selector + domínio) |
| Registo DMARC | MXToolbox DMARC Check | DMARC record found com política válida |
| Teste de entrega real | mail-tester.com | Pontuação 9-10/10, SPF/DKIM/DMARC todos verdes |
Verificação rápida via PowerShell
Resolve-DnsName -Name empresa.pt -Type TXT | Where-Object { $_.Strings -like “v=spf1*” }
# Verificar DMARC
Resolve-DnsName -Name _dmarc.empresa.pt -Type TXT
# Verificar DKIM (substituir “selector1” pelo selector real)
Resolve-DnsName -Name selector1._domainkey.empresa.pt -Type CNAME
10. Configuração Específica para Microsoft 365
Se o servidor de envio é o Microsoft 365 / Exchange Online, o processo de activação do DKIM é feito directamente no portal de segurança. O SPF para M365 já inclui os servidores Microsoft por defeito quando o domínio é adicionado.
# 1. Ligar ao Exchange Online
Install-Module -Name ExchangeOnlineManagement -Force
Connect-ExchangeOnline -UserPrincipalName [email protected]
# 2. Ver o estado actual do DKIM
Get-DkimSigningConfig | Format-Table Domain, Enabled, Status, Selector1CNAME, Selector2CNAME
# 3. Se Status = “CnameMissing”, publicar os registos CNAME no DNS
# O output do comando acima mostra os valores exactos a publicar
# 4. Após publicar os registos DNS, activar o DKIM
Set-DkimSigningConfig -Identity empresa.pt -Enabled $true
# 5. Confirmar que ficou activo
Get-DkimSigningConfig -Identity empresa.pt | Select-Object Domain, Enabled, Status
✓ Resumo dos registos DNS a criar para M365
v=spf1 include:spf.protection.outlook.com -all
# DKIM — dois registos CNAME (valores exactos obtidos no portal)
selector1._domainkey.empresa.pt → selector1-empresa-pt._domainkey.empresa.onmicrosoft.com
selector2._domainkey.empresa.pt → selector2-empresa-pt._domainkey.empresa.onmicrosoft.com
# DMARC — registo TXT em _dmarc.empresa.pt
v=DMARC1; p=none; rua=mailto:[email protected]
11. Erros Comuns e Como Evitá-los
| Erro | Causa | Solução |
|---|---|---|
| Dois registos SPF no DNS | Criou um novo registo em vez de editar o existente | Apagar um dos dois e consolidar tudo num único registo TXT com v=spf1 |
| DKIM activo no M365 mas CNAME não publicado | Activou o DKIM antes de publicar os CNAME no DNS | Publicar os registos CNAME primeiro, aguardar propagação, depois activar |
| DMARC a falhar com SPF e DKIM a passar | Problema de alinhamento — domínio do From diferente do domínio autenticado | Activar DKIM personalizado na plataforma de envio externa para alinhar com o domínio do From |
| SPF com mais de 10 lookups DNS | Muitos include: no registo SPF que expandem para mais de 10 consultas DNS |
Usar SPF flattening para reduzir para IPs directos, ou remover plataformas que já não enviam email |
| DMARC publicado mas sem monitorização | Publicou p=none sem configurar rua= |
Adicionar rua=mailto:[email protected] para receber relatórios e perceber o que está a falhar antes de apertar a política |
Artigos relacionados no kbase.pt
- Message Header Analyzer: Como Analisar Cabeçalhos de Email — Guia Completo
- Erros de Email POP3, IMAP e SMTP: Causas, Diagnóstico e Resolução
- Autodiscover no Office 365 e Hosted Exchange: Configuração DNS Passo a Passo
- DNS: Guia Completo para Sysadmins em Portugal — Registos, Ferramentas e Diagnóstico
