O último dos sete formatos de caixa de e-mail, e o que tem mais trabalho de administrador. Conte com uma ida e volta com quem administra o seu tenant do Exchange.
O resumo do próprio assistente: “Escolha um Grupo do M365 com e-mail habilitado do qual você é membro. As respostas são publicadas na árvore de conversa do grupo.” E a restrição que decide se você pode começar — Grupo do M365 com e-mail habilitado · O usuário que conecta precisa ser membro.
Isto é somente trabalho/escola. Uma conta Microsoft de consumidor não tem nada disso.
Você conecta como membro, não como o grupo
Mesmo formato de o caminho do Grupo do Google: um grupo não é uma conta com que você faz login. Você faz login como você mesmo, e já precisa ser membro do grupo — o assistente lista os grupos a que você pertence, e se essa chamada falhar você recebe “Não foi possível listar seus grupos”.
A única permissão extra
Este é o único fluxo de e-mail que pede Group.ReadWrite.All além dos sete
padrão. É o que nos deixa ler a árvore de conversa do grupo e publicar
respostas nela. Uma conexão
pessoal do Outlook ou
de caixa compartilhada
nunca a pede.
As duas concessões únicas do administrador
Diferente dos outros caminhos da Microsoft, este mantém uma tela final de configuração, e ela traz um aviso intitulado Etapas únicas do administrador para habilitar envio + recebimento do grupo:
Para enviar e receber e-mail por este Grupo do M365, peça ao seu administrador do Exchange para fazer estas duas coisas no centro de administração do Exchange. As duas são únicas.
A. Saída (permissão de envio em nome de)
- Abra admin.cloud.microsoft/exchange → Destinatários → Grupos.
- Selecione este grupo na lista.
- Na aba Settings, ative “Let people outside the organization email this group” (obrigatório para entrada externa).
- Ainda em Settings, selecione Edit manage delegates.
- Em Add a delegate, informe o e-mail do usuário que conecta e escolha Send on behalf como tipo de permissão; depois, Save changes.
B. Entrada (inscrever o usuário no e-mail do grupo)
- Mesmo grupo → aba Members → confirme que o usuário que conecta aparece como membro (adicione, se não aparecer).
- Na aba Settings, garanta que “Send copies of group conversations and events to members’ inboxes” esteja ATIVADO (ou o equivalente por usuário: o usuário é um membro Subscribed).
- A Microsoft mantém em cache as consultas de permissão por ~15 minutos.
A etapa B explica a arquitetura, e vale ler em vez de apenas executar: “É assim que nosso app recebe a entrada — a Microsoft entrega uma cópia de cada e-mail do grupo na caixa de entrada de cada membro inscrito, e nós observamos a do usuário que conecta.” Se essas cópias param, a entrada para.
Sem a concessão de saída, o primeiro envio falha no lado da Microsoft com um 403 e nenhuma explicação útil, que é exatamente por que o aviso existe.
Os rascunhos se comportam diferente aqui
A única diferença funcional real, e a razão para ler isto antes de escolher o modo rascunho:
Os rascunhos ficam apenas no painel para Grupos do M365 — o Graph não tem API de thread de rascunho para conversas de grupo, então não enviamos uma cópia para a pasta de rascunhos do Outlook. Aprovar e enviar publica no grupo.
Então, em todas as outras caixas, uma resposta pendente também está na pasta de Rascunhos do provedor, onde um colega pode vê-la. Aqui não. O painel diz isso no próprio rascunho — “Aguardando sua revisão aqui: esta caixa de e-mail não tem uma pasta de Rascunhos própria” — e aprovar publica direto na conversa do grupo.
O que isso não faz
Isso não importa o histórico do grupo. A observação começa na conexão.
Isso para de funcionar se o membro sai. A conexão pega emprestadas a assinatura e a delegação de um membro. Remova-o do grupo, ou revogue a permissão de delegado, e a entrada e a saída falham independentemente uma da outra.
Isso não conserta o tenant por você. Cada etapa acima está no centro de administração da Microsoft; o assistente pode pedi-las e detectar a falha, não executá-las.