A autenticação EAT do Outlook Actionable Messages não é mais aceita: migre para a autenticação por token do Microsoft Entra ID e valide, em ambiente controlado, a renderização do cartão, o token e o endpoint de ação como resultados separados. Essa orientação vale para equipes que mantêm uma integração própria e têm acesso a destinatários Microsoft 365 autorizados para o escopo de teste.
Desenvolvedores responsáveis pela migração podem usar as etapas para conferir a nova cadeia de autenticação.
QA pode separar mensagem recebida, cartão exibido e ação concluída.
Equipes que administram ambientes Microsoft 365 podem planejar destinatários de teste e critérios de liberação.
Última atualização: 25 de outubro de 2026. A data de migração e os requisitos descritos abaixo foram conferidos nas páginas oficiais da Microsoft sobre a migração para tokens do Entra ID, o Actionable Messages Developer Dashboard, a validação de tokens de acesso e os requisitos de segurança do Actionable Messages. Se a Microsoft alterar suporte, escopo de registro ou validação de tokens, revise as etapas afetadas antes de repetir a homologação.
Linha de partida: diferencie a falha antiga dos sintomas atuais
A Microsoft informa que concluiu a migração de EAT para autenticação por token do Microsoft Entra ID em 8 de junho de 2026 e que a autenticação antiga não é mais aceita. Portanto, se a integração ainda depende de EAT, a primeira ação é identificar e substituir esse mecanismo, não tentar recuperar o fluxo antigo por meio de ajustes no e-mail.
Antes de editar configurações, faça um inventário do que existe. Registre o tipo de autenticação usado, o identificador da aplicação, a configuração do provedor, os URLs de ação e a identidade de envio. Identifique também quem administra cada componente: equipe da aplicação, administradores do Microsoft 365 ou outro responsável autorizado. Isso evita que uma alteração em uma parte controlada por outro grupo seja tratada como correção local.
Abra um registro de teste com estados independentes:
- A mensagem não chegou: investigue envio, destinatário, filtros e fluxo de entrega.
- A mensagem chegou, mas o cartão não aparece: confira elegibilidade do destinatário, registro do provedor e suporte do cliente.
- O cartão aparece, mas a ação falha: registre a requisição recebida, o status devolvido pelo endpoint e o resultado da regra de negócio.
- A chamada chega ao servidor, mas é recusada: examine a validação do token e a autorização, sem presumir que o botão visível confirma uma autenticação válida.
Esses resultados não são intercambiáveis. Um e-mail na caixa de entrada prova que houve entrega para aquele destinatário; não prova que a autenticação do provedor funciona. Da mesma forma, um cartão visível não prova que o servidor verificou corretamente o token recebido.
Antes da mudança: registre uma referência que permita comparar e reverter
Monte uma referência do ambiente atual antes de alterar o registro ou a aplicação. Guarde a versão das configurações, os ambientes envolvidos, os URLs cadastrados e o comportamento observado em cada etapa. A referência não deve incluir tokens reais, segredos ou dados pessoais desnecessários. Para evidências de QA, prefira identificadores de teste e registros técnicos que não exponham credenciais.
Prepare um ambiente separado da produção e confirme que os destinatários estão autorizados para o escopo de teste aplicável. Não assuma que qualquer endereço capaz de receber uma mensagem serve como usuário de teste Microsoft 365. Um endereço temporário comum pode ajudar a observar o recebimento de mensagens em cenários compatíveis, mas não substitui os requisitos de uma conta organizacional elegível nem o registro oficial do provedor.
Confira também a identidade de envio e a configuração do domínio. O objetivo aqui não é usar um teste de recebimento como substituto da autenticação do Actionable Messages. É impedir que um problema de entrega masque a migração: se o destinatário não recebe a mensagem, ainda não há evidência para avaliar a renderização ou a ação.
| Componente | Registro antes da migração | Evidência a guardar |
|---|---|---|
| Autenticação | Mecanismo usado pela integração e local onde é configurado | Versão da configuração, sem segredos |
| Provedor | Registro existente e escopo de teste aplicável | Estado e dados necessários para comparação |
| Ação | URL ou URLs configurados e responsável pelo serviço | Resposta observada e logs sem credenciais |
| Envio | Identidade usada pelo serviço e ambiente que envia | Identificação da mensagem de teste e resultado de entrega |
| Destinatários | Contas autorizadas para o teste | Critério de elegibilidade e resultado por destinatário |
Essa tabela não define valores universais. O escopo, as aprovações e os campos exigidos dependem da configuração vigente e do tipo de implantação. Confirme-os no guia oficial do Developer Dashboard, em vez de reutilizar automaticamente parâmetros de outra integração.
Durante a migração: configure o registro e a autenticação pelo fluxo oficial
A migração envolve mais do que trocar um nome de mecanismo. A aplicação precisa obter e usar tokens do Microsoft Entra ID conforme o cenário documentado, e a configuração do provedor deve refletir os dados de autenticação correspondentes. Use o procedimento oficial para registrar a aplicação, definir seu identificador e configurar as permissões requeridas. Não copie permissões de outro produto ou de um ambiente sem verificar se se aplicam ao seu caso.
Depois, atualize o registro do provedor de Actionable Messages com as informações de autenticação exigidas. Confirme o escopo do registro: um teste limitado, um uso organizacional mais amplo e uma disponibilidade global não devem ser tratados como se tivessem o mesmo processo. A documentação atual determina os requisitos e eventuais aprovações aplicáveis. Se o escopo ainda não estiver claro, mantenha o teste restrito e peça confirmação aos administradores responsáveis antes de ampliar os destinatários.
O Actionable Message Developer Dashboard deve fazer parte da conferência do registro e da validação do cenário. Use-o para verificar os dados e o estado que a documentação associa ao provedor; não o trate como prova isolada de que uma ação real foi autorizada pelo serviço. A etapa do painel, a requisição ao endpoint e a lógica de negócio precisam de evidências próprias.
Para evitar uma falsa conclusão, anote o que mudou em cada componente e quem aprovou a alteração. Se uma aplicação for ajustada, mas o registro do provedor permanecer configurado para o mecanismo antigo, o comportamento ainda pode falhar. Se o registro for alterado, mas a aplicação não emitir ou não tratar os tokens esperados, a aparência da configuração não basta para validar a migração.
Antes de testar o cartão: valide o token no endpoint de ação
O endpoint é a fronteira de segurança da operação. Ele deve verificar o token recebido e sua aplicabilidade ao pedido antes de executar uma ação. A orientação da Microsoft sobre tokens de acesso e os requisitos de segurança do Actionable Messages devem orientar a implementação. Não trate a simples presença de um token como validação concluída.
Separe a verificação técnica da autorização de negócio. Primeiro, confirme que o servidor aplica os controles de token exigidos para o cenário e rejeita uma credencial inválida ou incompatível. Depois, verifique se uma requisição autenticada tem permissão para realizar aquela ação específica. Por fim, confirme que a regra de negócio aceita o estado solicitado. Uma requisição pode passar pela autenticação e ainda ser recusada corretamente pela aplicação.
| Caso controlado | O que o teste precisa demonstrar | Interpretação |
|---|---|---|
| Token inválido ou inaplicável | O endpoint não executa a ação | A validação de autenticação rejeitou o pedido |
| Permissão incompatível | A operação não é autorizada para aquele contexto | A autenticação não concedeu autorização de negócio |
| Pedido válido, mas regra de negócio recusada | O endpoint informa a recusa sem executar a operação | A regra da aplicação protege o estado do serviço |
| Pedido autorizado | A ação esperada ocorre e o resultado fica registrado | A cadeia foi validada para aquele caso de teste |
A tabela descreve resultados de teste, não um formato de token nem uma implementação pronta. A verificação detalhada deve seguir os requisitos oficiais aplicáveis. Evite registrar o conteúdo integral de credenciais em logs, capturas de tela ou tickets. Para investigar falhas, guarde identificadores de correlação, resultados de validação e respostas sanitizadas, sem transformar a evidência de QA em um risco de segurança.
Uma requisição HTTP enviada pelo botão é apenas evidência de que houve uma chamada. Para concluir que a autenticação passou, o servidor precisa validar o token e registrar o resultado dessa verificação antes de permitir a operação.
Depois da configuração: faça uma rodada de ponta a ponta com destinatários autorizados
Envie uma mensagem produzida pelo próprio serviço para destinatários aprovados para o escopo de teste. Use uma mensagem identificável e evite misturar resultados de vários ambientes ou destinatários no mesmo registro. Em cada execução, anote separadamente entrega, renderização, interação, chegada ao endpoint, validação do token e resultado da ação.
Comece pela caixa postal. Se a mensagem não chegou, pare a análise do cartão: ainda não há uma amostra válida para avaliar sua renderização. Registre o destinatário de teste, o horário da execução e o resultado observado. Para estruturar a separação entre recebimento e validação, a página sobre como verificar a chegada de e-mails de teste pode servir como referência complementar. Ela não substitui os requisitos de destinatário e registro da Microsoft.
Se a mensagem chegou, mas não mostrou o cartão, compare o destinatário usado com o escopo autorizado e revise o estado do registro do provedor. Em seguida, confira se o cliente está dentro das condições de suporte descritas pela Microsoft para o cenário testado. Não conclua que o endereço é a causa apenas porque outro destinatário se comportou de forma diferente. A elegibilidade pode depender do registro e do escopo, e o cliente pode afetar a exibição.
Se o cartão apareceu, teste o botão em um contexto seguro e observe a chamada ao endpoint. Um botão inativo, um erro de rede, uma resposta de autenticação e uma recusa de negócio são resultados distintos. Guarde o código e o conteúdo relevante da resposta sem segredos nem dados pessoais. Em seguida, relacione a chamada ao log do servidor para confirmar se a requisição chegou e em qual estágio foi aceita ou rejeitada.
A evidência de recebimento também precisa ser interpretada com cuidado. Uma caixa de entrada de teste ajuda a confirmar o que chegou naquele endereço; não confirma a autenticação do remetente, a adequação do destinatário ao escopo Microsoft 365 ou o processamento seguro pelo endpoint. Para organizar uma coleta de evidências sem confundir essas etapas, consulte o guia de recebimento em caixas de teste.
Decisão de liberação: mantenha o escopo ou volte uma etapa
Use estas condições antes de ampliar o uso:
- Se o provedor e a aplicação usam a autenticação por token configurada conforme a documentação, então execute a rodada de teste com destinatários autorizados; caso contrário, não trate o registro como migrado e volte à configuração.
- Se o cartão é exibido, mas a chamada não chega ao endpoint, então investigue interação, cliente e conectividade; caso contrário, avance para a análise da resposta do servidor.
- Se o endpoint rejeita credenciais inválidas e só permite operações autorizadas, então registre esses resultados e teste o caminho permitido; caso contrário, bloqueie a liberação e corrija a validação.
- Se mensagem, cartão, token e resultado da ação têm evidências separadas e coerentes, então solicite a ampliação gradual conforme o processo interno; caso contrário, mantenha o escopo de teste.
- Se a equipe não controla o destinatário, o registro ou o ambiente, então aguarde a autorização do responsável em vez de inferir que o teste é válido.
Na revisão antes da publicação, confira novamente as permissões, a identidade de envio e os URLs de ação. Compare os dados registrados com a configuração efetivamente implantada. Faça a ampliação conforme as aprovações internas, sem interpretar uma rodada de teste como garantia de entrega ou suporte em todos os destinatários e clientes.
Guarde a versão da configuração aprovada, a identificação das mensagens de teste, os resultados sanitizados do endpoint e a decisão de liberação. Esses artefatos comprovam o que foi observado no escopo testado. Não provam que todos os destinatários receberão a mensagem, que qualquer cliente exibirá o cartão ou que a entrega em produção está garantida. Se a Microsoft mudar requisitos de registro ou validação, revise as evidências e repita os testes pertinentes.
Dúvidas comuns durante a validação
Qual alteração deve vir primeiro depois da desativação do EAT?
Identifique qual autenticação a integração realmente usa e localize a configuração do provedor e da aplicação. Se ainda depender de EAT, planeje a migração para tokens do Microsoft Entra ID antes de investigar sintomas isolados do cartão. Registre o estado anterior e preserve uma cópia segura das configurações para comparar resultados, sem guardar segredos em evidências de QA.
Como validar tokens do Microsoft Entra ID no escopo de usuários de teste?
Use destinatários autorizados de acordo com o escopo registrado e verifique as instruções atuais no Developer Dashboard. Envie uma mensagem do próprio serviço, confirme a renderização e teste a validação no endpoint com casos permitidos e recusados. Uma caixa temporária pode mostrar uma mensagem recebida quando o cenário for compatível, mas não confere elegibilidade organizacional ao endereço.
O e-mail chegou, mas o cartão não aparece. O que revisar?
Separe a entrega da renderização. Confirme se o destinatário atende ao escopo de teste, se o registro do provedor está válido e se o cliente usado é compatível com o cenário. Registre cada resultado. Não atribua a falha ao endereço apenas com base na ausência do cartão, pois a mensagem pode ter sido entregue sem que as condições para exibir o conteúdo acionável estejam atendidas.
O botão funcionou visualmente. Como comprovar que o servidor validou a requisição?
A exibição do botão não comprova autenticação. Correlacione a chamada com os registros do endpoint e confirme que o servidor verificou o token segundo os requisitos aplicáveis antes de autorizar qualquer operação. Teste separadamente token inválido, permissão incompatível e recusa de negócio. Considere a ação aprovada somente quando houver evidência do resultado de validação e do processamento esperado.
Para uma migração de Outlook Actionable Messages, a caixa de teste é uma ferramenta auxiliar para observar mensagens, não um substituto para um usuário organizacional autorizado nem para a validação do endpoint. Quando o caso de uso permite receber uma mensagem de teste sem expor o endereço principal, o BoxTmp pode ser considerado como opção de isolamento. Use-o apenas quando isso for compatível com o escopo autorizado; mantenha contas Microsoft 365 adequadas para validar o registro e a renderização, e preserve a verificação de token no seu serviço.
Perguntas frequentes
O que deve ser alterado primeiro depois que a autenticação EAT deixou de ser aceita?
Identifique o tipo de autenticação usado pela integração e confirme se o provedor ainda depende do EAT. Em seguida, planeje a migração para tokens do Microsoft Entra ID conforme a documentação vigente. Antes de alterar produção, registre a configuração atual, os URLs de ação e a lógica de validação para conseguir comparar o comportamento e recuperar a configuração anterior se necessário.
Como testar tokens do Microsoft Entra ID com usuários de teste?
Use destinatários autorizados que atendam aos requisitos do escopo de teste registrado para o provedor. Confira no Actionable Message Developer Dashboard o estado do registro e as instruções aplicáveis ao tipo de implantação. Depois, envie uma mensagem do próprio serviço e teste separadamente o token no endpoint. Um endereço temporário comum não substitui uma conta organizacional elegível.
Por que a mensagem chega, mas o cartão do Actionable Message não aparece?
A entrega confirma apenas que a mensagem chegou à caixa postal. Verifique se o destinatário está dentro do escopo de teste permitido, se o provedor está registrado corretamente e se o cliente usado oferece suporte ao cenário. Registre o resultado de cada verificação antes de investigar o endereço: ausência do cartão, por si só, não prova falha de entrega nem identifica a causa.
Como saber se o botão foi validado pelo servidor, e não apenas exibido?
A aparência do botão e o envio de uma requisição não comprovam que o servidor aceitou a autenticação. Inspecione a validação do token no endpoint de ação, confirme se ele é aplicável ao provedor e ao pedido recebido e verifique o resultado de autorização e da regra de negócio. Mantenha casos separados para token inválido, permissão incompatível e operação recusada.
Prepare um endereço separado para a próxima verificação de baixo risco
Abra a área de trabalho para copiar um endereço, acompanhar a contagem regressiva e ler o e-mail de verificação na mesma página. Para contas importantes, use um e-mail com recuperação de longo prazo.
Criar e-mail temporário