Diagnóstico Autodiscover O365: Testar DNS, SCP e Conectividade

✎ Duarte Spínola  |  2026-07-16

O Outlook não consegue configurar automaticamente a caixa de correio do Office 365. O utilizador abre o Outlook, introduz o email, e em vez de aparecer a caixa configurada, surge um erro de ligação ou um pedido de configuração manual. Na maioria dos casos, o problema não está no Outlook nem no Exchange Online — está no caminho de resolução Autodiscover, que depende de registos DNS correctos, ausência de Service Connection Points legados do Exchange on-premises, e conectividade HTTPS aos endpoints da Microsoft. Este artigo estrutura um diagnóstico completo em seis passos que isola cada camada — DNS, SCP, HTTPS, autenticação — para identificar exactamente onde a ligação falha.

Já existem artigos no kbase.pt sobre autodiscover (diagnóstico DNS e Office 365 vs Hosted Exchange). Este artigo é um complemento que estrutura o diagnóstico como um fluxo sequencial — cada passo valida uma camada específica e só passa para a seguinte se a anterior passar.

1. O que Está a Acontecer — Como o Outlook Encontra o Exchange via Autodiscover

O Autodiscover é o mecanismo pelo qual o Outlook descobre automaticamente as definições de ligação ao Exchange — servidor, porta, protocolo de autenticação. Sem Autodiscover funcional, o Outlook não consegue configurar uma caixa de correio sem intervenção manual (Microsoft Learn — Autodiscover).

O processo de descoberta segue uma ordem precisa. O Outlook tenta cada método por ordem e usa o primeiro que responder:

O problema surge quando uma destas camadas responde com informação incorrecta. Por exemplo: o SCP aponta para um Exchange on-premises descomissionado (passo 1 responde, mas com o servidor errado), ou o CNAME DNS aponta para um servidor que já não existe (passo 2 responde, mas com o destino errado). O Outlook segue a primeira resposta que recebe, mesmo que seja incorrecta.

Para tenants do Office 365, o fluxo correcto é: sem SCP (ou SCP a apontar para O365) → CNAME autodiscover.dominio.pt → autodiscover.outlook.com → Exchange Online.

2. Cenários em que Este Diagnóstico Se Aplica

Este guia aplica-se especificamente a:

• Migração on-premises → cloud: domínio recentemente migrado de Exchange on-premises para Exchange Online, Outlook não configura automaticamente
• Configuração inicial O365: novo tenant Office 365, novo domínio verificado, primeira configuração do Outlook
• Cenário híbrido: Exchange on-premises coexiste com Exchange Online, Outlook liga ao servidor errado
• Domínios com múltiplos fornecedores: domínio que teve Hosted Exchange noutro fornecedor antes do O365, registos DNS antigos a interferir
• Alterações de DNS recentes: mudança de fornecedor de DNS, propagação incompleta

Não se aplica a:

• Outlook com caixa de correio on-premises (Exchange Server local) — o fluxo Autodiscover é diferente
• Clientes móveis (iOS/Android) que usam ActiveSync, não Autodiscover Outlook
• Problemas de licenciamento (caixa sem licença E3/Business Premium) — não é problema de Autodiscover

3. Passo 1 — Verificar o Registo DNS CNAME autodiscover

O primeiro passo é confirmar que o registo DNS autodiscover.dominio.pt existe e aponta para o endpoint correcto da Microsoft. Este é o registo que o Outlook consulta quando não encontra SCP (ou quando o SCP não responde).

3.1 Consultar o registo CNAME

Abre uma linha de comandos (cmd ou PowerShell) e resolve o registo DNS:

O output esperado para um domínio correctamente configurado no Office 365:

Se o output mostrar um CNAME diferente (ex: autodiscover.outlook.com está ausente e aponta para um servidor local), o registo DNS está mal configurado.

3.2 Verificar a cadeia completa de resolução

O CNAME autodiscover.dominio.pt deve resolver para autodiscover.outlook.com, que por sua vez resolve para um endereço IP da Microsoft. Verifica a cadeia completa:

3.3 Verificar com nslookup (alternativa)

Se não tiveres PowerShell, usa nslookup em qualquer sistema Windows:

3.4 Tabela de Diagnóstico DNS

Os endpoints oficiais do Office 365 que devem estar acessíveis estão documentados em (Microsoft Learn — URLs e IP ranges O365).

4. Passo 2 — Verificar Service Connection Points (SCP) no Active Directory

Em ambientes que tinham Exchange on-premises, o Active Directory contém objectos SCP que dizem ao Outlook onde procurar o Autodiscover. Mesmo após migrar para O365, estes objectos podem persistir e direccionar o Outlook para o servidor Exchange antigo — o problema mais comum em migrações.

4.1 Listar SCPs no domínio

Para listar todos os SCPs de Autodiscover registados no Active Directory:

O output esperado num ambiente puramente cloud (sem Exchange on-premises):

Se aparecerem resultados, cada linha mostra um SCP que está a direccionar o Outlook. Output típico de ambiente com Exchange on-premises legado (exemplo ilustrativo, não executado):

Name serviceBindingInfo DistinguishedName

—- —————— —————–

Autodiscover (EXCH01) https://exch01.dominio.local/autodiscover/autodiscover.xml CN=EXCH01,CN=Servers,CN=Exchange…

Isto significa que o Outlook está a ser direccionado para exch01.dominio.local — um servidor que provavelmente já não existe ou não é o correcto para O365.

4.2 Verificar SCP do computador local

Para ver qual SCP específico o Outlook está a usar no computador actual:

As chaves que podem estar a interferir:

4.3 Desactivar SCPs Legados

Se o ambiente já não tem Exchange on-premises, os SCPs devem ser removidos do Active Directory. Isto faz-se no servidor Exchange on-premises antes de descomissionar, ou via ADSI Edit:

4.4 Bypass Temporário de SCP para Teste

Para confirmar que o SCP é o problema, desactiva temporariamente a consulta de SCP no registo do cliente e testa novamente:

Depois de aplicar esta chave, reinicia o Outlook. Se a caixa configurar automaticamente, o problema é o SCP. Remove a chave depois do teste se não quiseres manter o bypass permanente:

5. Passo 3 — Testar Conectividade HTTPS ao Endpoint Autodiscover

Depois de confirmar que o DNS resolve correctamente e os SCPs não interferem, o próximo passo é verificar que o Outlook consegue efectivamente ligar via HTTPS ao endpoint Autodiscover do Office 365.

5.1 Testar ligação TCP à porta 443

O Autodiscover do O365 usa HTTPS (porta 443). Verifica que o computador consegue chegar ao endpoint:

Output esperado:

Se TcpTestSucceeded for False, há um firewall ou proxy a bloquear a ligação.

5.2 Testar o pedido HTTPS completo

Para testar o pedido Autodiscover completo (não só TCP), usa o Microsoft Remote Connectivity Analyzer (RCA). É a ferramenta oficial da Microsoft para validar Autodiscover:

1. Abre o browser em https://testconnectivity.microsoft.com
2. Selecciona “Office 365” → “Autodiscover Outlook”
3. Introduz as credenciais da caixa de correio
4. O RCA simula o pedido Autodiscover completo e mostra onde falha

A documentação sobre conectividade de clientes no Exchange Online está em (Microsoft Learn — Clients and mobile in Exchange Online).

5.3 Verificar certificado TLS

Se a ligação HTTPS falha por certificado, testa com PowerShell:

O certificado deve ser emitido para *.outlook.com ou autodiscover.outlook.com por uma CA Microsoft (Microsoft IT CA ou DigiCert). Se o certificado for inválido ou diferente, pode haver um proxy SSL a interceptar o tráfego.

6. Passo 4 — Validar Autenticação Moderna (Modern Auth)

O Office 365 requer autenticação moderna (OAuth 2.0 / Modern Authentication). A autenticação básica (Basic Auth) foi descontinuada no Exchange Online em Outubro 2022. Se o Outlook tenta autenticar com Basic Auth, a ligação falha mesmo que o Autodiscover esteja correcto.

6.1 Verificar se Modern Auth está activa no tenant

Liga ao Exchange Online PowerShell:

O valor esperado é True. Se for False, activa:

6.2 Verificar chaves de registo de autenticação no cliente

No computador cliente, verifica se há chaves que forçam autenticação básica:

A chave EnableADAL deve ser 1 (activa Modern Auth). Se for 0 ou não existir em clientes antigos, o Outlook pode estar a tentar Basic Auth.

6.3 Tabela de Diagnóstico de Autenticação

7. Passo 5 — Diagnosticar com Test-OutlookWebServices

O cmdlet Test-OutlookWebServices (disponível no Exchange Online PowerShell) testa o fluxo Autodiscover end-to-end — simula um pedido real de cliente e verifica a resposta.

O output mostra cada passo do fluxo Autodiscover:

Se o resultado for Failure, o campo Error contém a mensagem específica. Os erros mais comuns:

8. Passo 6 — Verificar Conditional Access e Firewall

Mesmo com DNS, SCP, HTTPS e autenticação correctos, políticas de Conditional Access no Microsoft Entra ID podem bloquear a ligação Autodiscover.

8.1 Verificar políticas de Conditional Access

No portal Microsoft Entra (entra.microsoft.com), navega para Protection → Conditional Access. Verifica se há políticas que:

• Bloqueiam ligações de IPs não confiáveis
• Exigem dispositivo compliant (Intune) para aceder ao Exchange Online
• Exigem MFA que o cliente Outlook não consegue satisfacer (ex: certificado de hardware)

Uma política mal configurada pode bloquear o Autodiscover mesmo que toda a infraestrutura DNS/SCP/HTTPS esteja correcta.

8.2 Verificar endpoints necessários no firewall

Os endpoints que o Outlook precisa de aceder para Autodiscover no Office 365:

A lista completa e actualizada de endpoints está em (Microsoft Learn — URLs e IP ranges O365).

8.3 Testar conectividade a todos os endpoints

Para testar rapidamente todos os endpoints numa só execução:

9. Outras Causas de Falha do Autodiscover

Nem todos os problemas de Autodiscover vêm de DNS, SCP ou autenticação. Outras causas a considerar:

• Proxy HTTP com autenticação: Se a organização usa proxy com autenticação, o Outlook pode não conseguir enviar credenciais do proxy ao pedido Autodiscover. Verificar definições de proxy em Settings → Network → Proxy, e a variável de ambiente HTTP_PROXY. Documentado em (Microsoft Learn — Outlook troubleshooting).
• Perfil Outlook corrupto: Um perfil existente com cache de Autodiscover antigo pode impedir a descoberta correcta. Solução: criar perfil novo em Control Panel → Mail → Show Profiles → Add.
• Domínio não verificado no tenant: Se o domínio ainda não foi verificado no Microsoft 365 admin center, o Autodiscover responde mas não encontra a caixa. Verificar em admin.microsoft.com → Settings → Domains.
• Split-brain DNS: Se o DNS interno resolve autodiscover.dominio.pt para um IP diferente do DNS público, o Outlook no escritório pode ir para o servidor errado. Verificar com Resolve-DnsName de dentro e fora da rede corporativa.
• Cached Exchange Mode com cache corrompido: Mesmo que o Autodiscover funcione, um cache OST corrompido impede a sincronização. Sintoma diferente de Autodiscover mas muitas vezes confundido. Correr Outlook.exe /cleanprofile ou recriar o perfil.
• Versão do Outlook desactualizada: Outlook 2010 e 2013 não suportam Modern Auth correctamente sem patches específicos. Mínimo recomendado: Outlook 2016 com as últimas actualizações, ou Microsoft 365 Apps.

10. Como Evitar Problemas de Autodiscover no Futuro

Práticas para manter o Autodiscover saudável em ambientes migrados para O365:

• Documentar a transição: Quando migrar de Exchange on-premises para O365, documentar o processo de remoção de SCPs. Sem documentação, os SCPs esquecidos causam problemas meses depois.
• Remover SCPs antes de descomissionar: Remover todos os SCPs de Autodiscover do AD antes de desligar o último Exchange on-premises. Se não o fizeres, os clientes continuam a tentar ligar a um servidor que já não existe.
• Monitorizar registos DNS: Configurar alertas para mudanças no registo CNAME autodiscover. Uma alteração acidental neste registo quebra todos os clientes Outlook do domínio.
• Manter Office actualizado: As últimas versões do Outlook 2016+ suportam Modern Auth nativamente. Versões mais antigas exigem patches específicos e configuração manual de chaves de registo.
• Testar com RCA antes de abrir tickets: O Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com) identifica o problema em 2 minutos e gera um relatório que podes anexar ao ticket de suporte, reduzindo o tempo de resolução.
• Usar perfis de teste: Manter uma conta de teste no tenant para validar o fluxo Autodiscover periodicamente. Se essa conta configurar automaticamente, o Autodiscover está funcional.

Checklist Antes de Aplicar em Produção

Antes de aplicar qualquer comando deste artigo em ambiente produtivo, confirma:

1. Versão do Outlook no cliente (mínimo 2016 com últimas actualizações, recomendado Microsoft 365 Apps): verificar em File → Office Account → About Outlook
2. Domínio verificado no tenant (admin.microsoft.com → Settings → Domains): o domínio da caixa de correio deve estar verificado
3. Ligação ao Exchange Online PowerShell disponível (para Passos 5 e 6): Connect-ExchangeOnline com conta admin
4. Permissões de admin no Active Directory (para Passo 2 — SCPs): Domain Admin ou delegação na OU dos servidores Exchange
5. Staging environment disponível — um cliente de teste e uma conta de teste no tenant para validar o fluxo antes de aplicar mudanças a todos os utilizadores
6. Backup do estado antes de alterar registos DNS ou remover SCPs: export dos registos DNS atuais e screenshot dos SCPs do AD antes de remover

Artigos Relacionados

• Autodiscover Outlook: Falha e Diagnóstico DNS — Artigo base sobre diagnóstico de DNS para Autodiscover, complementar a este para casos onde o problema é especificamente DNS
• Autodiscover Outlook: Office 365 vs Hosted Exchange — Guia sysadmin sobre diferenças entre Autodiscover O365 e Hosted Exchange, útil quando se migra de um fornecedor para outro
• Outlook Caixa de Correio Temporária ao Adicionar Domínio O365 — Sintoma específico onde o Outlook cria uma caixa temporária em vez de ligar ao O365, causado por registo Autodiscover incorrecto
• Problemas Email Microsoft Hotmail Outlook M365 — Visão geral de problemas de email em contas Microsoft, inclui cenários de Autodiscover para contas pessoais