Visão geral

Dentro de Definições → Configuração de Email, o campo Provedor Ativo passa a controlar dois modos diferentes. Se o vosso fornecedor entrega host, porto, username e password, o caminho é SMTP. Se a conta operacional está em Microsoft 365 / Entra ID, o setup é feito por aplicação em Azure e depois ligado ao Studio por Tenant ID, Client ID e Client Secret.

Dois protocolos
Backoffice
Testar antes de publicar

1

Vista da configuração no Studio

Os dois formulários reais

Configuração de email no Studio com o protocolo SMTP selecionado
Quando o Provedor Ativo está em SMTP, o Studio apresenta os campos de servidor, autenticação, remetente e nome do remetente.
Configuração de email no Studio com o protocolo Microsoft 365 selecionado
Quando o Provedor Ativo está em Microsoft 365, o formulário troca para credenciais de aplicação: Tenant ID, Client ID e Client Secret.
Importante: escolha apenas um protocolo ativo de cada vez, grave a configuração e use sempre o botão Testar para validar o envio antes de fechar a tarefa.
2

Quando usar cada protocolo

Decisão rápida

Use SMTP

Escolha esta opção quando o fornecedor vos entrega Mail Host, Mail Port, Mail Username e Mail Password. É o cenário mais comum para contas de envio tradicionais ou serviços externos de SMTP.

Use Microsoft 365

Escolha esta opção quando o envio deve ser autenticado pela infraestrutura da Microsoft da organização. Aqui o acesso não é feito por host e password, mas sim por uma App Registration criada em Azure.

  • Em ambos os casos, os campos Mail From e Mail From Name devem refletir o remetente real que os clientes vão ver.
  • O teste final deve ser feito depois de clicar em Guardar, para validar tanto autenticação como permissões de envio.
  • Se a organização usa Microsoft 365 com políticas internas, o consentimento de administrador pode ser obrigatório para o fluxo funcionar.
3

Configurar via SMTP

Fluxo base no backoffice

Mail Host

Servidor de envio SMTP. Exemplos comuns: smtp.gmail.com ou smtp.office365.com, conforme o fornecedor.

Mail Port

Porta usada pelo serviço. Em muitos setups o valor é 587 com TLS, mas deve seguir a indicação real do fornecedor.

Mail Username

Conta usada para autenticação, normalmente o endereço de email completo que fará o envio.

Mail Password

Password da conta ou password de aplicação, quando o fornecedor exige autenticação reforçada.

Encryption

No ecrã base surge preenchido com tls. Mantenha esse valor quando for o protocolo pedido pelo vosso fornecedor.

Auth Mode

No fluxo standard do Studio o modo base é login. Só altere se o serviço SMTP vos tiver dado outra instrução explícita.

Mail From

Email remetente que os clientes vão receber nas notificações, confirmações e fluxos automáticos.

Mail From Name

Nome visível do remetente, normalmente a marca, empresa ou identificação operacional do projeto.

Passo a passo SMTP

Selecione SMTP em Provedor Ativo e também na navegação lateral da própria configuração.

Preencha host, porto, utilizador e password do fornecedor, confirme Encryption e Auth Mode, defina Mail From e Mail From Name, depois clique em Guardar e Testar.

4

Configurar Microsoft 365 no Studio

Campos do backoffice

Tenant ID

Identificador do diretório Microsoft Entra ID. É copiado da página da aplicação em Azure depois do registo estar criado.

Client ID

Identificador da aplicação registada. No Azure aparece como Application (Client) ID.

Client Secret

Valor gerado em Certificates & secrets. Deve ser guardado logo no momento em que é criado, porque depois fica oculto.

Mail From

Conta de email que vai enviar as mensagens. Deve corresponder à conta permitida para o fluxo de envio.

Mail From Name

Nome visível do remetente que acompanhará os emails enviados pelo website.

Refrescar Token

Depois de inserir as credenciais da aplicação, este botão ajuda a atualizar o acesso antes do teste final.

  • No Studio, selecione Microsoft 365 como Provedor Ativo.
  • Cole Tenant ID, Client ID e Client Secret vindos do Azure.
  • Preencha Mail From e Mail From Name, use Refrescar Token se necessário, depois clique em Guardar e Testar.
Atenção: no Microsoft 365, o erro mais comum é colar o identificador do secret em vez do Client Secret Value. O Studio precisa do valor do secret, não do nome nem do ID interno.
5

Criar a app no Azure Portal

Tutorial Microsoft 365 com capturas

1. Abrir Azure Portal e criar a App Registration

Entre em portal.azure.com, procure App registrations e clique em New registration.

Defina um nome para a aplicação e, no campo de tipos de conta suportados, selecione a opção Any Entra ID Tenant + Personal Microsoft accounts, exatamente como indicado no fluxo do PDF.

Passo 1 do setup Microsoft 365 em Azure com App registrations e New registration
O primeiro passo do Azure é criar a aplicação e escolher o tipo de conta suportada correto para o envio.

2. Registar a aplicação e guardar Tenant ID + Client ID

Depois de clicar em Register, a aplicação fica criada. Nessa página copie os valores de Application (Client) ID e Directory (tenant) ID.

De seguida, abra Certificates & secrets, clique em New client secret, adicione uma descrição e, como referência do documento, escolha uma expiração de 24 months.

Passo 2 do setup Microsoft 365 com Client ID, Tenant ID e New Client Secret
A mesma zona do Azure mostra onde copiar o Client ID, o Tenant ID e onde criar o novo secret da aplicação.

3. Gerar o Client Secret e guardar o valor logo de imediato

Ao clicar em Add, o Client Secret Value fica disponível uma única vez. Copie-o imediatamente e guarde-o num local seguro para usar no Studio.

Sem esse valor não será possível completar a autenticação, e depois de sair da página o campo fica oculto.

Passo 3 do setup Microsoft 365 com criação do Client Secret e respetivo value
O documento reforça que o secret deve ser copiado no momento em que é criado, porque deixa de ser legível depois.

4. Adicionar a permissão Microsoft Graph Mail.Send

Abra API permissions, clique em Add a permission, escolha Microsoft Graph, depois Application permissions e procure Mail.Send.

Adicione a permissão e finalize com Grant admin consent for your organization, para que a aplicação possa enviar emails em nome da organização.

Passo 4 do setup Microsoft 365 com permissão Microsoft Graph Mail.Send
Sem a permissão Mail.Send e sem consentimento de administrador, a integração não fica operacional.

5. Voltar ao Studio, preencher os campos e testar

No Studio CMS, escolha Microsoft 365, cole Tenant ID, Client ID e Client Secret, defina Mail From e Mail From Name e use Refrescar Token se necessário.

Termine com Guardar e Testar para validar a configuração ainda no backoffice.

Passo 5 do setup Microsoft 365 já no Studio com o formulário preenchido
O fluxo fecha no Studio: preencher as credenciais da app, guardar a configuração e confirmar o envio no botão Testar.
6

Checklist final e troubleshooting

O que validar antes de fechar

Antes do teste

Confirme que o Mail From é coerente com a conta usada, que a configuração foi guardada e que o fornecedor permite envio externo a partir do website.

Se o teste falhar

Reveja porta e encriptação no SMTP, ou confirme no Microsoft 365 se o Client Secret ainda está válido, se a permissão Mail.Send foi dada e se o consentimento de administrador ficou concluído.

  • O envio de formulários e notificações depende desta configuração; não feche a tarefa sem um teste real.
  • Se o projeto trocar de fornecedor, atualize o protocolo ativo em vez de tentar misturar SMTP e Microsoft 365 na mesma configuração.
  • Em Microsoft 365, guarde sempre Tenant ID, Client ID e Client Secret Value antes de sair do Azure.
Recomendação: depois do teste técnico, submeta também um formulário real do website para confirmar que a notificação chega ao destinatário final e que o remetente aparece corretamente ao cliente.
7

Explorar também

Páginas relacionadas