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.
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)
- 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).
- 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.).
- 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.
- 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.
- 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
Categoria | O que verificar | Efeito típico | Como corrigir |
---|---|---|---|
Configuração da caixa | Centro 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ínio | MX, 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 transporte | Filtros 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 Web | Funciona 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 terceiros | Se 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 local | Conectores, 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 settings → Message 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:
Registro | Exemplo (sem gateway) | Erros comuns | Boas práticas |
---|---|---|---|
MX | 10 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 -all | Vá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. |
DKIM | selector1.domainkey CNAME selector1-contoso-com.domainkey.<tenant>.onmicrosoft.com | CNAMEs 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=s | p=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 Perfis → Adicionar → 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ódigo | Significado provável | Ação recomendada |
---|---|---|
550 5.1.10 | Domí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.1 | Polí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.1 | Loop ou destino não alcançável (roteamento). | Reveja conectores/gateway; confirme o destino final correto. |
552 5.2.3 | Excedeu limites (tamanho/quota). | Aumente limite temporário; peça reenvio compactado ou via compartilhamento. |
451 4.7.650 | Throttle/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:
- Crie conectores de entrada no Exchange Online confiando no IP do gateway, com TLS apropriado.
- Garanta que o SPF inclua o emissor final (gateway), não apenas
spf.protection.outlook.com
. - Se usar transport rules para roteamento condicional, documente e teste cada caminho (desvio pode mandar mensagens para o lugar errado).
- 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:
none
→quarantine
→reject
, 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 Exchange → Restriçõ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)
- Testar pelo OWA; guardar NDR/cabeçalhos.
- Executar Message Trace e capturar a ação aplicada.
- Eliminar “Exigir remetentes autenticados” e limpezas na caixa (regras, Junk, Prioritária).
- Validar MX →
*.mail.protection.outlook.com
(ou gateway), SPF/DKIM/DMARC. - Rever políticas anti‑spam/quarentena e regras de transporte; habilitar notificações.
- Se só no Outlook desktop, novo perfil e correções locais.
- 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.