Já mostramos aqui no blog da VM SERV como liberar permissão de envio para caixas compartilhadas. Mas e quando o endereço em questão não é uma caixa compartilhada, e sim um Grupo? O processo é diferente — e o Exchange Online costuma confundir bastante gente nessa hora, porque o erro retornado não deixa claro qual cmdlet usar.

Neste artigo, mostramos o passo a passo para identificar corretamente o tipo do objeto e aplicar a permissão certa.

O problema

Um cenário comum: você precisa que um colaborador consiga enviar e-mails em nome de um endereço como [email protected]. O primeiro instinto é usar o cmdlet de caixa de correio:

powershell

Set-Mailbox -Identity "[email protected]" `
  -GrantSendOnBehalfTo @{add="[email protected]"}

Só que, se o endereço for um grupo, o comando falha:

Write-ErrorMessage : ||Não foi possível executar a operação porque não foi possível encontrar o objeto
'[email protected]' [...] ManagementObjectNotFoundException

Isso acontece porque Set-Mailbox só reconhece caixas de correio reais (usuário ou compartilhada). Grupos não aparecem para esse cmdlet.

Passo 1 — Descubra o tipo real do objeto

Antes de tentar qualquer cmdlet, identifique o que você está lidando:

powershell

Get-Recipient -Identity "[email protected]" | Select-Object Name, RecipientTypeDetails

O valor de RecipientTypeDetails indica o caminho a seguir:

RecipientTypeDetails	O que é	Cmdlet correto
UserMailbox / SharedMailbox	Caixa de correio	Set-Mailbox
MailUniversalDistributionGroup / MailUniversalSecurityGroup	Grupo de distribuição clássico	Set-DistributionGroup
GroupMailbox	Microsoft 365 Group (grupo unificado)	Set-UnifiedGroup ou Add-RecipientPermission
DynamicDistributionGroup	Grupo de distribuição dinâmico	Não suporta GrantSendOnBehalfTo diretamente

Passo 2 — Se for um grupo de distribuição clássico

powershell

Set-DistributionGroup -Identity "[email protected]" `
  -GrantSendOnBehalfTo @{add="[email protected]"}

Esse comando funciona bem para MailUniversalDistributionGroup e MailUniversalSecurityGroup.

Passo 3 — Se for um Microsoft 365 Group (GroupMailbox)

Se o RecipientTypeDetails retornar GroupMailbox, nem Set-Mailbox nem Set-DistributionGroup vão funcionar. Tentar Set-DistributionGroup nesse caso retorna:

Write-ErrorMessage : ||Não há suporte para a operação atual no GroupMailbox.

O motivo é que Microsoft 365 Groups (também chamados de “grupos unificados”) têm cmdlets próprios, separados dos grupos de distribuição tradicionais. O cmdlet correto é Set-UnifiedGroup:

powershell

Set-UnifiedGroup -Identity "[email protected]" `
  -GrantSendOnBehalfTo @{add="[email protected]"}

Esse comando resolve o caso do GroupMailbox diretamente, mantendo o mesmo comportamento de “Send on Behalf” (o destinatário vê “Fulano em nome de Grupo”).

Se Set-UnifiedGroup não estiver disponível ou não aceitar o parâmetro

Em alguns tenants ou versões, -GrantSendOnBehalfTo pode não estar habilitado para GroupMailbox. Nesse caso, uma alternativa é conceder permissão de “Send As”:

powershell

Add-RecipientPermission -Identity "[email protected]" `
  -Trustee "[email protected]" `
  -AccessRights SendAs

Diferença entre as duas abordagens:

• Send on Behalf (Set-UnifiedGroup) exibe “Fulano em nome de Grupo” no destinatário.
• Send As (Add-RecipientPermission) faz o e-mail parecer enviado diretamente pelo endereço do grupo, sem indicar o remetente real.

Alternativa: associar o usuário ao grupo

Vale lembrar que, para Microsoft 365 Groups, membros (ou proprietários) geralmente já conseguem enviar como o grupo diretamente pelo Outlook/Outlook Web, dependendo de como a organização configurou o acesso. Se o objetivo for uma permissão permanente e o colaborador realmente fizer parte da comunicação daquele grupo, avaliar a inclusão como membro pode ser mais simples do que configurar permissões via PowerShell.

Resumo rápido

1. Sempre rode Get-Recipient antes de qualquer alteração, para confirmar o RecipientTypeDetails.
2. Caixa de correio (usuário ou compartilhada) → Set-Mailbox.
3. Grupo de distribuição clássico → Set-DistributionGroup.
4. Microsoft 365 Group (GroupMailbox) → Set-UnifiedGroup (ou, se não suportado, Add-RecipientPermission com -AccessRights SendAs).

Identificar o tipo correto do objeto antes de agir evita boa parte da tentativa e erro no Exchange Online — e economiza tempo (e paciência) na hora de liberar acessos.