Email de aplicações e dispositivos no Microsoft 365: o que verificar antes da alteração de dezembro de 2026

Antes de aprovar alterações a um digitalizador, sistema de faturação ou aplicação de relatórios, confirme se envia através do Exchange Online com a autenticação básica do SMTP AUTH. É essa dependência específica que será afetada pela alteração da Microsoft em dezembro de 2026. O facto de uma organização utilizar o Microsoft 365 não permite saber como cada aplicação envia as suas mensagens.

A tarefa prática consiste em identificar os remetentes afetados, confirmar uma opção compatível para continuar e verificar uma mensagem empresarial representativa antes de alterar a configuração ativa. Assim, o responsável ou quem aprova o orçamento pode decidir que trabalho é necessário.

O que muda no final de dezembro

O calendário atualizado do SMTP AUTH da Microsoft indica que o comportamento se mantém inalterado até ao final de dezembro de 2026. No final desse mês, a autenticação básica do SMTP AUTH será desativada por predefinição nos tenants existentes. Os administradores poderão continuar a ativá-la quando necessário. Esta alteração da predefinição é independente da remoção final.

Nos novos tenants criados após dezembro de 2026, não estará disponível por predefinição, sendo o OAuth o método de autenticação suportado. A Microsoft afirma que anunciará a data da remoção final no segundo semestre de 2027. Esse é o período em que será anunciada uma data, não a data da remoção.

Este calendário diz respeito à autenticação básica do SMTP AUTH no Exchange Online. Não significa que o SMTP vá terminar nem que todas as caixas de correio e dispositivos Microsoft 365 tenham a mesma dependência. O calendário revisto dá tempo para preparação, mas continua a haver uma alteração concreta de configuração a avaliar.

Comece pela mensagem empresarial

Para cada mensagem importante, peça ao fornecedor ou ao administrador que confirme o percurso real de envio. Uma aplicação de faturação pode enviar diretamente para o Exchange Online, utilizar um relay local ou enviar através do serviço do fornecedor. São exemplos hipotéticos e cada um exige provas diferentes. O endereço Microsoft 365 no campo do remetente, por si só, não permite concluir qual é o percurso.

Mantenha um inventário breve com estes campos:

• Mensagem empresarial: o que é enviado, quando é necessário e que anexo ou conteúdo é importante.
• Remetente e percurso: a aplicação ou dispositivo, o serviço de envio efetivo e o método de autenticação.
• Destinatários: pessoas dentro da organização, destinatários externos ou ambos.
• Responsável pelo sistema: a pessoa responsável pelo remetente e pela relação com o fornecedor.
• Opção de continuidade: o percurso suportado e quaisquer questões de compatibilidade ou configuração por resolver.
• Responsável pela verificação: a pessoa que confirmará que a mensagem necessária chega ao destinatário.

Registe explicitamente as incógnitas e atribua a alguém a tarefa de as resolver. Assim, é possível distinguir uma dependência confirmada da autenticação básica de um remetente que exige uma análise separada. Também dá aos fornecedores uma pergunta específica para responder antes de uma compra ou alteração de configuração.

Escolha o percurso em função dos destinatários e do alojamento

O envio SMTP pelo cliente com OAuth é uma opção possível para continuar. A documentação de OAuth para SMTP da Microsoft descreve o suporte de autenticação, incluindo o registo da aplicação e os tokens. A aplicação ou o dispositivo em causa tem de implementar o suporte necessário, e a configuração do tenant tem de permitir a sua utilização. A afirmação de que um produto «suporta SMTP» é demasiado abrangente para confirmar a compatibilidade. Pergunte ao fornecedor pelo modelo ou versão exatos.

As orientações da Microsoft para envio por aplicações e dispositivos distinguem os percursos pelo alcance dos destinatários e pelos requisitos operacionais. O envio de cliente e o relay por conector, quando elegíveis, podem chegar a destinatários internos e externos. High Volume Email e Direct Send são opções apenas para destinatários internos nessa comparação. Os limites de destinatários excluem faturas ou lembretes a clientes externos à organização.

O relay por conector tem condições próprias. Exige um conector de entrada, autenticação com um certificado ou endereço IP público estático adequado e disponibilidade da porta 25. A Microsoft exclui desta opção o relay através de serviços alojados por terceiros, como o Azure. Por isso, é necessário verificar o alojamento de uma aplicação na cloud antes de considerar o relay por conector como opção.

O Direct Send também implica responsabilidades de administração do servidor de correio. Outro serviço de envio, incluindo a alternativa Azure Communication Services descrita pela Microsoft para correio interno e externo, exige a sua própria avaliação de compatibilidade e operação. A lista de destinatários, o ambiente de alojamento e o suporte disponível determinam as opções que devem ser investigadas. A substituição de hardware é uma decisão a justificar depois de verificar as opções suportadas.

Verifique a mensagem antes da alteração em produção

Defina quem fará a alteração, quem verificará o resultado empresarial e quem tratará das falhas posteriormente. Utilize uma mensagem representativa com a identidade do remetente, o conteúdo e o anexo necessários. Acompanhe-a desde o envio até à receção pelo destinatário previsto, incluindo um destinatário externo quando o processo empresarial o exigir.

Uma autenticação bem-sucedida confirma apenas uma parte do percurso. A confirmação de suporte do fornecedor e um teste de ligação bem-sucedido do administrador também têm de ser seguidos pela verificação da receção empresarial. Agende a alteração em produção quando estiverem claros a dependência, o percurso compatível e as responsabilidades de verificação.

Se precisar de ajuda para avaliar os requisitos de uma aplicação ou dispositivo que envia mensagens, podemos conversar sobre o âmbito através do nosso serviço de infraestrutura de email.