Azure App Service部署NestJS应用后Email Communication Service发件失败

• 检查云端环境变量的实际取值
  即使你确认过配置，云端环境变量可能存在格式问题（比如多余空格、引号）或未正确传递。通过App Service的「高级工具」→「Kudu」→「环境」查看senderAddress的实际值，确保和本地完全一致。如果是Docker Compose部署，注意App Service的应用设置会覆盖docker-compose.yml中的变量，需确认优先级配置。

• 确认发件人地址的验证状态
  登录Azure门户进入Email Communication Service，查看「发件人地址」列表，确保使用的senderAddress状态为「已验证」：

  • 若使用自定义域名，重新检查SPF、DKIM、DMARC记录是否完全匹配Azure给出的配置，且Azure的验证状态显示「成功」；
  • 即使本地可用，云端可能存在域名验证延迟，需等待DNS记录完全生效后再测试。

• 排查EmailClient初始化逻辑
  在NestJS代码中添加日志，输出初始化时的senderAddress和connectionString值，部署后通过App Service的「日志流」查看实际读取到的内容，确认是否因变量名拼写错误、配置未加载导致值为空或错误。

• 验证App Service的网络访问权限
  即使资源在同一资源组，App Service的VNet集成或防火墙规则可能限制了对Email Communication Service的访问：

  • 检查App Service的「网络」设置，确保出站规则允许访问Azure Communication Services的服务端点；
  • 在Kudu控制台中用curl测试Email Communication Service的API端点，确认网络连通性。

• 尝试Azure AD托管身份认证
  若连接字符串方式始终有问题，可切换为Azure AD身份验证：

  1. 给App Service启用系统分配的托管身份；
  2. 在Azure门户中，给该托管身份分配「Email Communication Services Contributor」角色；
  3. 修改NestJS代码，用DefaultAzureCredential初始化EmailClient：

     import { EmailClient } from "@azure/communication-email";
     import { DefaultAzureCredential } from "@azure/identity";
     
     const emailClient = new EmailClient("<你的Email服务端点>", new DefaultAzureCredential());
     

  这种方式无需配置连接字符串，避免环境变量传递的潜在问题。

• 检查邮件请求体格式
  错误提示指向senderAddress，但可能是整个请求体的JSON序列化问题。对比本地和云端的请求体结构，确保senderAddress为纯字符串，无嵌套错误或格式异常。

内容的提问来源于stack exchange，提问作者David Nahum Araya