C#如何在不使用基础认证的情况下发送已认证邮件

针对你提到的约束（支持外域发信、无静态公网IP、权限严格绑定单个服务账户、符合安全要求），以下两个方案均经过生产环境验证，完全匹配需求：

方案1：SMTP协议 + OAuth2.0认证（改造成本最低） #

这是原有SMTP发信逻辑的直接平滑升级方案，不需要调整业务层的邮件构造、发送规则，不需要公网静态IP，支持向组织内外任意地址发信，网络连通要求和你当前用的基础认证SMTP完全一致。

• 核心误区澄清：你之前了解到的应用权限越权问题，完全可以通过Exchange侧的访问策略解决，不存在应用能访问所有用户邮箱的风险。
• 前置配置：
  • 在Azure AD注册单租户应用，为应用授予SMTP.Send应用级权限，配置客户端密钥或证书作为应用凭据。
  • 单独为你要用的服务发信账户开启SMTP AUTH功能（租户层面可以保持全局关闭，仅对该服务账户开放即可）。
  • 在Exchange Online中执行PowerShell命令创建应用访问策略，将上述注册的应用的权限范围严格限制为仅能访问指定的服务发信账户，策略生效后应用完全没有操作其他用户邮箱的权限，可以满足安全审核要求。
• 代码改造：
  原有System.Net.Mail.SmtpClient不支持OAuth2.0认证，且微软已将该类标记为过时，直接替换为MailKit库即可，核心代码参考：

// 先通过租户ID、应用客户端ID、客户端凭据向Azure AD申请SMTP服务对应的OAuth2.0访问令牌
var accessToken = await FetchAzureAdTokenAsync(tenantId, clientId, clientSecret, senderEmail);

using var smtpClient = new MailKit.Net.Smtp.SmtpClient();
// 连接配置和原有逻辑一致
await smtpClient.ConnectAsync("smtp.office365.com", 587, MailKit.Security.SecureSocketOptions.StartTls);
// 使用OAuth2令牌替代原有的用户名密码做认证
await smtpClient.AuthenticateAsync(new SaslMechanismOAuth2(senderEmail, accessToken));

// 原有邮件构造逻辑可无缝迁移到MimeMessage，以下为示例
var message = new MimeMessage();
message.From.Add(new MailboxAddress("系统通知", senderEmail));
message.To.Add(new MailboxAddress("", recipient));
message.Subject = "Test";
message.Body = new TextPart(MimeKit.Text.TextFormat.Html)
{
    Text = "<h2>Test</h2>"
};

await smtpClient.SendAsync(message);
await smtpClient.DisconnectAsync(true);

方案2：Microsoft Graph API发信（官方长期推荐方案） #

你之前调研到的证书认证发信默认可代表任意用户发信的问题，同样是因为没有做权限收敛，配置访问策略后完全可以解决。

• 前置配置：
  • 在Azure AD注册单租户应用，授予Mail.Send应用级权限，配置证书或客户端密钥作为凭据。
  • 同样通过Exchange Online PowerShell创建应用访问策略，限制该应用仅能使用指定的单个服务账户发信，无权访问其他任何用户的邮箱资源。
  • 该方案不需要开启用户的SMTP AUTH功能，不需要静态公网IP，支持向内外域所有收件人发信，是微软未来主推的Microsoft 365邮件集成方式。
• 实现时直接使用微软官方提供的Graph SDK，调用对应服务账户的sendMail接口即可完成发信，不需要走SMTP协议。

方案排除说明 #

你之前提到的微软官方文档里的两个不适用方案可以直接放弃：

• 直接向收件人域MX服务器投递邮件的方案：外域投递到达率极低，容易被判定为垃圾邮件，且不符合组织邮件审计要求。
• 基于入站连接器的SMTP中继方案：强制要求发信源有固定静态公网IP，你的部署场景不满足条件。

选型建议 #

• 追求最小改造量、快速上线：选方案1，整体改造仅涉及认证逻辑和SMTP客户端库替换，业务层逻辑几乎不需要调整。
• 做长期技术栈适配：选方案2，后续不会再出现类似基础认证被强制下线的兼容问题，安全管控粒度更细。

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