谷歌停用Less Secure Apps选项后Google SMTP设置失效如何解决

你遇到的生产环境邮件发信失效问题，是谷歌全量下线个人Gmail账号「Less Secure Apps（低安全性应用）」访问权限导致的。该功能完成全量推送后，所有直接使用账号登录明文密码对接SMTP/IMAP/POP3协议的第三方应用，都会被谷歌鉴权层直接拦截，不存在任何官方回退通道。

方案1：使用应用专用密码（最快修复方案） #

该方案对原有代码侵入性极低，不需要调整现有发信业务逻辑，仅替换鉴权参数即可完全适配你当前的SMTP配置：

• 前置要求：给对应发信Gmail账号开启两步验证（2FA），未开启2FA的账号无法生成应用专用密码
• 操作逻辑：在谷歌账号的安全设置页面生成16位长度的应用专用密码，替换原有代码中NetworkCredential里的账号登录明文密码，其余Host、Port、SSL配置完全保留
• 适配后的可直接运行代码参考：

// 仅替换密码字段即可，其余原有发信逻辑无需改动
SmtpServer.Credentials = new System.Net.NetworkCredential("你的完整Gmail邮箱地址", "16位应用专用密码（删除生成时自带的分组空格）");
SmtpServer.Port = 587;
SmtpServer.Host = "smtp.gmail.com";
SmtpServer.EnableSsl = true;
// 老版本.NET框架需补充下行配置，强制使用TLS1.2协议避免SSL握手失败
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

方案2：切换为Gmail API + OAuth2.0鉴权（官方长期推荐方案） #

这是谷歌官方目前首推的Gmail服务对接方式，安全性更高，不存在专用密码泄露、账号权限调整导致的服务中断风险，适合长期迭代的核心业务系统：

• 需要在谷歌云平台创建对应项目，开启Gmail API权限，完成OAuth2.0同意屏幕配置、生成服务凭据
• 代码层替换原有明文密码鉴权逻辑，通过标准OAuth2.0流程拿到对应账号的有效access_token，作为SMTP协议的鉴权凭据
• 整体改造成本高于应用专用密码方案，长期稳定性更好

方案3：更换第三方专业邮件发送服务 #

如果不想适配谷歌的鉴权规则，可以直接替换邮件服务提供商，选择成熟的事务邮件推送服务：

• 可选服务包括SendGrid、Mailgun、国内各大云厂商的邮件推送服务、正规企业邮箱SMTP服务等
• 仅需替换原有代码中的Host、Port、鉴权账号密码三个配置项即可完成切换，大部分专业服务的发信送达率比原生Gmail SMTP更稳定，适合批量发送验证码、系统通知类邮件的场景

• 不存在任何重新开启「低安全性应用」访问的隐藏入口，不要尝试非官方的破解绕过方案，大概率会触发Gmail账号风控，导致账号被临时限制发信
• 如果你使用的是谷歌Workspace企业账号，可以由租户管理员在后台配置SMTP中继规则，给固定出口IP的内部应用放开免用户鉴权的发信权限，适合企业内部业务系统使用
• 谷歌生成的应用专用密码默认是4位一组带空格展示的，填入代码时需要把所有空格删除，传入16位连续字符串，否则会鉴权失败

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