Como diagnosticar o 550 5.7.515 do Outlook.com em 2026? Lista de verificação para desenvolvedores

A Microsoft define remetentes de alto volume como aqueles que enviam 5.000 ou mais mensagens por dia para endereços de consumidores do Outlook.com, conforme sua política para remetentes de alto volume. Se você recebeu o erro 550 5.7.515, não troque primeiro o endereço de teste: confirme se a regra se aplica ao seu envio e investigue SPF, DKIM, DMARC e o alinhamento do domínio. Uma caixa de entrada de teste pode mostrar o que chegou, mas não corrige a autenticação do seu domínio de envio.

Adequado para: desenvolvedores que mantêm o domínio de envio do próprio produto e precisam localizar falhas de autenticação.
Também é para: QA que valida mensagens em homologação e operações que configuram serviços de envio de terceiros.

Última atualização: 22 de outubro de 2026. As informações sobre o erro e a política foram conferidas nas páginas oficiais da Microsoft sobre o 550 5.7.515 e sobre remetentes de alto volume. Confira essas páginas novamente antes de alterar uma política de envio: regras e orientações podem mudar.

Primeiro, classifique a falha pela resposta recebida

O código 550 5.7.515 é uma rejeição associada à autenticação exigida pela Microsoft para remetentes de alto volume. A página oficial descreve o erro como um problema relacionado ao domínio do remetente não atender aos requisitos aplicáveis. Isso não significa, por si só, que a mensagem foi aceita e direcionada à pasta de spam. Também não prova que o endereço de teste está incorreto. A explicação oficial do erro é o ponto de partida para interpretar o NDR.

A distinção muda o caminho do diagnóstico:

• Rejeição SMTP: o servidor informa que não aceitou a mensagem. Guarde a resposta SMTP e o NDR completo.
• Mensagem aceita, mas ausente na caixa de entrada: investigue spam, regras, quarentena, atraso ou outro problema posterior à aceitação.
• Nenhuma resposta conclusiva: consulte os registros do serviço de envio e o estado da transação. “Enviado” no painel do provedor pode significar apenas que ele aceitou a solicitação do seu sistema.

Como diferenciar uma rejeição do Outlook.com de uma mensagem que foi para o spam? Procure o resultado SMTP e o NDR, não apenas a ausência da mensagem na interface do destinatário. Uma rejeição com 550 5.7.515 aponta para a etapa de aceitação e inclui uma explicação específica da Microsoft. Uma mensagem que foi aceita, mas não aparece na caixa de entrada, exige outro diagnóstico. Se você não tiver a resposta SMTP, peça ao serviço de envio o evento correspondente e seu resultado final.

Antes de alterar DNS, registre a mensagem de erro inteira, o destinatário e a hora do envio. Salve também os cabeçalhos completos se o e-mail tiver sido aceito por algum destinatário de teste. Anote qual serviço enviou a mensagem e qual endereço aparece no campo “De”. Esses dados permitem separar problemas no domínio da aplicação, na plataforma de envio e no destino.

Confirme o escopo antes de mexer no DNS

A exigência de remetentes de alto volume não deve ser transformada numa afirmação de que toda conta que envia para Outlook.com precisa atender ao mesmo critério de volume. A Microsoft descreve a regra para envios de alto volume a endereços de consumidores Outlook.com. Por isso, avalie em conjunto o destino, o volume relevante e o domínio associado ao e-mail rejeitado. Não tire uma conclusão só porque sua aplicação usa uma plataforma conhecida de envio ou porque o painel dela mostra uma autenticação “ativa”.

A política da Microsoft usa 5.000 mensagens por dia como referência para definir remetentes de alto volume. Esse número se refere às mensagens destinadas a contas de consumidores do Outlook.com conforme a descrição oficial, não a qualquer mensagem enviada pela sua empresa para qualquer plataforma. Se o seu tráfego é distribuído entre vários destinos, não assuma que o volume global seja automaticamente a contagem que determina o enquadramento. Examine os dados e a definição indicados pela Microsoft.

Use a resposta de erro como evidência adicional. Confirme se o NDR menciona o domínio esperado e se o envio foi realmente direcionado a um destinatário Outlook.com, Hotmail ou Live.com. Esses domínios ajudam a identificar o destino, mas o domínio do destinatário não substitui a investigação do domínio de envio.

No registro de diagnóstico, diferencie estes elementos:

• Destino: serviço que recebeu a tentativa de entrega.
• Domínio visível do remetente: domínio do endereço exibido no cabeçalho From.
• Domínio do envelope: domínio usado na comunicação SMTP para o remetente do envelope.
• Domínio da assinatura DKIM: domínio informado no parâmetro d= da assinatura.

A descrição da política e a mensagem de erro devem orientar a avaliação de aplicabilidade. Se o caso não se encaixar claramente, evite concluir que o volume é a causa apenas porque o código apareceu: reúna o NDR e os dados de autenticação antes de alterar a configuração.

SPF, DKIM e DMARC respondem a perguntas diferentes

Uma checagem DNS isolada não demonstra que a mensagem foi autenticada corretamente. O registro pode existir e ainda assim a mensagem sair por um serviço que não está autorizado, não ter assinatura DKIM válida ou falhar no alinhamento necessário para DMARC.

A Microsoft explica os mecanismos de autenticação em sua documentação sobre SPF, DKIM e DMARC. Para interpretar o resultado, examine os cabeçalhos da mensagem e compare-os com o caminho real usado pelo seu sistema.

O SPF valida a autorização do servidor para o domínio associado ao remetente do envelope. O DKIM verifica uma assinatura criptográfica da mensagem e identifica o domínio que a assinou. O DMARC avalia os resultados de SPF e DKIM em relação ao domínio visível para o destinatário. A documentação da Microsoft sobre cabeçalhos ajuda a localizar campos de autenticação e remetente.

Por que SPF ou DKIM podem passar enquanto o alinhamento DMARC falha? Porque “passou” e “está alinhado” não são a mesma condição. Por exemplo, o serviço pode autenticar um domínio de envelope diferente do domínio visível no From; nesse caso, o resultado SPF pode ser positivo, mas não alinhado. A assinatura DKIM também pode ser válida e usar um domínio d= que não se alinha ao From. A regra e os modos de alinhamento do DMARC são definidos na especificação RFC 9989. Consulte o resultado DMARC e os domínios efetivamente usados na mensagem, em vez de confiar apenas na presença de registros DNS.

Etapa de diagnóstico: acompanhe os domínios de ponta a ponta

Quando uma plataforma de terceiros envia em nome do seu produto, compare a configuração dela com os cabeçalhos da mensagem real. O status “autenticado” no painel é um indício, mas não demonstra sozinho que a mensagem de homologação usou o domínio esperado em todas as etapas.

1. Identifique o endereço visível. Copie o domínio do cabeçalho From da mensagem gerada pelo ambiente de teste. Não use como substituto o endereço de login da plataforma de envio.
2. Encontre o remetente do envelope. Consulte os dados da transação SMTP ou os cabeçalhos disponíveis. O 5321.MailFrom pode usar um domínio diferente do 5322.From.
3. Verifique o resultado SPF da mensagem. Veja qual domínio foi avaliado e se o resultado foi pass, fail, softfail ou outro valor. Um registro SPF publicado para um domínio não prova que ele foi o domínio consultado.
4. Inspecione a assinatura DKIM. Confirme o resultado da validação e o domínio d=. Compare esse domínio com o From, levando em conta a política de alinhamento DMARC configurada.
5. Leia o resultado DMARC. Procure o resultado e o domínio avaliados. Registre se a passagem ocorreu por SPF alinhado, DKIM alinhado ou ambos.
6. Compare com o DNS autoritativo. Confira os registros usados pelo domínio e pelas instruções do serviço. Procure erros de digitação, registros publicados no domínio errado ou configurações antigas que continuam sendo usadas.
7. Revise a autorização do terceiro. Se um fornecedor envia para você, confirme que a configuração de domínio foi concluída para a conta, o fluxo e o ambiente corretos. Não copie registros de outro domínio ou de uma configuração de produção sem verificar se correspondem ao ambiente de teste.

Um resultado SPF positivo para o domínio do envelope e uma assinatura DKIM válida são sinais úteis, mas ainda precisam ser interpretados em relação ao domínio do From. A autenticação DMARC não é uma soma de três caixas verdes: ela depende dos resultados e do alinhamento. Use a RFC e a documentação de cabeçalhos da Microsoft para resolver divergências, em vez de inferir a causa pela tela de configuração.

Lista de verificação antes de considerar o reparo concluído

Use esta lista para registrar evidências da sua própria aplicação. Cada item deve corresponder a uma mensagem de teste identificável.

• [ ] Salvei o NDR completo, incluindo o código 550 5.7.515 e o texto explicativo.
• [ ] Confirmei que o destinatário era de um serviço de consumidor Outlook.com, Hotmail ou Live.com.
• [ ] Registrei o domínio do 5322.From e o domínio do 5321.MailFrom.
• [ ] Verifiquei nos cabeçalhos ou nos dados do envio qual servidor tentou entregar a mensagem.
• [ ] Conferi o resultado SPF e o domínio que foi avaliado.
• [ ] Conferi o resultado DKIM e o domínio d= da assinatura.
• [ ] Li o resultado DMARC e confirmei se SPF ou DKIM passou com alinhamento ao From.
• [ ] Comparei a configuração do terceiro com os registros DNS realmente publicados para o domínio usado.
• [ ] Repeti o envio depois da alteração e salvei a nova resposta SMTP ou o NDR.
• [ ] Separei evidências confirmadas de hipóteses ainda não testadas.

Não marque uma etapa como concluída só porque o DNS parece correto no painel administrativo. A evidência mais útil é a que corresponde à mensagem que foi enviada: cabeçalhos, resposta SMTP e resultado registrado pelo serviço. Se a plataforma não expuser cabeçalhos para uma mensagem rejeitada, registre essa limitação e use os eventos de entrega que ela disponibiliza. Não invente um resultado de autenticação que não foi observado.

Valide a alteração com um destinatário controlado

Como verificar se o e-mail de teste deixou de ser recusado depois da correção? Envie uma mensagem controlada do ambiente de teste para um destinatário Outlook.com adequado e acompanhe a transação até obter o resultado. Registre o horário, o destinatário usado, o identificador da mensagem, a resposta SMTP e, se houver entrega, os cabeçalhos completos. A pergunta não é apenas se a mensagem apareceu: primeiro confirme se a rejeição deixou de ocorrer.

Mantenha o teste limitado ao seu próprio produto. Use uma mensagem de validação que represente o fluxo real, mas evite dados pessoais de clientes ou colegas. Para uma verificação de registro ou redefinição de senha, use dados fictícios que não permitam acesso a uma conta real. Guarde o mínimo de informação necessário para reproduzir o caso.

Uma caixa controlada pode ajudar a inspecionar corpo, assunto, links e cabeçalhos recebidos. Porém, ela não replica necessariamente a decisão de aceitação de Outlook.com e não valida a autenticação de um domínio por conta própria. Um endereço alternativo ou uma caixa de teste de outro destino pode confirmar que a aplicação gerou uma mensagem, mas não prova que a Microsoft aceitará a mesma mensagem.

Separe o resultado em três estados:

• Ainda recusada: guarde o NDR atualizado e retorne ao domínio e ao mecanismo que falhou.
• Aceita, mas não encontrada na caixa principal: verifique spam, regras e demais pastas antes de concluir que houve rejeição.
• Aceita e recebida: inspecione os cabeçalhos e salve os resultados de autenticação; essa mensagem confirma o teste observado, não uma garantia universal de entrega.

Se sua aplicação usa mais de uma rota de envio, valide cada uma separadamente. Uma mensagem de redefinição pode sair por uma plataforma diferente da mensagem de boas-vindas. A mudança na configuração de um fluxo não comprova que os demais usam o mesmo 5321.MailFrom, a mesma assinatura DKIM ou o mesmo alinhamento.

Amplie a regressão de acordo com as evidências

Uma entrega bem-sucedida é evidência de que aquele envio específico foi aceito e recebido. Não é uma promessa de que todas as mensagens, destinatários e rotas funcionarão da mesma forma. Decida a abrangência da regressão considerando o resultado da nova tentativa, os cabeçalhos disponíveis e os destinos envolvidos.

Se o 550 5.7.515 reaparecer, não altere o endereço de teste como se isso corrigisse o domínio. Compare a resposta nova com a anterior. Verifique se o remetente do envelope ou o domínio DKIM mudou entre tentativas e se o fluxo de homologação usa a configuração que você corrigiu.

Se a mensagem for aceita, mas a autenticação indicar falha ou ausência de alinhamento, mantenha o caso em aberto. Registre qual mecanismo passou, qual falhou e que evidência falta. Se SPF, DKIM e DMARC apresentarem resultados coerentes na mensagem observada, faça regressão nos outros fluxos de e-mail do produto que usam domínios ou serviços de envio diferentes.

Guarde três categorias separadas no relatório de QA ou no chamado de operações:

1. Alterações aplicadas: registros DNS, parâmetros do serviço e ambiente afetado.
2. Evidências verificadas: NDR, resposta SMTP, cabeçalhos e resultados de autenticação.
3. Pontos sem confirmação: destinos não testados, ausência de cabeçalhos ou resultados que não podem ser reproduzidos.

Essa separação impede que uma única mensagem recebida vire uma alegação de entrega garantida. Também torna a próxima investigação mais rápida, porque a equipe sabe qual hipótese já foi testada e qual continua pendente.

Depois de confirmar o domínio de envio, você pode usar o EmailPut como uma opção de destinatário controlado para inspecionar o conteúdo que sua aplicação realmente envia. Trate esse teste como uma verificação complementar: ele pode ajudar a revisar a mensagem recebida, mas não substitui SPF, DKIM, DMARC nem explica sozinho uma rejeição da Microsoft. Para o 550 5.7.515, a evidência decisiva continua sendo a resposta do destino e a autenticação observada na rota de envio.