ASP.NET C# WebForms通过SmtpClient调用smtp.office365.com发邮件报错

安全阿岳

2026-9-1

问题描述

在ASP.NET C# Web Forms应用中使用如下代码发送Office 365邮件时触发报错：

SMTP服务器需要安全连接或客户端未通过身份验证。服务器响应为：5.7.57 客户端未通过认证无法发送邮件。错误：535 5.7.139 身份验证失败，当前租户已禁用SmtpClientAuthentication，可参考官方说明文档了解更多信息。[DXXP273CA0023.AREP273.PROD.OUTLOOK.COM]

相同代码在另一款应用中可正常运行，疑问点：域名包含连字符(-)是否为报错诱因？是否需要排查邮件配置或服务器/域级别设置？

当前使用的发信代码：

string smtpServer = "smtp.office365.com";
int port = 587;
using (MailMessage mail = new MailMessage())
{
    using (SmtpClient SmtpServer = new SmtpClient(smtpServer))
    {
        mail.From = new MailAddress(_emailIDFrom);
        mail.To.Add(_emailIDTo);
        mail.Subject = _subject;
        mail.IsBodyHtml = true;
        mail.Body = _emailBody;
        SmtpServer.Port = port;
        SmtpServer.DeliveryMethod = SmtpDeliveryMethod.Network;
        SmtpServer.UseDefaultCredentials = false;
        SmtpServer.Credentials = new System.Net.NetworkCredential(_emailIDFrom, _emailIDFromPassword);
        SmtpServer.EnableSsl = true;
        try
        {
            SmtpServer.Send(mail);
            return true;
        }
        catch (Exception ex)
        {
            lblMessage.Text = ex.Message;
            return false;
        }
    }
}

Global.asax的Application_Start中配置的TLS代码：

if (ServicePointManager.SecurityProtocol.HasFlag(SecurityProtocolType.Tls12) == false)
{
    ServicePointManager.SecurityProtocol = ServicePointManager.SecurityProtocol | SecurityProtocolType.Tls12;
}

问题解答

首先明确结论：域名包含连字符和该报错完全无关，不需要在域名格式上做排查。
该报错的核心原因已经在错误提示中说明：你当前使用的发信邮箱所属的Office 365租户/邮箱本身禁用了SMTP客户端认证，和代码逻辑无关——同代码在其他应用正常运行，已经可以证明代码写法本身没有问题。

可按以下优先级排查修复：

检查单邮箱的SMTP认证权限
进入Microsoft 365管理中心的活跃用户列表，选中发信使用的邮箱账号，打开邮件设置板块的「管理电子邮件应用」，确认「已验证的SMTP」选项处于勾选状态，保存修改后等待10分钟左右再测试发信。
检查租户级SMTP认证全局配置
如果单邮箱已经开启SMTP认证仍然报错，需要用Exchange Online管理员权限执行PowerShell命令查看全局配置：
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
如果命令返回值为True，说明租户全局禁用了SMTP客户端认证，执行以下命令开启即可：
Set-TransportConfig -SmtpClientAuthenticationDisabled $false
注意：如果你的组织开启了安全默认值、强制MFA（多重身份验证）的条件访问策略，即使开启了SMTP认证，直接用账号密码发信也会被拦截。这种场景下要么给发信账号生成应用专用密码，用应用密码替换原账号密码发信；要么改用微软官方推荐的Microsoft Graph API实现发信，稳定性更高。
代码层面的优化检查
你当前的TLS配置逻辑没有问题，但建议直接显式指定TLS1.2版本，避免旧版.NET Framework默认协议匹配异常，可将Global.asax中的TLS配置简化为：
```
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
```
同时确认传入的发信账号、密码没有多余空格、拼写错误，发信账号本身处于正常可用状态、没有被限制发信权限。

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