Entenda as respostas 451 4.7.500, 4.7.650, RP-001 e 550 5.7.515 da Microsoft, distinga um incidente do Outlook de um problema de reputação e saiba o que evitar.
Um adiamento da Microsoft é uma recusa SMTP temporária, uma resposta que começa com 4, que um servidor do Outlook.com ou do Microsoft 365 envia quando não vai aceitar a sua mensagem naquele momento. O seu servidor deve guardá-la e tentar de novo. O mais conhecido é 451 4.7.500 Server busy. Please try again later, e o mesmo código pode significar “os seus envios parecem suspeitos” ou “a Microsoft está num dia ruim”.
Em 4 de setembro de 2026, era o segundo caso, e pelo menos um operador experiente passou a manhã investigando o primeiro. Veja como diferenciar os dois.
*.olc.protection.outlook.com é o e-mail pessoal do Outlook.com, e *.mail.protection.outlook.com é um tenant do Microsoft 365. Documentação diferente, escalonamento diferente.550 5.7.515 é sempre responsabilidade sua.A Microsoft opera dois sistemas de recebimento.
O Outlook.com é o e-mail pessoal: outlook.com, hotmail.com, live.com e msn.com, com hosts MX como hotmail-com.olc.protection.outlook.com. Ele tem o site Postmaster do Outlook.com, o SNDS para a reputação e um formulário próprio de suporte a remetentes.
O Microsoft 365 (Exchange Online) hospeda caixas postais corporativas. Os e-mails para acme.com vão para acme-com.mail.protection.outlook.com. Os erros são documentados no Microsoft Learn, os bloqueios passam pelo sender.office.com, e os admins do destinatário controlam como o tenant deles trata você.
O nome de domínio não diz em qual dos dois você está batendo. A resposta diz. Nesta linha de log publicada na mailop em 4 de setembro, o host do relay= é um tenant do Microsoft 365:
relay=xxxx-com.mail.protection.outlook.com[52.101.10.16]:25, dsn=4.7.500,
status=deferred (host xxx-com.mail.protection.outlook.com[52.101.10.16] said:
451 4.7.500 Server busy. Please try again later from [199.89.3.6]. (S77714)
[BN2PEPF000055E1.namprd21.prod.outlook.com 2026-09-04T10:28:53.346Z ...]
(in reply to end of DATA command))Leia o código básico (451), o código de status estendido (4.7.500) e o subcódigo entre parênteses, como (S77714). A Microsoft não publica os subcódigos S, mas muitos remetentes relatando o mesmo subcódigo ao mesmo tempo é um sinal.
| Resposta | Onde | O que diz a documentação da Microsoft | Primeira ação |
|---|---|---|---|
451 4.7.500 Server busy. Please try again later from [IP]. (S77714) |
Microsoft 365 | O Learn lista o 4.7.500-699 como “Access denied, please try again later”: atividade suspeita, envio temporariamente restrito. | Deixe a fila tentar de novo. Confira primeiro o alcance do problema. |
451 4.7.500-699 (ASxxx) |
Microsoft 365 | Limitação de taxa do IP quando o IP que se conecta “mudou os padrões anteriores de envio de e-mails, enviando um volume muito maior”. | Aumente o volume mais devagar. A limitação se resolve “em um período de alguns dias”. |
451 4.7.650 ... temporarily rate limited due to IP reputation (S775) |
Outlook.com | Não está na tabela publicada pela Microsoft. | Reduza o volume e as conexões simultâneas e depois confira o SNDS. |
451 4.7.652 ... exceeded the maximum number of connections (S3115) |
Outlook.com | Não está na tabela. O texto indica a causa. | Abra menos conexões. |
421 RP-001, RP-002, RP-003 |
Outlook.com | Limites de taxa, de taxa por conexão e de conexões excedidos, “relacionados à reputação do IP/domínio”. | Limite a taxa de envio e depois confira o SNDS. |
550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level. |
Outlook.com | O domínio envia mais de 5.000 por dia e não cumpre os requisitos de SPF, DKIM e DMARC. | Corrija a autenticação e o alinhamento. |
550 5.7.1 ... part of their network is on our block list (S3150) |
Outlook.com | Bloqueio do seu IP ou da sua faixa de IPs. | Pare de enviar por esse IP e abra um chamado. |
550 SC-001, SC-004, OU-002 e similares |
Outlook.com | Rejeições por política de conteúdo, de reputação ou de reclamações. O SC-004 aponta para o JMRP. | Encontre a causa antes de retomar. |
550 5.7.606-649 Access denied, banned sending IP [IP] |
Microsoft 365 | O IP está na lista de remetentes bloqueados. | Peça a remoção em sender.office.com. |
550 5.7.511 Access denied, banned sender |
Microsoft 365 | Exige investigação manual. | Encaminhe a notificação de falha na entrega (NDR) para delist@microsoft.com. |
Fontes: a referência de NDRs do Exchange Online, o artigo sobre o ASxxx, a tabela de códigos do Postmaster e o artigo sobre o 550 5.7.515, todos da Microsoft; o Al Iverson sobre o S775 e o S3115; o Twilio SendGrid sobre os bloqueios S3140/S3150.
As Sender Best Common Practices da M3AAWG dizem que, depois de uma falha temporária, “o remetente deveria fechar a conexão e abrir uma nova conexão mais tarde”, e que os remetentes nunca devem tratar uma falha temporária como permanente. As políticas para remetentes da Microsoft, sobre os 5xx: “o remetente não deve tentar retransmitir essa mensagem para esse destinatário”.
Um 451 não é uma rejeição. Se a sua plataforma ou algum script o trata como rejeição, corrija isso primeiro.
As orientações da Microsoft para o 4.7.500 apontam para os seus próprios envios. Normalmente, com razão, mas nem sempre.
A Qboxmail contou na mailop que o problema “começou às 9h47 CEST em todos os nossos IPs ao mesmo tempo”, com os subcódigos S77714, S77717 e S77719. A página de status da Poppulo citou o ID do incidente da Microsoft, EX1467029, com início às 11h19 BST.
Segundo o relato do emailexpert de 10 de setembro, um operador culpou cortes de fibra óptica até que One.com, Qboxmail, Mailjet e Poppulo relataram os mesmos códigos em todos os IPs de envio e em todas as regiões. A Microsoft culpou um modelo antispam e, depois, uma regra de limitação de taxa que continuou disparando durante a recuperação. O emailexpert não encontrou nenhum relatório público pós-incidente. Uma falha de autenticação separada, a MO1465074, durou cerca de 67 horas, de 31 de agosto a 3 de setembro. O nosso relatório de setembro cobre esses dez dias.
| Sinal | Aponta para a Microsoft | Aponta para você |
|---|---|---|
| Início | Todos os IPs começam no mesmo minuto | Um IP ou domínio, ou uma subida gradual |
| Outros provedores | Normais | Também piorando, ou com reclamações em alta |
| Outros remetentes | O mesmo código na mailop e nas páginas de status | Ninguém mais falando disso |
| As suas mudanças recentes | Nenhuma | Salto de volume, IP novo, lista nova |
| SNDS | Verde, sem bloqueio | Amarelo ou vermelho, reclamações, “Blocked” |
| Código | 4.7.500 com um subcódigo que outros relatam | RP-00x, 4.7.650, 5.7.515, S3150 |
Como encaminhar uma resposta da Microsoft, com base na documentação da Microsoft e nos relatos do incidente de setembro de 2026.
O Smart Network Data Services (SNDS) é o portal gratuito da Microsoft com a reputação de cada IP no Outlook.com. As perguntas frequentes do SNDS listam o que cada IP autorizado mostra:
Os dados “podem não estar presentes para IPs que enviaram menos de 100 mensagens no dia em questão”. Para ter acesso, solicite um IP, uma faixa ou um ASN, e o SNDS envia um link para os endereços que encontra pelo DNS reverso (postmaster@, abuse@) ou pelo RDAP. Não há pedidos manuais.
O SNDS foi relançado em junho de 2026. O Al Iverson observou em 19 de junho que os return-paths do JMRP já não identificam com confiabilidade a campanha e o destinatário, então codifique essas informações em outro lugar. Segundo a página inicial do SNDS (atualizada em 22 de setembro), o acesso expira 10 meses depois da aprovação ou da migração, com três lembretes. Anote na agenda.
O Junk Mail Reporting Program (JMRP), que você ativa dentro do SNDS, devolve cada mensagem que um usuário do Outlook.com marca como lixo eletrônico, muitas vezes “em apenas 72 horas” depois da inscrição. Remova quem reclamou de todas as listas e inscreva os IPs novos à medida que adicioná-los. Em IPs compartilhados, que você não pode cadastrar, pergunte ao seu provedor o que ele monitora.
Outlook.com. O formulário de suporte da página de solução de problemas do Postmaster exige uma conta Microsoft, cobre só os quatro domínios pessoais e “não garante” a entrega. Como orientação de fornecedor, o Twilio SendGrid recomenda incluir o seu domínio, os IPs, uma descrição do tráfego, o texto da rejeição e capturas de tela do SNDS, responder à primeira resposta automática pedindo escalonamento e solicitar a sua cota de volume e uma revisão do Volume-Based Limit.
Microsoft 365. Para o 5.7.606-649, use o portal de remoção da lista em sender.office.com: um endereço e um IP por visita, com confirmação por e-mail. A remoção “pode levar até 24 horas ou mais”. Para o 5.7.511, envie a notificação de falha na entrega por e-mail para delist@microsoft.com e espere uma resposta em até 48 horas.
Uma limitação ASxxx não tem remoção. Se a empresa destinatária filtra os e-mails recebidos por um serviço de terceiros antes do Microsoft 365, o artigo do Learn diz que um conector configurado pelo admin dela remove a limitação. Caso contrário, ela desaparece à medida que você constrói histórico.
Tente de novo com uma programação. A RFC 5321, seção 4.5.4.1, diz que “o intervalo entre tentativas DEVERIA ser de pelo menos 30 minutos” e que o prazo para desistir “geralmente precisa ser de pelo menos 4 a 5 dias”, com duas tentativas na primeira hora e depois uma a cada duas ou três horas. Não encurte esse prazo por causa de um envio urgente.
Limite a taxa por destino. A M3AAWG diz que os receptores esperam que o ajuste seja feito “como um processo em bloco, para todos os e-mails enviados a eles pelo mesmo endereço IP”. Quando a Microsoft adiar, desacelere tudo o que vai para aquela família de MX (Outlook.com ou Microsoft 365).
Fique de olho nas conexões. A política do Outlook.com diz que os remetentes “não devem abrir mais de 500 conexões simultâneas” sem um acordo prévio. Esse é um teto, e um 4.7.652 (S3115) significa que você passou do seu.
Aqueça IPs e domínios novos. A Microsoft diz que um IP novo “pode esperar estar totalmente aquecido em algumas semanas ou antes”, dependendo do volume, da precisão da lista e das reclamações. IPs novos cobertos por um registro SPF existente herdam parte da reputação do domínio. Comece por quem engajou recentemente.
5.7.515.Para o alinhamento do DMARC e a passagem de p=none para uma política aplicada, veja o nosso guia de entregabilidade. Para que as redefinições de senha e os recibos continuem chegando, o nosso guia de e-mails transacionais explica como colocá-los em um domínio próprio.
O Brew opera a infraestrutura de envio e repete as tentativas em falhas temporárias, então você nunca precisa ajustar filas ou limites de conexão. O que você vê:
delivery_delayed), e o destinatário passa de aceito para atrasado e depois para entregue ou rejeitado. Em Eventos, busque por “atrasados” e depois digite @hotmail.com ou @outlook.com para restringir ao Outlook.com (os filtros de domínio se combinam com OU; os destinatários do Microsoft 365 usam domínios próprios). O evento diz que a mensagem está esperando, não o motivo.deliveryDelayed e pending ao lado dos entregues e das rejeições. O get_email_analytics faz o mesmo pelo MCP.get_domain_health. Um teste de caixa de entrada (10 créditos) envia para caixas de teste no Gmail, no Outlook, no Yahoo, na Apple e em outros provedores.Webhooks de entrega e dados do SNDS ou do JMRP ainda não estão no Brew (as contagens por provedor vêm da API de eventos, com groupBy=recipientDomain), então use os portais da Microsoft para acompanhar a reputação. Diante da suspeita de um incidente da Microsoft, nós deixaríamos o envio como está e acompanharíamos o Atrasado virar Entregue.
É uma recusa temporária do Microsoft 365 (Exchange Online), listada como “Access denied, please try again later” depois de uma atividade suspeita. Normalmente, é porque o seu padrão de envio mudou, mas em 4 de setembro de 2026 foi um incidente da Microsoft (EX1467029). Deixe o seu servidor tentar de novo e confira se outros remetentes também estão recebendo esse código.
A Microsoft diz que a limitação baseada em padrões se resolve “em um período de alguns dias”, à medida que você constrói histórico, e que a remoção da lista pode levar até 24 horas ou mais. Continue tentando por pelo menos 4 a 5 dias, como a RFC 5321 recomenda, e a maior parte dos e-mails adiados acaba sendo entregue.
O Outlook.com rejeita e-mails de domínios que enviam mais de 5.000 por dia e não cumprem as regras de autenticação dele, aplicadas desde 5 de maio de 2025. O SPF e o DKIM precisam passar, o domínio precisa publicar um registro DMARC (p=none basta), e o SPF ou o DKIM precisa estar alinhado com o domínio do From.
Não. A Microsoft diz que IPs novos não têm reputação e têm mais chance de ter problemas. Corrija a causa, peça a remoção da lista e volte a aumentar o volume aos poucos no IP que você já tem.
Não. A M3AAWG diz que os remetentes não devem tratar um 4xx como permanente. Ele só vira rejeição se as tentativas se esgotarem ou se o servidor retornar um 5xx. No Brew, um adiamento aparece como um evento Atrasado, e os contatos só são suprimidos depois de rejeições temporárias repetidas.
