# Adiamentos 451 4.7.500 da Microsoft: guia para remetentes

URL canônica: https://brew.new/pt-br/blog/microsoft-451-4-7-500-deferrals-playbook
Por Thomas Park
Publicado em 2026-10-05
Atualizado em 2026-10-05

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.

## Pontos-chave

- Leia primeiro o host: `*.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.
- Um 4xx significa colocar na fila e tentar de novo: a RFC 5321 fala em intervalos de pelo menos 30 minutos, por pelo menos 4 a 5 dias. Um 5xx significa parar. As políticas da Microsoft proíbem novas tentativas.
- Se todos os IPs recebem o mesmo código da Microsoft no mesmo minuto enquanto o Gmail e o Yahoo seguem normais, desconfie da Microsoft e confira a lista mailop antes de mudar qualquer coisa.
- Desde 5 de maio de 2025, o Outlook.com exige SPF, DKIM e DMARC de domínios que enviam mais de 5.000 mensagens por dia. Um `550 5.7.515` é sempre responsabilidade sua.
- Cadastre agora os seus IPs de envio no SNDS e no JMRP. O acesso ao SNDS expira depois de 10 meses, a menos que você renove a confirmação.
- Não insista com mais tentativas, não troque para IPs novos e não suprima os contatos com envios adiados.

## Primeiro, descubra com qual Microsoft você está falando

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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting), 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](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), 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](https://www.mail-archive.com/mailop@mailop.org/msg27209.html) em 4 de setembro, o host do `relay=` é um tenant do Microsoft 365:

```text
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))
```

## Decifre a resposta

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](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), o [artigo sobre o ASxxx](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-451-4-7-500-699-asxxx-in-exchange-online), a tabela de códigos do Postmaster e o [artigo sobre o 550 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com), todos da Microsoft; o Al Iverson sobre o [S775](https://www.spamresource.com/2026/02/microsoft-rate-limiting-issues.html) e o [S3115](https://www.spamresource.com/2025/07/microsoft-says-too-many-connections.html); o Twilio SendGrid sobre os [bloqueios S3140/S3150](https://support.sendgrid.com/hc/en-us/articles/38465017420955-Troubleshooting-Microsoft-Delivery-Issues-With-Error-550-5-7-1-S3140-S3150-Blocks).

### O 4 ou o 5 já é a instrução

As [Sender Best Common Practices da M3AAWG](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf) 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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies) 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.

## Incidente da Microsoft ou a sua reputação

As orientações da Microsoft para o 4.7.500 apontam para os seus próprios envios. Normalmente, com razão, mas nem sempre.

### Como foi o 4 de setembro de 2026

A Qboxmail [contou na mailop](https://www.mail-archive.com/mailop@mailop.org/msg27208.html) 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](https://poppulo1.statuspage.io/incidents/w0671ycn23fw) 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](https://emailexpert.com/microsofts-ten-days-three-exchange-online-incidents-three-causes/), 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](/pt-br/blog/state-of-email-september-2026) cobre esses dez dias.

### Cinco verificações antes de agir

1. **O alcance do problema nos seus envios.** Problemas de plataforma atingem todos os IPs, domínios e tipos de tráfego em poucos minutos. Problemas de reputação costumam começar em um só.
2. **Outros provedores.** Se o Gmail, o Yahoo e a Apple aceitam normalmente e outros remetentes relatam o mesmo código da Microsoft, a causa provavelmente é a Microsoft.
3. **As suas últimas 72 horas.** Um pico de volume, um IP novo, uma lista importada, uma alteração no DNS ou um envio de reativação precisam de correção de qualquer jeito.
4. **Pergunte por aí.** Confira o arquivo da mailop e as páginas de status. Um admin do Microsoft 365 pode abrir **Integridade > Integridade do serviço** (Health > Service health), cujo [Histórico de problemas](https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health) cobre os últimos 7 ou 30 dias de incidentes publicados no seu tenant. Foi ali que a Poppulo encontrou o EX1467029.
5. **SNDS.** Verde e sem bloqueios enquanto os adiamentos se acumulam indica que o problema não está do seu lado.

| 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 |

![Fluxograma de decisão para as respostas da Microsoft: os códigos 5xx levam à correção da autenticação, ao portal de remoção da lista ou a um chamado no suporte; os códigos 4xx levam a uma verificação de incidente e, depois, a esperar passar ou a limitar a taxa e conferir o SNDS.](/images/blog/microsoft-451-4-7-500-deferrals-playbook-flowchart.png)

*Como encaminhar uma resposta da Microsoft, com base na documentação da Microsoft e nos relatos do incidente de setembro de 2026.*

## SNDS e JMRP: configure antes de precisar

O [Smart Network Data Services](https://substrate.office.com/ip-domain-management-snds/snds) (SNDS) é o portal gratuito da Microsoft com a reputação de cada IP no Outlook.com. As [perguntas frequentes do SNDS](https://substrate.office.com/ip-domain-management-snds/SNDS/FAQ) listam o que cada IP autorizado mostra:

- **Resultado da filtragem.** Verde significa menos de 10% das mensagens classificadas como spam; amarelo, de 10% a 90%; vermelho, mais de 90%.
- **Taxa de reclamações**, as reclamações divididas pelos destinatários. Mais de 30% dos IPs ficam abaixo de 0,3%, “um bom patamar para mirar”.
- **Comandos RCPT versus destinatários das mensagens.** Uma diferença grande indica listas desatualizadas.
- **Status do IP**: Blocked, Bot ou Junked.

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](https://www.spamresource.com/2026/06/snds-and-jmrp-in-transition.html) 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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Services) (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.

## Suporte a remetentes e remoção da lista de bloqueio

**Outlook.com.** O formulário de suporte da [página de solução de problemas do Postmaster](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting) 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](https://learn.microsoft.com/en-us/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself) 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, limite a taxa e aumente aos poucos

**Tente de novo com uma programação.** A [RFC 5321, seção 4.5.4.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-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.

## O que não fazer

- **Insistir com mais tentativas.** Forçar a fila a cada poucos minutos empilha conexões em um IP que a Microsoft quer desacelerar, e o resultado é um 4.7.652.
- **Trocar de IP para escapar.** IPs novos não têm reputação e têm mais chance de ter problemas, e espalhar e-mails por IPs novos é exatamente o que fazem os spammers da técnica snowshoe.
- **Tentar de novo depois de um 5xx.** A Microsoft proíbe, e depois de “várias respostas de falha na entrega” você precisa parar de enviar para aquele destinatário.
- **Suprimir os contatos com envios adiados.** O endereço continua válido.
- **Reenviar para os destinatários adiados.** As mensagens deles continuam na fila. Você mandaria duplicatas.
- **Mexer no DNS em pânico.** Alterar o SPF ou o DKIM no meio de um incidente cria um segundo problema, a menos que você tenha recebido um `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](/pt-br/blog/email-deliverability). Para que as redefinições de senha e os recibos continuem chegando, o nosso [guia de e-mails transacionais](/pt-br/blog/transactional-emails) explica como colocá-los em um domínio próprio.

## Como isso aparece no Brew

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ê:

- **Eventos atrasados.** Um adiamento registra um evento Atrasado (`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.
- **Detalhes da rejeição.** Os Metadados de um evento Rejeitado trazem o tipo de rejeição e a mensagem do provedor.
- **Contagens pela API.** A [visão geral de análises](https://docs.brew.new/api-reference/public-v1/analytics/brand-overview-totals-rates-timeseries) retorna `deliveryDelayed` e `pending` ao lado dos entregues e das rejeições. O `get_email_analytics` faz o mesmo pelo MCP.
- **Supressão que respeita os 4xx.** Rejeições permanentes e reclamações geram supressão imediata. Rejeições temporárias só geram supressão depois de três em 30 dias.
- **Aumento gradual.** O [envio gradual](https://docs.brew.new/create-emails/send-options#gradual-send) divide um envio grande em lotes percentuais por hora ou por dia, que você pode pausar se o Outlook.com começar a adiar.
- **Saúde do domínio.** O card Entregabilidade de cada domínio dá uma nota de 0 a 100 considerando a chegada à caixa de entrada, a reputação, a autenticação, o conteúdo e a configuração de envio; essa nota também está disponível pela ferramenta 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.

## Perguntas frequentes

### O que significa 451 4.7.500 Server busy no Outlook ou no Microsoft 365?

É 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.

### Por quanto tempo a Microsoft vai continuar adiando os meus e-mails?

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 que é o 550 5.7.515 e como corrigir?

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.

### Devo trocar de endereço IP se a Microsoft bloquear o meu?

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.

### Os adiamentos da Microsoft contam como rejeições?

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.