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.

⚠ **Atenção

** Se o domínio foi recentemente migrado de Exchange on-premises para Exchange Online, os registos SCP (Service Connection Point) no Active Directory local podem estar a direccionar o Outlook para o servidor Exchange antigo em vez do Office 365. Este é o problema mais comum e está coberto no Passo 2.

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:

Ordem Método O que faz Tempo típico
1 SCP (Service Connection Point) Consulta o Active Directory local por um objecto que aponta para o servidor Exchange <1 segundo
2 DNS — registo CNAME autodiscover Resolve autodiscover.dominio.pt via DNS público 1-3 segundos
3 HTTPS — autodiscover.dominio.pt Liga a https://autodiscover.dominio.pt/autodiscover/autodiscover.xml 2-5 segundos
4 HTTPS — autodiscover.outlook.com Liga ao endpoint cloud da Microsoft 2-5 segundos

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:

# Substituir dominio.pt pelo domínio real
Resolve-DnsName -Name autodiscover.dominio.pt -Type CNAME

Testado em: sintaxe validada contra Microsoft Learn — Resolve-DnsName, Julho 2026.

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

Name Type TTL Value
—- —- — —–
autodiscover.dominio.pt CNAME 3600 autodiscover.outlook.com

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:

# Resolver o CNAME até ao IP final
Resolve-DnsName -Name autodiscover.dominio.pt -Type CNAME
Resolve-DnsName -Name autodiscover.outlook.com -Type A

Testado em: sintaxe validada contra Microsoft Learn — Resolve-DnsName, Julho 2026.

3.3 Verificar com nslookup (alternativa)

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

nslookup -type=CNAME autodiscover.dominio.pt
nslookup autodiscover.outlook.com

Testado em: sintaxe validada contra Microsoft Learn — nslookup, Julho 2026.

3.4 Tabela de Diagnóstico DNS

Resultado Diagnóstico Acção
CNAME → autodiscover.outlook.com Correcto — O365 Avançar para Passo 2
CNAME → outro servidor Registo aponta para servidor errado Corrigir CNAME no painel de DNS
CNAME não existe (NXDOMAIN) Registo em falta Criar CNAME: autodiscover → autodiscover.outlook.com
CNAME → autodiscover.dominio.local Aponta para Exchange on-premises Remover e redireccionar para O365
A record em vez de CNAME Configuração incorrecta Substituir A por CNAME para autodiscover.outlook.com

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:

# Listar todos os SCPs de Autodiscover no domínio
Get-ADObject -Filter “objectClass -eq ‘serviceConnectionPoint’ -and Name -like ‘*Autodiscover*'” -Properties serviceBindingInformation | Select-Object Name, serviceBindingInformation, DistinguishedName

Testado em: sintaxe validada contra Microsoft Learn — Get-ADObject, Julho 2026.

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

(nenhum resultado — sem SCPs de Autodiscover)

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:

# Verificar a chave de registo que o Outlook consulta
Get-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover” -ErrorAction SilentlyContinue

Testado em: sintaxe validada contra Microsoft Learn — registry Autodiscover, Julho 2026.

As chaves que podem estar a interferir:

Chave de registo Efeito se presente
SCPDefaultCFG Força Outlook a usar SCP específico
ExcludeScpLookup = 1 Ignora SCP (útil para teste — ver 4.4)
ExcludeExplicitO365Endpoint = 1 Impede Outlook de tentar O365 directamente

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:

# Remover SCP do servidor Exchange descomissionado
$scp = Get-ADObject -Filter “objectClass -eq ‘serviceConnectionPoint’ -and Name -like ‘*Autodiscover*’ -and serviceBindingInformation -like ‘*dominio.local*'”
Remove-ADObject -Identity $scp -Confirm:$false

Testado em: sintaxe validada contra Microsoft Learn — Remove-ADObject, Julho 2026.

⚠ **Atenção

** Remover SCPs do Active Directory afecta todos os clientes Outlook do domínio. Testar numa OU de staging primeiro. Se ainda existem caixas de correio on-premises (cenário híbrido), NÃO remover os SCPs — ajustar para apontar ao servidor Exchange híbrido correcto.

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:

# Bypass SCP — forçar Outlook a ir directamente ao DNS
Set-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover” -Name “ExcludeScpLookup” -Value 1 -Type DWord

Testado em: sintaxe validada contra Microsoft Learn — ExcludeScpLookup, Julho 2026.

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:

Remove-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover” -Name “ExcludeScpLookup” -ErrorAction SilentlyContinue

Testado em: sintaxe validada contra Microsoft Learn — Remove-ItemProperty, Julho 2026.

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:

# Testar conectividade TCP ao endpoint Autodiscover do O365
Test-NetConnection -ComputerName autodiscover.outlook.com -Port 443

Testado em: sintaxe validada contra Microsoft Learn — Test-NetConnection, Julho 2026.

Output esperado:

ComputerName : autodiscover.outlook.com
RemoteAddress : 52.97.x.x
RemotePort : 443
InterfaceAlias : Ethernet
SourceAddress : 192.168.x.x
TcpTestSucceeded : True

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:

# Testar handshake TLS
$tcp = New-Object System.Net.Sockets.TcpClient(“autodiscover.outlook.com”, 443)
$ssl = New-Object System.Net.Security.SslStream($tcp.GetStream(), $false, { $true })
$ssl.AuthenticateAsClient(“autodiscover.outlook.com”)
$ssl.RemoteCertificate.Subject
$tcp.Close()

Testado em: sintaxe validada contra Microsoft Learn — SslStream, Julho 2026.

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:

# Ligar ao Exchange Online
Connect-ExchangeOnline

# Verificar estado de Modern Auth
Get-OrganizationConfig | Select-Object OAuth2ClientProfileEnabled

Testado em: sintaxe validada contra Microsoft Learn — Get-OrganizationConfig, Connect-ExchangeOnline, Julho 2026.

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

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Testado em: sintaxe validada contra Microsoft Learn — Set-OrganizationConfig, Julho 2026.

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:

# Verificar chaves de autenticação
Get-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Office\16.0\Common\Identity” -ErrorAction SilentlyContinue

Testado em: sintaxe validada contra Microsoft Learn — Office Identity registry, Julho 2026.

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

Sintoma Causa provável Resolução
Popup de credenciais repetido Basic Auth descontinuado Verificar EnableADAL=1, actualizar Office
“A ligação ao Exchange não está disponível” Modern Auth não activa no tenant Activar via Set-OrganizationConfig (ver secção 6.1)
Erro 0x8004deb5 Problema token AAD Limpar cache: dplickey no cliente
Erro 0x800CAA01 Token expirado / MFA interrompe Re-autenticar: fechar Outlook, limpar credenciais Windows
Funciona no browser (OWA) mas não no Outlook Cliente não suporta Modern Auth Actualizar para Office 2016+ ou Microsoft 365 Apps

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.

# Ligar ao Exchange Online
Connect-ExchangeOnline

# Testar Autodiscover para uma caixa de correio específica
Test-OutlookWebServices -Identity “[email protected]” | Format-List

Testado em: sintaxe validada contra Microsoft Learn — Test-OutlookWebServices, Julho 2026.

O output mostra cada passo do fluxo Autodiscover:

Id : 1
Type : Autodiscover
Result : Success
Error :

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

Erro Significado Camada afectada
The Autodiscover service couldn't be located DNS ou SCP incorrectos Passo 1 ou 2
The remote server returned an error: (401) Unauthorized Autenticação falhou Passo 4
The remote server returned an error: (403) Forbidden Acesso bloqueado / CA policy Passo 4 ou firewall
Could not establish trust relationship Certificado TLS inválido Passo 3
The operation has timed out Firewall/proxy a bloquear Passo 3

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:

Endpoint Protocolo Porta Uso
autodiscover.outlook.com HTTPS 443 Autodiscover principal
outlook.office365.com HTTPS 443 Ligação MAPI/HTTP à caixa
outlook.office.com HTTPS 443 Outlook na web (OWA)
login.microsoftonline.com HTTPS 443 Autenticação OAuth/Modern Auth
*.protection.outlook.com HTTPS 443 Anti-spam/anti-malware

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:

$endpoints = @(
“autodiscover.outlook.com”,
“outlook.office365.com”,
“outlook.office.com”,
“login.microsoftonline.com”
)
foreach ($ep in $endpoints) {
$result = Test-NetConnection -ComputerName $ep -Port 443 -WarningAction SilentlyContinue
Write-Host “$ep : TcpTest=$($result.TcpTestSucceeded) IP=$($result.RemoteAddress)”
}

Testado em: sintaxe validada contra Microsoft Learn — Test-NetConnection, Julho 2026.

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.

Nota de Transparência

Resumo Rápido de Confiança

Componente do artigo Confiança Requer staging antes de produção?
Sintaxe dos cmdlets PowerShell Alta — verificada contra Microsoft Learn Não
Fluxo de descoberta Autodiscover (SCP → DNS → HTTPS) Alta — baseado em documentação oficial Exchange Não
Comandos DNS (nslookup, Resolve-DnsName) Alta — validados contra Microsoft Learn Não
Verificação SCP (Get-ADObject, Remove-ADObject) Média — sintaxe validada, sem execução em AD real Sim
Test-OutlookWebServices Média — sintaxe validada, sem execução em tenant real Sim
Configuração de registo (ExcludeScpLookup, EnableADAL) Média — chaves validadas, sem teste em cliente real Sim

O que FOI Verificado (auditoria de fontes)

  • 8 URLs Microsoft Learn validadas a 200 OK em 2026-07-16:
  • learn.microsoft.com/en-us/exchange/architecture/client-access/autodiscover (Autodiscover overview)
  • learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges (endpoints O365)
  • learn.microsoft.com/en-us/exchange/troubleshoot/ (Exchange troubleshooting hub)
  • learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/ (clients Exchange Online)
  • learn.microsoft.com/en-us/exchange/architecture/client-access/ (client access architecture)
  • learn.microsoft.com/en-us/outlook/troubleshoot/ (Outlook troubleshooting hub)
  • learn.microsoft.com/en-us/powershell/module/exchange/test-outlookwebservices (cmdlet reference)
  • learn.microsoft.com/en-us/powershell/module/exchange/get-autodiscovervirtualdirectory (cmdlet reference)
  • Sintaxe de 12+ cmdlets PowerShell verificada: Resolve-DnsName, Test-NetConnection, Test-OutlookWebServices, Get-ADObject, Remove-ADObject, Get-OrganizationConfig, Set-OrganizationConfig, Connect-ExchangeOnline, Get-ItemProperty, Set-ItemProperty, Remove-ItemProperty.
  • Auditoria kbase.pt (sitemap com 360+ artigos): existem 4 artigos relacionados — autodiscover-outlook-falha-diagnostico-dns (diagnóstico DNS), autodiscover-outlook-office365-vs-hosted-exchange-guia-sysadmin (comparação O365 vs Hosted), outlook-caixa-correio-temporaria-dominio-o365-autodiscover (caixa temporária), problemas-email-microsoft-hotmail-outlook-m365 (problemas gerais email). Este artigo é complemento que estrutura o diagnóstico como fluxo sequencial em 6 passos, cobrindo SCP e Conditional Access que os artigos existentes não abordam.

O que NÃO foi testado em ambiente real (e o que isso significa)

Componente Estado Implicação prática
Consulta DNS CNAME autodiscover Não testado em domínio real Sintaxe validada. Aplicar com domínio real para confirmar.
Remoção de SCPs do Active Directory Não testado Sintaxe validada. Aplicar em ambiente de staging antes de remover de produção.
Test-OutlookWebServices em tenant O365 Não testado Sintaxe validada. Requer ligação ao Exchange Online PowerShell com conta admin.
Chaves de registo ExcludeScpLookup / EnableADAL Não testado em cliente real Valores validados contra Microsoft Learn. Testar num cliente piloto antes de aplicar via GPO.
Conectividade HTTPS a endpoints O365 Não testado Endpoints documentados. Validar a partir da rede interna do cliente.
Conditional Access a bloquear Autodiscover Não testado Cenário documentado. Verificar políticas no portal Entra caso o fluxo Autodiscover funcione mas a ligação final falhe.

Ambiente de Teste e Validade

  • Data de redação: 2026-07-16
  • Hardware usado para validação: apenas validação documental (Microsoft Learn, web search). Nenhum dos comandos foi executado em ambiente Exchange Online ou Active Directory real durante a redação deste artigo.
  • Público-alvo: sysadmins Exchange Online e Microsoft 365 em PMEs com experiência intermédia. Para contexto sobre Autodiscover em migrações, ler primeiro o artigo Autodiscover Outlook: Falha e Diagnóstico DNS.
  • Validade: até Janeiro 2028 (18 meses). Razões pelas quais pode necessitar actualização antes: (1) Outlook New (versão web) pode alterar o fluxo Autodiscover, (2) Exchange Online continua a receber actualizações de protocolo trimestrais, (3) Conditional Access pode receber novas controls que afectam Autodiscover, (4) Microsoft Entra ID pode substituir a autenticação Modern Auth por algo novo, (5) Descontinuação do Outlook 2016 — sem suporte Modern Auth nativo pode mudar requisitos mínimos.

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

⚠ ⚠️ Comandos que afectam o Active Directory (e.g. Remove-ADObject para SCPs) ou o

Artigos Relacionados