Não recebo e‑mails externos no Exchange Online/Outlook (Microsoft 365): diagnóstico completo e correção passo a passo

Seu Exchange Online/Outlook (Microsoft 365) parou de receber e‑mails de fora? Este guia prático explica as causas mais comuns, mostra como diagnosticar em minutos e fornece correções seguras para retomar o fluxo de mensagens sem adivinhações.

Índice

Visão geral do problema

Em organizações de todos os portes — e, em menor escala, em contas pessoais @outlook.com/@msn — usuários relatam que deixaram de receber e‑mails externos. Internamente, o fluxo segue normal; alguns remetentes recebem relatórios de falha (NDR/bounce) e outros não veem qualquer alerta. Em ambientes Microsoft 365 Business/Enterprise, a origem costuma estar em (a) restrições na própria caixa, (b) registros DNS (MX/SPF/DKIM/DMARC) incoerentes, (c) políticas de antispam/quarentena (EOP/Defender) rígidas demais ou (d) regras/roteamentos que desviam o tráfego. Nas contas de consumidor, filtros e listas de remetentes também têm papel importante.

O segredo para resolver rápido é confirmar onde a mensagem parou (Traço de Mensagem/Message Trace) e, a partir daí, ajustar o componente responsável: caixa, DNS ou política.

Diagnóstico rápido (checklist de 5 minutos)

  1. Teste pelo Outlook na Web (OWA): envie de um endereço externo para a caixa afetada e verifique a chegada somente via navegador. Se aparece no OWA mas não no Outlook para desktop, o problema é local (perfil/OST/regras do cliente).
  2. Recolha o NDR completo (quando houver): código “550/554 5.x.x”, descrição e cabeçalhos. Isso aponta o responsável (DNS, rejeição de política, tamanho, etc.).
  3. Faça um Traço de Mensagem (Message Trace) no portal de segurança: confirme se foi aceita, quarentenada, bloqueada ou nem chegou ao serviço.
  4. Verifique a restrição da caixa “Exigir que todos os remetentes sejam autenticados” (Require that all senders are authenticated): se marcada, nenhum remetente externo consegue entregar.
  5. Valide o MX: o registro deve apontar para *.mail.protection.outlook.com (ou para o host fornecido pelo provedor/segurança se você usa gateway externo).

Causas frequentes e o que verificar

CategoriaO que verificarEfeito típicoComo corrigir
Configuração da caixaCentro de administração do Exchange → Caixas → Recursos da caixa → Restrições de entrega de mensagens / Message delivery restrictions.Bloqueio total de remetentes externos.Desmarque Require that all senders are authenticated; revise as listas Accept from / Reject from, removendo entradas indevidas.
DNS do domínioMX, SPF, DKIM e DMARC coerentes. O MX precisa resolver para a borda correta (EOP ou gateway).Mensagens entregues ao servidor errado, rejeitadas por SPF/DMARC ou perdidas.Alinhe o MX para *.mail.protection.outlook.com (sem gateway) ou para o seu gateway (com conectores). Corrija SPF/DKIM/DMARC conforme exemplos abaixo.
Políticas anti‑spam / Regras de transporteFiltros de reputação, listas de bloqueio (IP/domínio), políticas de quarentena, regras de mail flow.Mensagem vai para quarentena “silenciosa” ou é rejeitada com 5.7.1/5.7.23.Reduza agressividade, habilite notificações de quarentena ao usuário, corrija regras que rejeitam “externo” indiscriminadamente.
Cliente vs WebFunciona no OWA, falha no Outlook desktop?Perfil local corrompido, OST ou credenciais.Novo perfil, redefinição de pastas, atualização do Office, limpeza de credenciais; veja seção específica.
Servidores externos (POP/IMAP/SMTP de ISP)Se usa coleta POP/IMAP ou encaminhamento por ISP, teste autenticação e conectividade.Outlook deixa de transferir correio do servidor externo.Repare credenciais, TLS/portas, quotas; prefira conectividade direta ao Exchange Online quando possível.
Gateway/segurança de terceirosSe o MX aponta para um gateway (appliance/serviço), confirme conectores e IPs de origem confiáveis.Mensagens ficam retidas no gateway ou são rejeitadas ao encaminhar para o 365.Crie/ajuste conectores no Exchange Online, sincronize listas de permissão e SPF alinhado ao gateway.
Híbrido com Exchange localConectores, receive connectors on‑prem, roteamento híbrido, certificados.Entrega só falha para caixas migradas ou apenas para on‑prem.Valide conectores híbridos, certificados válidos, namespaces e roteamento coerente.

Passo a passo de resolução (detalhado)

Reproduzir e recolher provas

  • Envie de um endereço externo e salve o NDR completo (inclua Enhanced Status Code e cabeçalhos). Ex.: 550 5.7.1, 550 5.4.1, 554 5.2.0.
  • Execute Message Trace no portal de segurança para confirmar o caminho (Delivered, Quarantined, Rejected, FilteredAsSpam, Expanded, etc.).

Eliminar bloqueios na própria caixa

  • No Exchange Admin Center (novo ou clássico): localize a caixa → Mail flow settingsMessage delivery restrictions. Desmarque Require that all senders are authenticated.
  • Verifique regras do usuário (incluindo regras “do lado do servidor”). No Windows, você pode iniciar o Outlook com: outlook.exe /cleanrules Use com cautela — remove regras do cliente. Para “server‑side”, use: outlook.exe /cleanserverrules
  • Confirme se a pasta Itens de Correio Indesejado e Outras (Caixa de Entrada Prioritária) não estão ocultando mensagens. Desative temporariamente a Caixa de Entrada Prioritária para testes.

Validar DNS e autenticação

Fora erros de caixa, DNS desalinhado é o campeão de incidentes. Use ferramentas de consulta de DNS para verificar cada registro abaixo:

RegistroExemplo (sem gateway)Erros comunsBoas práticas
MX10 contoso-com.mail.protection.outlook.com.Apontar para provedor antigo; entrada duplicada com menor prioridade; TTL altíssimo durante migração.Um único MX ativo apontando para EOP (ou para o gateway oficial se aplicável). TTL 300–3600 durante mudanças.
SPF (TXT)v=spf1 include:spf.protection.outlook.com -allVários registros SPF; ~all quando se deseja -all; esquecer de incluir serviços que enviam pelo domínio (marketing, helpdesk).Mantenha um SPF; agregue todos os emissores com include:; evite ultrapassar 10 lookups.
DKIMselector1.domainkey CNAME selector1-contoso-com.domainkey.<tenant>.onmicrosoft.comCNAMEs apontando para nomes errados; seletor ativado no portal, mas sem CNAME no DNS.Crie os dois seletores (selector1/selector2) e só ative após a propagação.
DMARC (TXT)v=DMARC1; p=quarantine; rua=mailto:dmarc@contoso.com; adkim=s; aspf=sp=reject prematuro; ausência de rua para relatórios, dificultando ajustes graduais.Comece com p=none, monitore, evolua para quarantine e só então reject.

Split‑brain DNS: se existe DNS interno com MX diferente do externo, garanta que o resolutor de saída usado pelos servidores remetentes externos vê o MX público correto. Em migrações, TTL alto pode atrasar até 48 h em alguns provedores.

Rever políticas globais de spam (EOP/Defender)

  • Política anti‑spam: verifique o que acontece com High confidence spam e Phishing. Se estiver definido para Quarantine sem notificação ao usuário, parece que o e‑mail “sumiu”. Ative as notificações ou entregue em Junk para testes.
  • Tenant Allow/Block List: procure domínios/IPs em Block. Bloqueios herdados de incidentes antigos continuam ativos e abrangentes.
  • Regras de mail flow (transport rules): identifique regras com condições “O remetente é externo” combinadas a ações de Reject/Delete. Muitas tentam reduzir spam mas acabam bloqueando parceiros legítimos.
  • Proteções avançadas (Safe Attachments/Links): revise se há políticas com ação de Block para todos os destinatários; teste em modo Monitor/Replace ao invés de bloqueio total.

Contas pessoais (@outlook.com/@msn) sem acesso de admin

  • Adicione o remetente à Lista de Remetentes Seguros e verifique as regras de caixa.
  • Se houver NDR, copie os cabeçalhos e abra uma solicitação de suporte via menu de Ajuda do próprio serviço.

Problemas apenas no Outlook para desktop

  • Crie um novo perfil: Painel de Controlo → Correio → Mostrar PerfisAdicionar → marque Solicitar um perfil ao iniciar.
  • Redefina pastas e regras do lado do servidor: outlook.exe /resetfolders outlook.exe /cleanserverrules
  • Atualize o Office e limpe credenciais salvas no Gerenciador de Credenciais.
  • Teste a conta: Ficheiro → Definições da Conta → Testar Definições da Conta. Se o OWA recebe e o Outlook não, é quase sempre local.

Escalar para Microsoft

Abra um chamado quando o Traço de Mensagem mostra rejeição no serviço (não no remetente) ou quando múltiplos domínios/usuários são afetados apesar de MX correto. Inclua:

  • Hora do envio (UTC), endereço IP do servidor remetente, NDR completo.
  • Resultado do Message Trace (ID do Message ID, ação tomada e política responsável).

Interpretando NDRs: o que significam na prática

CódigoSignificado provávelAção recomendada
550 5.1.10Domínio/caixa não aceita o endereço (erro de roteamento, domínio não autoritativo).Confirme se o domínio está verificado no tenant e se o MX aponta corretamente.
550 5.7.1Política bloqueou (SPF/DMARC falhou; bloqueio por reputação; remetente não autenticado).Ajuste políticas anti‑spam; verifique SPF/DMARC do remetente; remova bloqueios em listas.
550 5.4.1Loop ou destino não alcançável (roteamento).Reveja conectores/gateway; confirme o destino final correto.
552 5.2.3Excedeu limites (tamanho/quota).Aumente limite temporário; peça reenvio compactado ou via compartilhamento.
451 4.7.650Throttle/limitação temporária por reputação.Tente novamente após alguns minutos; verifique reputação do IP remetente.

Conectores, gateways e cenários híbridos

Se você utiliza um gateway de e‑mail (serviço/appliance antes do Exchange Online) ou Exchange híbrido, o MX pode apontar para outro host. Nesse caso:

  1. Crie conectores de entrada no Exchange Online confiando no IP do gateway, com TLS apropriado.
  2. Garanta que o SPF inclua o emissor final (gateway), não apenas spf.protection.outlook.com.
  3. Se usar transport rules para roteamento condicional, documente e teste cada caminho (desvio pode mandar mensagens para o lugar errado).
  4. Em híbrido, valide receive connectors on‑prem, certificados e Accepted Domains como Authoritative/Internal Relay conforme o desenho.

Comandos úteis de verificação (administradores)

Para quem administra via PowerShell, estes comandos ajudam no diagnóstico (exemplos ilustrativos, adapte à sua realidade):

# Verificar se a caixa exige remetentes autenticados
Get-Mailbox -Identity usuario@dominio.com | fl RequireSenderAuthenticationEnabled

Verificar listas Accept/Reject da caixa

Get-Mailbox -Identity [usuario@dominio.com](mailto:usuario@dominio.com) | fl AcceptMessagesOnlyFrom\,RejectMessagesFrom\

Traço de mensagens básico (últimas 24h)

Get-MessageTrace -RecipientAddress [usuario@dominio.com](mailto:usuario@dominio.com) -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date)

Políticas anti-spam ativas

Get-HostedContentFilterPolicy | ft Name,MarkAsSpamBulkMail,HighConfidenceSpamAction,QuarantineTag

Itens na Allow/Block List do tenant

Get-TenantAllowBlockListItems -ListType Sender -Entries "dominio-remetente.com"

Regras de transporte

Get-TransportRule | ft Name,State,Mode,Priority 

Boas práticas de prevenção

  • Monitore registros DNS e use TTL baixo (300–3600) antes de migrações/trocas de provedor.
  • Audite trimestralmente regras de transporte, Allow/Block Lists e políticas anti‑spam para evitar “apertos” cumulativos.
  • Implemente DMARC gradualmente: nonequarantinereject, sempre com relatórios.
  • Alertas de falha: crie relatórios de NDR por limiar (picos de rejeição são sinal precoce de incidentes).
  • Documente conectores e gateways: desenhe o fluxo de e‑mail; em emergências, ter o diagrama acelera o reparo.

Ponto de atenção para utilizadores lusófonos

  • Os menus podem aparecer como Centro de administração do ExchangeRestrições de entrega de mensagens (PT‑PT/pt‑BR).
  • Se o domínio estiver alojado fora de Portugal/Brasil, confirme com o registrador se não há split‑brain DNS (MX interno diferente do externo).
  • Provedores com catch‑all: desative durante testes — mascara a existência de endereços inválidos e atrapalha o diagnóstico.

FAQ rápida

“O NDR diz que o SPF falhou, mas meu SPF está correto. O que ocorre?”
Provavelmente o envelope sender (Return‑Path) difere do From: visível. Ajuste no serviço remetente (sua ferramenta de marketing/helpdesk) para assinar com o domínio certo ou inclua o emissor real no SPF.

“Ativei DKIM e mesmo assim falha.”
Os CNAMEs dos seletores podem apontar para nomes errados ou ainda não propagaram. Valide a resolução e só então ative no portal.

“Usamos gateway que faz rewrite de links e anexos. Pode quebrar DMARC?”
DMARC depende de SPF e DKIM alinhados. Se o gateway altera o corpo/assinatura, o DKIM quebra; garanta que o SPF do gateway esteja no seu registro.

“No OWA chega, no Outlook não.”
Defeito local: reconfigure o perfil, limpe regras/pastas, atualize o Office. Verifique também antivírus/plug‑ins de terceiros.

“Só um domínio externo específico não consegue enviar para nós.”
O problema provavelmente está do lado deles (SPF/DMARC/reputação). Peça que validem autenticação e reputação; em paralelo, confira se você não os bloqueou em Allow/Block List.

Checklist final (imprimível)

  1. Testar pelo OWA; guardar NDR/cabeçalhos.
  2. Executar Message Trace e capturar a ação aplicada.
  3. Eliminar “Exigir remetentes autenticados” e limpezas na caixa (regras, Junk, Prioritária).
  4. Validar MX → *.mail.protection.outlook.com (ou gateway), SPF/DKIM/DMARC.
  5. Rever políticas anti‑spam/quarentena e regras de transporte; habilitar notificações.
  6. Se só no Outlook desktop, novo perfil e correções locais.
  7. Se persiste e afeta muitos, abrir chamado com UTC, IP de origem, NDR e Message Trace.

Resumo em uma frase

Na maioria dos casos, a falha em receber e‑mails externos ocorre por (a) a restrição “Exigir que todos os remetentes sejam autenticados” ligada, ou (b) registros MX/SPF incorretos; ao corrigir essas configurações no Exchange Admin Center ou no DNS, as mensagens voltam a chegar normalmente.


Anexos práticos

Modelos de registros (ajuste ao seu domínio)

; MX (sem gateway)
@   IN MX 10 contoso-com.mail.protection.outlook.com.

; SPF (apenas Exchange Online)
@   IN TXT "v=spf1 include\:spf.protection.outlook.com -all"

; DMARC (política em quarentena, modo estrito)
\_dmarc IN TXT "v=DMARC1; p=quarantine; adkim=s; aspf=s; pct=100; rua=mailto\:dmarc\@contoso.com"

; DKIM (os alvos exatos são fornecidos no portal)
selector1.\domainkey IN CNAME selector1-contoso-com.\domainkey.\.onmicrosoft.com.
selector2.\domainkey IN CNAME selector2-contoso-com.\domainkey.\.onmicrosoft.com. 

Roteiro de decisão (resumo)

  • Não chegou ao serviço → DNS/MX errado ou problema no remetente.
  • Chegou e foi rejeitada → política (anti‑spam/regras/conectores) causou Reject.
  • Chegou e foi quarentenada → ajuste ação/política e habilite notificação ao usuário.
  • Entregue na caixa e não aparece no Outlook → defeito do cliente (perfil/OST/regras).

Boas práticas adicionais

  • Cadastre domínios/parceiros críticos em Allow (temporário) apenas durante investigações — remova após a causa‑raiz.
  • Padronize nomes de regras de transporte (ex.: “BLK – Externo suspeito – 2025‑09”) e registre a justificativa.
  • Implemente relatórios DMARC e analise-os semanalmente até estabilizar em p=reject.
  • Antes de mudanças de MX/SPF, publique aviso interno e monitore filas/quarentena nas 24–48 h seguintes.

Com estes procedimentos, você cobre 95% dos cenários em que e‑mails externos deixam de chegar ao Exchange Online/Outlook. O restante geralmente envolve rotas híbridas/gateways com conectores fora de conformidade, que também estão mapeados acima.

Índice