新服务器上Laravel Mail配置报错：530 Authentication Required

故障场景：完全相同的邮件发送配置在本地开发环境可正常返回250发件成功响应，部署到公网服务器后请求被SMTP服务拒绝，返回530-5.7.0 Authentication Required错误。

常见根因与对应解决方法 #

• 配置层面的认证失效
  • 确认发件使用的Gmail账号已开启两步验证，并生成了独立的应用专用密码做SMTP认证：直接使用Gmail账号本身的登录密码在服务端做认证时，本地请求因为是用户日常常用设备IP，不会触发安全拦截，但服务器端的陌生IP会被Gmail判定为不安全登录，直接拒绝认证请求。这类场景下返回的报错提示和密码填错的提示完全一致，很容易排查错方向。
  • 检查服务端实际加载的配置值：避免出现本地配置读取到正确的环境变量，服务器端因为配置加载路径错误，读到了占位的默认值的情况。重点核对SMTP服务地址、端口、认证账号、认证密码四个参数是否和本地完全一致，尤其注意不要错用不支持STARTTLS的端口，导致认证流程根本没有触发就被服务端拒绝。
• IP维度的风控拦截
  • 云服务器的出口IP属于数据中心IP段，是Gmail的重点风控对象。如果该IP段之前有其他用户发送过垃圾邮件，IP本身已经被Gmail标记，即使客户端传递了完全正确的认证信息，Gmail也会直接返回通用的530认证错误提示，不会明确告知是IP被拦截。遇到这类情况，可以先在服务器端查询自己的公网出口IP，登录对应Gmail账号的安全中心，将该IP标记为可信访问来源；如果IP已经被拉黑，可联系云服务商申请对应IP段的Gmail发信权限解除。
• 网络链路导致的认证流程中断
  • 部分云厂商的出口防火墙、安全组规则会拦截SMTP TLS握手阶段的数据包，导致客户端根本没有完成认证交互，就被Gmail判定为未认证的匿名请求。可以在服务器端手动执行测试命令，验证完整的认证流程是否能走通：

    openssl s_client -connect smtp.gmail.com:465 -crlf -quiet
    

    按照终端提示依次输入EHLO指令、AUTH LOGIN指令，传入base64编码后的账号与应用专用密码，如果这一步就返回530错误，说明和业务代码逻辑无关，直接排查网络或者Gmail风控策略即可。

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