← Recursos Microsoft 365 · Segurança 11 de novembro de 2026 9 min de leitura
Microsoft 365: fim do SMTP AUTH básico e do MFA por SMS.
À data de 11 de novembro de 2026, o calendário oficial da Microsoft tem duas datas que tocam no dia a dia de uma PME: no fim de dezembro de 2026, o envio de email por SMTP AUTH com utilizador e palavra-passe (autenticação básica) fica desligado por defeito no Microsoft 365, e a 1 de fevereiro de 2027 a Microsoft deixa de enviar os códigos de autenticação por SMS e chamada de voz. A primeira afeta o ERP que envia faturas por email, as impressoras e os scanners; a segunda afeta quem entra no Microsoft 365 só com um código por SMS. Este guia diz o que muda, como descobrir quem é afetado e o que alterar antes de cada data.
Resposta direta: as datas oficiais
Estado a 11 de novembro de 2026, segundo as publicações da Microsoft listadas no fim da página. As duas mudanças são independentes: uma é do Exchange Online (envio de email), a outra do Microsoft Entra ID (início de sessão).
| Data | O que muda | Serviço |
|---|---|---|
| 1 de setembro de 2026 | Passkeys ativadas automaticamente para quem usa SMS ou voz, com convite a registar uma passkey no início de sessão | Entra ID |
| 30 de outubro de 2026 | Início da configuração de fornecedores de SMS e voz próprios através do Microsoft Security Store | Entra ID |
| Fim de dezembro de 2026 | SMTP AUTH com autenticação básica desligado por defeito nos tenants existentes; os administradores ainda o podem voltar a ligar | Exchange Online |
| Depois de dezembro de 2026 | Tenants novos já não têm autenticação básica no SMTP AUTH por defeito; o método suportado é OAuth | Exchange Online |
| 1 de fevereiro de 2027 | SMS e voz fornecidos pela Microsoft retirados para todos os utilizadores, exceto Global Administrators e utilizadores externos | Entra ID |
| 1 de julho de 2027 | SMS e voz retirados também para Global Administrators e utilizadores externos | Entra ID |
| 2.º semestre de 2027 | A Microsoft anuncia a data da remoção definitiva da autenticação básica no SMTP AUTH | Exchange Online |
O calendário do SMTP AUTH já mudou duas vezes. O primeiro anúncio apontava para setembro de 2025; a Microsoft passou-o depois para rejeições graduais entre 1 de março e 30 de abril de 2026; a 27 de janeiro de 2026 substituiu esse plano pelo atual. Esta página é atualizada se o calendário voltar a mudar.
O que muda no SMTP AUTH
O SMTP AUTH (ou «client submission») é o envio de email em que um programa ou equipamento
se liga a smtp.office365.com, normalmente na porta 587, e se autentica com a
conta de uma caixa de correio. A Microsoft descreve-o como o método usado por clientes POP e
IMAP e por aplicações, servidores de relatórios e equipamentos multifunções que geram e
enviam mensagens. O Outlook e as aplicações móveis atuais não o usam.
Há duas formas de autenticação neste envio. A básica envia utilizador e palavra-passe em cada ligação. A moderna (OAuth 2.0) usa um token temporário emitido pelo Microsoft Entra ID. O que a Microsoft desliga por defeito no fim de dezembro é a primeira. O SMTP AUTH com OAuth continua disponível.
Na prática, a partir do fim de dezembro, um equipamento ou programa que ainda envie com
utilizador e palavra-passe deixa de conseguir enviar, a menos que o administrador do tenant
volte a ligar a autenticação básica. Essa reativação é uma ponte, não uma solução: a
Microsoft já disse que vai anunciar a remoção definitiva no segundo semestre de 2027.
Quando essa remoção acontecer, a Microsoft indicou que os clientes com autenticação básica
recebem a resposta 550 5.7.30 Basic authentication is not supported for Client Submission.
Quem costuma ser afetado numa PME
- O ERP, quando envia faturas, notas de encomenda, recibos de vencimento ou alertas por email através de uma conta do Microsoft 365 configurada com servidor, porta, utilizador e palavra-passe.
- Impressoras multifunções e scanners com a função «digitalizar para email».
- Aplicações de negócio e scripts: software de faturação ou de armazém, portais internos, alarmes, NAS, sistemas de videovigilância e tarefas agendadas que enviam relatórios.
- Clientes de email POP ou IMAP antigos, que usam SMTP AUTH para enviar.
Como descobrir quem usa autenticação básica
- Relatório de clientes SMTP AUTH. No novo centro de administração do Exchange, em Relatórios > Fluxo de correio, o relatório «SMTP AUTH clients» mostra as contas que enviam por SMTP AUTH e se usam autenticação básica ou OAuth. Por defeito mostra os últimos 7 dias; convém olhar para um mês de fecho, quando o ERP envia mais.
- Definição do tenant. O comando
Get-TransportConfig | Format-List SmtpClientAuthenticationDisableddiz se o SMTP AUTH está ligado para a organização. Se os security defaults do Entra ID estiverem ativos, o SMTP AUTH já está desligado. - Exceções por caixa.
Get-CASMailboxmostra as caixas com o SMTP AUTH ligado ou desligado individualmente, que se sobrepõem à definição da organização. - Inventário no terreno. O relatório mostra a conta, não o equipamento. Cruzem cada conta com a lista de impressoras, servidores e programas que a usam.
As alternativas documentadas pela Microsoft
A escolha depende de uma pergunta: o equipamento ou programa envia só para dentro da empresa, ou também para clientes e fornecedores? O quadro resume as opções da documentação da Microsoft:
| Método | Destinatários externos | Requisitos | Quando faz sentido |
|---|---|---|---|
| SMTP AUTH com OAuth 2.0 | Sim | O programa ou equipamento tem de suportar OAuth; caixa licenciada; TLS 1.2 ou superior | Primeira opção, se o fabricante já a suporta |
| Relay SMTP por conector | Sim | Conector de entrada com certificado (recomendado) ou IP público fixo e não partilhado; porta 25; não serve para envio a partir de serviços alojados por terceiros, como o Azure | Impressoras e servidores na rede da empresa que não suportam OAuth |
| Azure Communication Services Email | Sim | Recurso no Azure, com custo próprio | Programas que precisam de enviar para fora e não suportam OAuth nem relay |
| High Volume Email | Não, só internos | Conta HVE; aceita autenticação básica até setembro de 2028 ou OAuth; cobrado por destinatário desde 1 de junho de 2026 | Notificações e alertas para colaboradores com caixa no tenant |
| Direct Send | Não, só caixas do próprio tenant | Porta 25; SPF, DKIM e DMARC bem configurados; sem autenticação | Último recurso; a Microsoft recomenda-o apenas a quem gere email como administrador de servidor |
Uma nota sobre o Direct Send. É envio anónimo, e a Microsoft criou em 2025 uma definição,
RejectDirectSend, que o bloqueia para quem não precisa dele; a 23 de setembro
de 2026 está em pré-visualização pública e desligada por defeito, e a documentação diz que a
Microsoft está a preparar uma opção para desligar o Direct Send por defeito. Quem mudar
equipamentos para Direct Send pode ter de os mudar outra vez. Para equipamentos na rede da
empresa, o relay por conector com certificado é o caminho mais estável.
O envio de email no ERP
No Cegid Primavera, o envio de documentos por email usa a conta e o servidor configurados
por cada empresa. Se essa configuração aponta para smtp.office365.com com
utilizador e palavra-passe, está no âmbito da mudança de dezembro. O que confirmar:
- Que conta envia. Muitas vezes é uma caixa partilhada ou uma conta «faturacao@» criada há anos, com a palavra-passe guardada no posto ou no servidor.
- Para quem envia. Faturas e notas de encomenda vão para fora da empresa: o High Volume Email não serve. Recibos de vencimento enviados para caixas dos colaboradores no mesmo tenant são destinatários internos.
- Que métodos a versão instalada suporta. Confirmem com o parceiro que método de autenticação a vossa versão suporta (a 11 de novembro de 2026 não há nota pública do Cegid Help Center sobre OAuth 2.0 no envio de email do Cegid Primavera; a resposta é dada caso a caso, com a versão instalada à frente).
- Onde corre o ERP. Se o servidor estiver na rede da empresa, com IP público fixo ou certificado, o relay por conector é uma alternativa. Se estiver alojado no Azure ou noutro serviço de terceiros, a Microsoft indica que o relay por conector não se aplica, e as opções passam a ser OAuth ou Azure Communication Services.
- Testar antes de dezembro. Enviar uma fatura de teste para um endereço externo e um recibo para um colaborador depois de cada alteração, e guardar o resultado.
Quem está a planear a saída do servidor local encontra o enquadramento no Pack Migração Cloud. O Windows Server 2016 também chega ao fim do suporte alargado a 12 de janeiro de 2027, e as duas mudanças tocam muitas vezes no mesmo servidor.
O que muda no MFA por SMS
A segunda mudança é no Microsoft Entra ID, o serviço de identidade do Microsoft 365. A Microsoft deixa de fornecer o envio de códigos por SMS e as chamadas de voz usadas como segundo fator. Não é o fim do MFA: é o fim de dois métodos, a favor das passkeys, que a Microsoft passou a tratar como método por defeito.
- 1 de setembro de 2026: quem tem SMS ou voz ativo passou a ter as passkeys ativadas e recebe um convite para as registar quando completa o MFA. Por defeito, o convite pode ser adiado sem limite.
- 1 de fevereiro de 2027: o SMS e a voz fornecidos pela Microsoft deixam de funcionar para todos os utilizadores, exceto Global Administrators e utilizadores externos. Os convidados internos ficam nesta data.
- Depois de 1 de fevereiro: quem só tiver SMS ou voz como método é obrigado a registar uma passkey no início de sessão antes de continuar. O pedido é bloqueante e não há forma de o desligar.
- 1 de julho de 2027: a mesma regra para Global Administrators e utilizadores externos.
A retirada aplica-se também à reposição de palavra-passe self-service (SSPR). Quem precisar de manter SMS ou voz, por razões regulatórias ou operacionais, pode contratar um fornecedor de telecomunicações através do Microsoft Security Store, com custo por mensagem; a configuração fica disponível a partir de 30 de outubro de 2026. Migrar para passkeys não tem custo adicional. Existe um adiamento temporário da ativação automática das passkeys, mas termina a 1 de fevereiro de 2027.
Para encontrar quem ainda usa SMS ou voz, a Microsoft disponibiliza um script de PowerShell (entra-sms-voice-usage-analyzer, no GitHub da Microsoft), que precisa de uma função de leitura como Global Reader ou Security Reader. Os casos que costumam aparecer numa PME são colaboradores que nunca instalaram o Microsoft Authenticator, contas partilhadas com o telemóvel de uma pessoa associado e administradores externos.
Checklist antes de dezembro e de fevereiro
- Extrair o relatório de clientes SMTP AUTH e listar as contas que usam autenticação básica.
- Ligar cada conta a um equipamento ou programa: ERP, impressoras, scanners, servidores, scripts.
- Decidir o método de cada um com o quadro acima: OAuth se suportado; relay por conector para equipamentos na rede; Azure Communication Services para envio externo sem OAuth; High Volume Email só para destinatários internos.
- Atualizar firmware e versões antes de mudar configurações: o suporte a OAuth chega muitas vezes numa atualização do fabricante.
- Criar conectores e registos SPF onde for preciso, com certificado ou IP fixo.
- Testar com envio interno e externo e guardar a prova.
- Correr o script de SMS e voz do Entra ID e identificar quem só tem esses métodos.
- Pedir o registo de passkeys por grupos, começando pelos administradores e pelas contas partilhadas, com uma comunicação curta aos colaboradores.
- Rever os Global Administrators: devem estar num método resistente a phishing muito antes de 1 de julho de 2027.
- Registar a data de cada mudança, para saber o que investigar se um envio falhar em janeiro.
A HeraPrime trabalha o Microsoft 365 como identidade e política, não como instalação: ver o que fazemos em Microsoft 365, Entra ID e Teams. Para o enquadramento de segurança, incluindo NIS2, ver cibersegurança.
Perguntas frequentes
Quando deixa de funcionar o SMTP AUTH com autenticação básica no Microsoft 365?
O ERP vai deixar de enviar faturas por email?
Posso usar o High Volume Email para enviar faturas a clientes?
O que muda no MFA por SMS a 1 de fevereiro de 2027?
É possível continuar a usar SMS depois de fevereiro de 2027?
Por onde começar numa PME?
Fontes consultadas (verificadas a 11 de novembro de 2026):
- Exchange Team, 27 de janeiro de 2026, «Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline»: autenticação básica desligada por defeito no fim de dezembro de 2026, reativável pelos administradores; tenants novos sem autenticação básica; remoção definitiva anunciada no 2.º semestre de 2027.
- Exchange Team, 15 de abril de 2024, atualizado a 27 de janeiro de 2026: calendário anterior (março e abril de 2026), endpoints afetados, resposta 550 5.7.30 e alternativas.
- Microsoft Learn, envio de email a partir de equipamentos multifunções e aplicações: comparação entre SMTP AUTH, relay por conector, Direct Send e High Volume Email.
- Microsoft Learn, ativar ou desativar o SMTP AUTH no Exchange Online: definição da organização, exceções por caixa e security defaults.
- Microsoft Learn, relatório de clientes SMTP AUTH no novo centro de administração do Exchange.
- Microsoft Learn, descontinuação da autenticação básica no Exchange Online (atualizado a 10 de julho de 2026).
- Exchange Team, High Volume Email: apenas destinatários internos e autenticação básica suportada até setembro de 2028.
- Microsoft 365 Blog, 31 de março de 2026: disponibilidade geral do High Volume Email e cobrança por destinatário desde 1 de junho de 2026.
- Exchange Team, Direct Send e RejectDirectSend (atualizado a 20 de maio de 2026).
- Microsoft Learn, passkeys por defeito e retirada do SMS e da voz fornecidos pela Microsoft (atualizado a 16 de setembro de 2026): calendário de 1 de setembro de 2026 a 1 de julho de 2027.
- Microsoft Learn, perguntas frequentes sobre a retirada do SMS e da voz: SSPR, custos do Security Store e âmbito.
- Microsoft Lifecycle, Windows Server 2016: fim do suporte alargado a 12 de janeiro de 2027.