Azure Logic Apps 基于Gmail/Outlook发件的运行机制及前置条件咨询

一、Logic App 执行邮件发送的实际运行逻辑 #

整个发件流程不依赖Logic App本身内置的邮件投递能力，完全依托官方预置的托管连接器完成全链路操作，核心运行步骤为：

• Logic App 流程触发后，运行时节点会调取之前配置完成的、对应指定发件人的授权凭证
• 拿着有效凭证直接调用对应邮箱服务商的官方开放接口（Outlook场景调用Microsoft Graph邮件接口、Gmail场景调用Gmail API接口）
• 接口校验身份权限通过后，将组装完成的邮件参数（收件人列表、主题、正文、附件等）提交给邮箱服务商
• 最终的邮件投递动作由对应邮箱服务商本身的服务端完成，Logic App 仅负责拿到投递结果的回调状态（成功/失败），同步回写流程的运行日志

二、SMTP、中继服务类前置配置的适用场景 #

这类配置不是所有发件场景的必选项，分两种情况判断：

• 使用官方托管邮箱连接器的场景：完全不需要提前准备SMTP服务、邮件中继节点。连接器本身已经内置了和对应邮箱服务商打通的网络通道、认证逻辑，不存在用户需要额外打通网络链路的要求
• 使用通用SMTP连接器的场景：才需要提前准备对应SMTP服务的地址、端口、认证账号，这种情况下如果发件网络存在出口限制，才需要额外配置邮件中继完成流量转发

三、微软侧托管服务的覆盖边界 #

不存在完全零配置的全托管闭环，托管和需要用户自行配置的部分有明确边界：

• 可由微软侧完成托管的内容：连接器的端点维护、运行时的可用性保障、跨服务商的请求转发稳定性、运行日志的归集存储
• 必须由用户侧自行完成的内容：
  • 指定发件人邮箱的所有者需要完成一次OAuth授权，给Logic App 对应的邮件发送范围权限
  • 对应发件邮箱所在的组织安全策略如果限制了第三方应用的API调用，需要用户侧自行调整策略放行，否则会出现认证失败
  • 发件域名的信誉度、反垃圾规则适配这类影响邮件送达率的逻辑，是由对应邮箱服务商的平台规则决定，微软侧不会代为完成托管配置

内容的提问来源于stack exchange，提问作者Pardha