Brevo SMTP：配置、参数与故障排查指南

Brevo SMTP 把应用的外发邮件从虚拟主机本地的邮件代理搬到一套能对每一封消息做鉴权、记录和报告的基础设施上。配置本身很小：一个主机名、一个端口、两个凭据。配错的动作也很小，而失败方式往往悄无声息。本文覆盖参数、凭据模型、决定邮件能否送达的 DNS 工作，以及任一环节配置错误时你会遇到的报错。如果你还在挑选服务商，更宏观的 SMTP 邮件服务指南先帮你比较了整个市场。

Brevo SMTP 是什么

Brevo 把 Brevo SMTP 描述为它的 SMTP 中继服务。你的应用、网站或邮件服务器通过一条经过鉴权的连接把消息交给中继，然后由 Brevo 负责路由、重试、信誉和报告。中继邮件的统计数据与营销活动统计并列展示，一次硬退信会自动把该联系人加入屏蔽名单。

这个中继是为事务性消息而生的：密码重置、收据、订单确认、账号通知。如果你对它和营销邮件之间的界线还不够清楚，什么是事务性邮件讲清楚了这一点。

选 SMTP 还是 REST API

两条路径通向同一个平台。实际的分工是：

一条硬限制：Brevo 的开发者文档明确说明 SMTP 中继不支持批量发送，并把批量操作指向 API 端点。

创建你的 SMTP 凭据

Brevo 的 SMTP 鉴权用到两个很容易和你已有凭据混淆的值。

找到你的 SMTP 登录名

SMTP 登录名不是你的 Brevo 账号邮箱。它是一个独立标识，显示在 Settings 里 SMTP and API 页面的 Login 字段中，格式为 [email protected]。

由此得出两条规则，都来自 Brevo 的故障排查文档。不要把 smtp-relay.brevo.com 填进用户名字段：那是中继主机，不是你的登录名。也不要把 SMTP 登录名放进 From 头，因为它的作用是给你鉴权，而不是标识发件人。

生成一个 SMTP 密钥

密码是一个 SMTP 密钥，既不是账号密码，也不是 API 密钥。

1. 打开账号下拉菜单，选择 Settings，然后 SMTP and API。
2. 在 SMTP 标签页下点击 Generate a new SMTP key。
3. 用将要使用它的那个集成来给密钥命名。
4. 选择类型。Standard 是推荐的 64 位字符密钥；Short 是 15 位字符密钥，供无法处理长密码的客户端使用。
5. 设置 7 天到 1 年之间的有效期，或者选择永不过期。
6. 点击 Generate，然后立刻复制完整密钥。

完整密钥只显示一次，之后页面只会显示它的最后几位。如果丢了，就生成一个替代密钥并更新配置。

连接参数

在任何客户端或库里要填的值：

选择端口

Brevo 推荐 587 作为默认端口。465 端口当年被指定用于 SMTP over SSL，后来被废弃，但至今仍被广泛支持，在你需要连接在第一条命令之前就完成加密时正合适。2525 不是 IETF 或 IANA 注册端口，但大多数 ISP 和云服务商都放行，这让它成为 587 被封锁时的逃生通道。

加密字段最容易绊倒人。Brevo 告诉你，除非用 465，否则留空。这并不意味着连接是不加密的：在 587 和 2525 上，服务器会通告 STARTTLS，任何称职的客户端都会在鉴权之前完成升级。它的意思是，连 587 时不要选“SSL”，因为端口和加密方式不匹配，就算凭据正确也会鉴权失败。

写任何代码之前先测连接

在排查应用代码之前，先确认中继有响应并且 TLS 能协商成功。

openssl s_client -starttls smtp -crlf -connect smtp-relay.brevo.com:587

握手成功会以服务器的 250 能力列表结束，其中应该包含 STARTTLS，以及一行列出 PLAIN 和 LOGIN 的 AUTH。完全没有横幅说明是网络问题，不是凭据问题。

认证你的发送域名

这是人们会跳过的一步，而它决定了邮件到底能不能送达。自 2024 年 2 月 1 日起，域名认证在 Gmail 和 Yahoo 的发件人要求下已成为强制项，Brevo 也提到 Microsoft 在 2025 年 5 月 5 日宣布了类似标准。未经认证的邮件会被过滤或拒收，不管是哪个中继发出的。

Brevo 要求的记录

如果你在 Brevo 内部登录域名服务商，Brevo 可以自动添加这些记录，你也可以手动把值复制到 DNS 区域里。拿到哪种 DKIM 形式取决于账号：两条 CNAME 记录默认使用 2048 位密钥，单条 TXT 形式则是 1024 位密钥。

为什么没有 SPF 记录

Brevo 的 FAQ 说得很明确：认证域名不需要 SPF 和 MX 记录，只有在配置独立 IP 时才会提供。在共享基础设施上，Brevo 控制着回信路径，因此 DKIM 加上所有权校验就承担了全部认证。如果你是从一个要求 SPF include 的服务商迁过来的，不要自己发明一条；多余的 include 只会带来查询次数超限的风险。

DMARC 依然重要，Brevo 也给出了一条可用的起步记录：

v=DMARC1; p=none; rua=mailto:[email protected]

先用 p=none 拿到汇总报告而不冒送达风险，等所有合法发送源都对齐之后，再收紧到 quarantine 和 reject。我们的邮件送达率指南讲了这个演进过程。

验证发件人

每一个 From 地址都必须是已验证的发件人，或者位于一个已认证的域名下。新发件人需要用发送到该地址的 6 位验证码来验证，而位于已认证域名下的发件人可以跳过这一步，这也是先做域名认证的原因。免费邮箱域名无法被认证，所以 gmail.com 或 outlook.com 上的 From 地址会被拒收或过滤。

集成实操

WordPress

WordPress 把外发邮件交给 wp_mail，而它会调用主机提供的任何东西。要把它路由到 Brevo，需要一个插件。

1. 在后台侧边栏进入 Plugins，然后 Add New Plugin。
2. 搜索 Brevo，安装“Newsletter, SMTP, Email marketing and Subscribe forms by Brevo”，然后启用它。
3. 进入 Brevo，然后 Home，在激活字段里填入你的 Brevo API key v3。这一步用的是 API 密钥，因为插件同时还要同步联系人。点击 Login。
4. 在 Transactional emails 下选择 Yes。
5. 选择一个已有发件人或新建一个。每一封 WordPress 邮件都会使用该发件人名称和地址。
6. 填入一个地址并点击 Send email 发一封测试邮件。

有两个常见错误。提示事务性邮件未启用、因为你的 Brevo SMTP 账号尚未激活，意味着必须由 Brevo 支持人员在平台侧开通。提示无法使用 SMTP、因为 wp_mail 已被另一个进程声明，意味着存在互相冲突的 SMTP 插件；逐个停用其他插件。

服务端应用

Brevo 自己的 Node.js 示例使用 nodemailer 和上面这些参数：

const nodemailer = require("nodemailer");

const transporter = nodemailer.createTransport({
  host: "smtp-relay.brevo.com",
  port: 587,
  secure: false, // 465 端口用 true，其他端口用 false
  auth: {
    user: process.env.BREVO_SMTP_LOGIN, // [email protected]
    pass: process.env.BREVO_SMTP_KEY,
  },
});

async function sendOrderConfirmation() {
  const info = await transporter.sendMail({
    from: '"Acme Support" <[email protected]>',
    to: "[email protected]",
    subject: "你的订单已确认",
    text: "订单 10482 已确认，将在两个工作日内发货。",
  });
  console.log("邮件已发送：", info.messageId);
}

sendOrderConfirmation().catch(console.error);

注意 587 端口上的 secure: false。这个标记控制的是隐式 TLS，而不是连接是否加密；nodemailer 仍然会发出 STARTTLS。只有 465 端口才设为 true。

用标准库实现的 Python 等价写法：

import smtplib, ssl
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "Acme Support <[email protected]>"
msg["To"] = "[email protected]"
msg["Subject"] = "你的订单已确认"
msg.set_content("订单 10482 已确认，将在两个工作日内发货。")

with smtplib.SMTP("smtp-relay.brevo.com", 587, timeout=20) as server:
    server.starttls(context=ssl.create_default_context())
    server.login(BREVO_SMTP_LOGIN, BREVO_SMTP_KEY)
    server.send_message(msg)

两段代码都从环境变量读取凭据，这正是下一节的主题。

密钥安全与轮换

Brevo 把 SMTP 密钥当作密码对待。下面这些运维规则值得逐条照做。

• 一个集成一个密钥。 用使用它的系统给每个密钥命名，这样泄露或下线时只需要吊销一样东西。
• 绝不把密钥提交到代码仓库。 用环境变量、密钥管理服务或平台的配置存储。不要用版本控制，不要用被跟踪的 .env 文件，也不要截图。
• 零停机轮换。 先生成替代密钥，部署，确认能正常发送，然后再删除旧密钥。删除不可逆，删掉仍在使用的密钥会立刻中断事务性发送。
• 暂停集成用停用而不是删除。 密钥之后还能重新启用。
• 预期会过期。 密钥可以带 7 天到 1 年的有效期，而且 Brevo 会在 90 天不活跃后让密钥过期。

想要更硬的边界，Brevo 可以拦截来自未知 IP 地址的请求。授权名单在 API 密钥和 SMTP 密钥之间共享，所以你放行的任何地址对两者同时生效。容器化或云上负载要格外小心：出站地址可能是 NAT 网关，而不是你以为的实例 IP，弄错会得到 525 5.7.1 Unauthorized IP address 拒收。

同时运行 Brevo、店铺、CRM 和客服台的团队，最后往往要一次性管理好几个密钥、发件人和域名。Tajo 把这些配置放在一个地方，而不是四个仪表板里。

发送限额与限流

SMTP 发送消耗的是你套餐的邮件额度。免费套餐意味着每天 300 封邮件；限额每天重置，用不完的额度不结转。一旦达到上限，Brevo 会把最多 1,000 封后续邮件放进重试队列，超出队列的部分不再投递。付费套餐取消每日上限，Brevo 价格指南拆解了各个层级。

额度完全用尽时，通过 SMTP 提交的消息会被暂停并排队，而不是被丢弃。积压内容在 Transactional，然后 Real time，再到 Usage and plan，位于 Email queue 区域。

Brevo 公布的硬性速率限制针对的是 REST API 而不是中继。在通用层级上，POST /v3/smtp/email 允许每秒 1,000 次请求，超限会返回 429 Too Many Requests。API 路径还会返回速率限制响应头供你据此控速，而中继没有。

监控退信与投诉

中继邮件可以在 Transactional 下的 Statistics 和 Logs 页面查看。需要处理的事件：

• 硬退信。 地址无效，Brevo 会自动把该联系人加入屏蔽名单。
• 被拦截。 收件人此前投诉过、退订过、硬退信过，或者被手动拉黑。
• 延迟与软退信。 服务商接受了连接但延迟或拒绝了消息。针对某一家服务商反复出现延迟，说明是信誉问题，不是代码问题。

轮询日志无法扩展。Brevo 支持事务性 Webhook，把送达、退信、打开和投诉事件实时推送到你的端点，这也是你保持自有抑制数据最新的方式。

要盯住的数字是垃圾邮件投诉率。Gmail、Yahoo 和 Microsoft 要求发件人保持在 0.3% 以下，Brevo 建议用 Gmail Postmaster Tools 监控。踩线之后的恢复时间，远远长于一开始就不踩线所需的成本。

故障排查

535 5.7.8 Authentication failed

用户名或密码无法通过校验。按可能性排序：

• 用了账号邮箱地址，而不是 [email protected] 格式的 SMTP 登录名。
• 把 smtp-relay.brevo.com 粘贴进了用户名字段。Brevo 把这列为最常见原因之一。
• 用了 API 密钥而不是 SMTP 密钥。
• 密钥因复制粘贴带上了尾随空格或换行。
• 加密设置与端口不匹配。
• 密钥在一次安全告警后被作废，此时生成一个新的。

525 5.7.1 Unauthorized IP address

IP 拦截已启用，而发起连接的地址不在授权名单里。把它加进去，如果应用跑在 NAT 后面或容器平台上，先确认真实的出口地址。

无响应、无横幅

如果 TCP 连接建立了但服务器从未发出 220 问候，鉴权根本无法开始，问题出在你这一侧的网络上。企业防火墙有时会放行连接，然后静默丢弃 SMTP 流量。AWS、Azure 和 Google Cloud 默认对新账号限制出站 SMTP。申请解除限制，或者换到 2525 端口。

450，平台未激活

报错内容是你的 SMTP 账号尚未激活，或者你的发送平台当前被禁用。在新账号上，事务性发送需要 Brevo 支持人员单独执行一次激活。在老账号上，这通常意味着被暂停，要么是没有防护的表单被机器人注册攻击，要么是账号出现了被入侵的迹象。

发件人被拒绝

检查三件事：域名是否已认证，发件人是否已验证，以及 From 头是不是被误填成了 SMTP 登录名。

邮件被接收但进了垃圾箱

按这个顺序排查。确认发送域名已认证且 DKIM 正在签名。确认 From 域名是你自己的，而不是免费邮箱服务商。在 Postmaster Tools 里对照 0.3% 阈值检查投诉率。上述检查都干净之后再看内容，因为它几乎从来不是首要原因。

独立 IP

只有在高且稳定的发送量下，独立 IP 才有帮助。在真正大量使用之前必须先预热，而且需要一个发送子域名，它会作为 mailed by 和 return path 域名出现在邮件头里。这也是唯一一种 Brevo 会提供 SPF 和 MX 记录的配置，同时还有该子域名的 A、CNAME、DKIM 和 DMARC 记录。

有两个细节容易踩坑。一个仅配置给营销邮件的独立 IP 会把你的事务性消息排队而不是发出去，所以要么切换它，要么再买一个 IP。而把事务性和营销路由分开，需要至少两个 IP 组成的池以及各自独立的发件人，这样营销邮件较弱的互动表现才不会拖累收据和密码重置。

一次就配对

认证域名，创建一个有名字的 SMTP 密钥，连接 smtp-relay.brevo.com 的 587 端口，然后通过真实的代码路径而不是仪表板上的按钮发一封测试邮件。后来出现的几乎每一个问题，都能追溯到三件事之一。

• 用户名或密码字段里放错了凭据。
• 端口和加密设置彼此矛盾。
• 发送域名从未做过认证。

把这三件事做对，中继就会消失在背景里，而这正是事务性基础设施应有的样子。