550 5.7.515 no Outlook: o que significa e como corrigir?
Mandou campanha pra Hotmail e Outlook.com e a ferramenta devolveu 550 5.7.515. Parece erro de servidor. A busca manda olhar blocklist, o painel do Exchange e uma ferramenta de teste da Microsoft. Nenhuma dessas portas resolve esse bounce.
A resposta curta é esta. A Microsoft recusou o email de vez. O domínio do From manda bastante coisa, e o Outlook.com não aceitou a identidade. Desde 5 de maio de 2025, se o domínio manda 5.000 emails ou mais num dia pra Outlook.com, Hotmail, Live ou MSN, ele precisa de três registros funcionando: SPF, DKIM e DMARC. Os dois primeiros têm que passar. O DMARC também, e o nome que ele checa tem que ser o From que a pessoa vê. O conserto fica nesses registros, não num botão do Microsoft 365. Este guia cobre o que o bounce diz, a diferença pro 5.7.1 e pro erro de senha, as três causas mais comuns, e o tempo que o DNS leva pra valer.
O que o bounce 550 5.7.515 significa
A linha completa, no artigo de suporte da Microsoft, é esta:
550 5.7.515 Access denied, sending domain example.com does not meet
the required authentication level.550 quer dizer que o email acabou. O servidor não tenta de novo. 5.7.515 é o número da Microsoft pra essa regra. O domínio na linha é o From que a pessoa vê, não necessariamente o endereço escondido de bounce. O email não chegou em caixa nenhuma. Não foi pro lixo. O Outlook.com recusou ainda no caminho.
Esse aviso fica no log da ferramenta que envia. Quem vê é quem mandou. A pessoa no Outlook.com nunca viu o email.
Copia a linha inteira antes de mexer em qualquer registro. O domínio escrito ali é o que você checa no próximo passo.
Por que o Outlook bloqueia com o código 550 5.7.515
A Microsoft contou a regra em 2 de abril de 2025 no blog da Tech Community. O bounce duro pra quem manda muito começou em 5 de maio de 2025. No começo o texto falava em mandar pro lixo e recusar depois. No dia 29 de abril eles inverteram. O 550 5.7.515 valeu na data original.
Quem manda muito, no texto da Microsoft, é o domínio do From que dispara 5.000 emails ou mais num dia pra caixa pessoal de Outlook, Hotmail, Live ou MSN. Passou disso, ela quer que todo email seguinte daquele From cumpra isto:
- SPF passando no domínio escondido de envio.
- DKIM passando, com assinatura de verdade.
- Um registro DMARC no domínio do From.
p=nonejá serve. - DMARC passando porque o SPF bate, o DKIM bate, ou os dois.
Isso é mais duro que a regra básica do Gmail, que aceita SPF ou DKIM. O post dos requisitos do Gmail e do Yahoo cobre o outro lado. A Microsoft quer os dois passando, e o DMARC batendo com o From.
A regra escrita é pra caixa pessoal. Conta de trabalho no Microsoft 365 tem filtro próprio. O email pode morrer no Hotmail e entrar numa empresa, ou o contrário. O conserto do lado de quem envia é o mesmo: os registros no domínio do From. SaaS e email de recibo passam de 5.000 num dia só de comprovante ou reset de senha.
550 5.7.515 vs 550 5.7.1 vs falha de autenticação SMTP
Três códigos diferentes. Três consertos diferentes. A tabela é o atalho:
| Código | O que é | Onde está o conserto |
|---|---|---|
550 5.7.515 |
Outlook.com recusou um envio alto no teste de confiança | SPF, DKIM e DMARC batendo no domínio do From |
550 5.7.1 |
Um grupo misturado de bounce duro | O texto depois do código |
535 / 5.7.3 |
A ferramenta não conseguiu entrar | Host, porta e senha, antes de qualquer DNS |
O 550 5.7.1 é um grupo, não um diagnóstico. Ele já cita o 5.7.515 como primo da Microsoft. Este post é esse primo, escrito direito.
Erro de senha SMTP acontece quando a ferramenta não consegue entrar no servidor de envio. O 5.7.515 acontece depois, quando o email já saiu e o Outlook.com recusou o From. Trocar a senha do SMTP não mexe nisso.
O caminho de cada um começa no texto depois do código. Se a linha não tem 5.7.515 e authentication level, esta página não é o mapa.
As três causas, em ordem
Quando o bounce é mesmo 5.7.515, estas três cobrem quase tudo.
1. SPF, DKIM ou DMARC faltando ou falhando
É a causa mais comum em email honesto. Falta um dos três registros no domínio do From. Ou o SPF não lista o computador que saiu. Ou o DKIM está lá, mas o servidor não assina. A Microsoft quer os dois passando, não um.
O DMARC mínimo que o suporte dela aceita é uma linha:
_dmarc.example.com. TXT "v=DMARC1; p=none"p=none já serve pra esse bounce. Um endereço de relatório (rua=) ajuda a ver quem manda no domínio. Não é isso que causa a recusa. Os passos de publicação estão nos guias de SPF, DKIM e DMARC. O guia de falha de SPF cobre o caso em que o registro existe e o IP não.
Roda o email health check no domínio do From que o bounce escreveu. Os três precisam aparecer. Vermelho aqui já é a causa.
2. O nome do From não bate com o que passou
O SPF pode passar no domínio de bounce da ferramenta. O DKIM pode passar no nome dela. O From que a pessoa lê continua sendo o seu. O DMARC olha esse From. Se os nomes não batem, o DMARC falha e a Microsoft recusa.
Um cabeçalho típico desse caso:
Authentication-Results: outlook.com;
spf=pass (sender IP is 203.0.113.10)
smtp.mailfrom=bounce.esp.example;
dkim=pass header.d=esp.example;
dmarc=fail action=oreject
header.from=seudominio.comOs dois primeiros passam. O terceiro falha. O post sobre DMARC falhando quando o SPF passa caminha essa linha. O conserto é um endereço de bounce no seu domínio, ou uma assinatura DKIM com o seu domínio, ou os dois.
Abre um teste no header analyzer e compara smtp.mailfrom, header.d e header.from. Se os dois primeiros são da ferramenta, o health check pode estar verde e o bounce continuar.
3. Outra ferramenta manda sem os registros do seu domínio
A ferramenta de newsletter, o help desk, o app de recibo: cada um precisa aparecer no SPF e assinar DKIM com o domínio do From. A Microsoft pede isso no artigo de suporte. Um include: que faltou, ou DKIM de domínio próprio desligado no painel, gera exatamente esse 5.7.515 numa fatia da lista.
O recado está no recorte. Email do próprio Microsoft 365 chega. A newsletter da ferramenta nova volta. O From é o mesmo. O caminho de envio não é.
Liga o recurso que a ferramenta chama de domínio de envio. Publica cada registro que ela mostrar. Só então manda de novo por esse caminho.
A correção e como conferi-la
O bounce para quando um email novo passa nos quatro pontos da Microsoft. Mexer no DNS e reenviar o mesmo email não prova nada.
Quem toca a empresa sozinho no Microsoft 365 e quem cuida da conta inteira fazem o mesmo trabalho. Não existe botão 5.7.515 no painel do Exchange. DKIM de domínio próprio no Microsoft 365 ainda pede os registros selector1 e selector2 no DNS. Se um conector troca o From pra um domínio sem esses registros, a conta inteira pode bouncear. A unidade é o domínio do From, não a conta do Microsoft 365.
O Remote Connectivity Analyzer testa se o Outlook abre. Ele não lê esse bounce. O que vale é o health check mais um cabeçalho de um teste numa caixa sua.
Manda o teste depois da espera. No cabeçalho, o alvo é spf=pass, dkim=pass e dmarc=pass no From que o bounce escreveu.
Quanto tempo o erro leva para sumir depois do DNS
A internet guarda a resposta antiga até acabar o tempo do registro. Tempo de 3600 segundos é até uma hora. Tempo de 86400 é até um dia. Ver o valor novo no notebook não quer dizer que a Microsoft já viu a mesma coisa.
O 5.7.515 não “limpa”. Ele só para de aparecer. O email que falhou continua falho. Só o próximo envio, depois da espera, responde.
Se o bounce voltar depois de um dia, e o cabeçalho novo estiver passando, outro caminho ainda está quebrado. Ferramenta sem o include. Assinatura que o servidor não coloca. Ou um From que não é o domínio que você editou.
O que este erro não é
Três buscas comuns levam pro conserto errado.
Blocklist da Microsoft. IP listado, ou nota ruim no Outlook, muitas vezes manda pro lixo. Ou usa outro código 5.7.x. O post emails indo pro spam no Outlook e não no Gmail cobre isso. O hub de diagnóstico cobre quando várias caixas falham ao mesmo tempo. O 5.7.515 é teste de confiança. Ficar o dia inteiro em blocklist nesse bounce não mexe no aviso.
Painel do Exchange. Não existe regra de fluxo com esse número. Procurar 5.7.515 ali volta vazio porque a regra mora no Outlook.com, do lado de quem recebe.
Remote Connectivity Analyzer. Ferramenta certa pra “o Outlook não abre”. Ferramenta errada pra esse bounce.
Se o aviso for outro código, trata aquele código. Esta página só mapeia o 5.7.515.
O custo em escala
Um health check num domínio responde a pergunta de hoje. Ele não conta que uma ferramenta nova entrou na terça sem o include. Nem que a chave de DKIM morreu. Nem que o volume pro Outlook.com passou de 5.000 num disparo de recibo. O 5.7.515 aparece no painel como um pedaço de Hotmail e some da conversa até a campanha seguinte.
Por isso a vigilância é automática. A LitInboxes checa registros, blocklist e reputação em cada domínio acompanhado a cada seis horas. Guarda histórico com data, pra cruzar um pico de bounce com o dia em que o registro mudou. Avisa por email, Slack, Discord ou webhook. Tem um passo a passo se quiser ver isso num domínio de verdade.
Checklist
- Copia o bounce inteiro e confirma
550 5.7.515mais o domínio do From. - Roda o email health check nesse domínio. Publica o que faltar.
- Manda um teste e lê o
Authentication-Results. Quer SPF pass, DKIM pass e DMARC pass com o nome batendo. - Se o DNS está verde e o DMARC falha, arruma o nome na ferramenta que envia.
- Espera o tempo do registro antigo. Aí manda um email novo. O bounce velho fica.
- Se o código voltar num caminho só, esse caminho ainda está fora do SPF ou do DKIM.
Como corrigir um bounce 550 5.7.515 no Outlook
- Copie o bounce inteiro, não só o códigoPegue todas as linhas no log da ferramenta ou no aviso de bounce. A Microsoft escreve o domínio do From que ela checou. É esse domínio que você vai arrumar.
- Confirme que é 5.7.515, não outro 550O texto precisa ter Access denied e required authentication level. Outro 550, inclusive o 5.7.1, pede outro conserto. O post do 5.7.1 cobre esse grupo.
- Cheque o domínio do FromO domínio que a pessoa lê no From precisa de três registros: SPF, DKIM e DMARC. O email health check mostra os três de uma vez. Os guias de SPF, DKIM e DMARC mostram como publicar.
- Mande um teste e veja se o nome bateEnvie um teste pra uma caixa sua. Abra o Authentication-Results no header analyzer. A Microsoft quer SPF pass, DKIM pass e DMARC pass. O nome que o DMARC checa tem que ser o do From.
- Arrume a ferramenta ou o registro que falhaSe o SPF ou o DKIM passam no domínio da ferramenta, e não no seu, ligue o domínio de envio no painel dela e publique o que ela pedir. Nome que não bate é a causa mais comum depois de registro faltando.
- Espere e mande um teste novoCabeçalho de ontem não prova registro de hoje. Espere o tempo do registro antigo acabar, muitas vezes uma hora, às vezes um dia. Aí manda um email novo. O bounce velho não muda.
Perguntas frequentes
Quanto tempo o 550 5.7.515 leva pra sumir depois de mexer no DNS?
Ele para no primeiro email novo depois que o tempo do registro antigo acaba. Isso vai de alguns minutos até um dia. Mandar o mesmo email de novo na hora costuma devolver o mesmo bounce.
Qual a diferença entre 550 5.7.515 e 550 5.7.1?
O 5.7.515 é o código da Microsoft pra quem manda muito e falhou no teste de confiança do Outlook.com. O 5.7.1 é um grupo misturado de bounce duro. Dois 5.7.1 podem pedir consertos opostos. O 5.7.515 já diz o que falhou.
O 550 5.7.515 é erro de senha SMTP ou blocklist?
Não. Erro de login aparece como 535 ou 5.7.3, antes do email sair. Blocklist da Microsoft costuma ir pro lixo, ou virar outro 5.7.x. O 5.7.515 é teste de confiança no domínio do From, no DNS.
Essa regra vale pro Microsoft 365 da empresa e pra quem manda menos de 5.000 emails?
A Microsoft escreveu a regra pro Outlook.com, Hotmail, Live e MSN, as caixas pessoais, e pro domínio do From que passou de 5.000 emails num dia. Conta de trabalho filtra sozinha. Abaixo dessa linha ela não promete bounce, mas os mesmos três registros ainda são o setup seguro.