邮件退信率：安全阈值、原因与修复步骤

即使服务器返回 250 OK，邮件退信率也可能突然升高。你以为邮件已经送达，二十分钟后却发现发送控制台显示 8% 的失败率，而队列中的每次重试都可能让问题更加严重。

这不只是一次投递故障，而是发件人信誉正在实时受损。邮件退信率是 ISP 判断你是正常发件人，还是在向购买的地址库大量群发邮件的重要信号。Gmail、Outlook 和 Yahoo 通常不会在采取措施前发出警告。它们会按自动化阈值处理邮件；一旦越过阈值，整个列表的投递能力都可能下降，不只影响发送失败的邮件，也会波及多年来一直打开你邮件的订阅者。

下文会说明每种退信的实际含义、需要关注的准确 SMTP 代码，以及在问题影响主域名前应遵循的排查顺序。要进一步了解邮件退信率与整体发件人信任度的关系，请阅读我们的邮件发件人信誉信号指南。

邮件退信的三种类型

邮件退信率是接收服务器拒绝的邮件数占已发送邮件数的百分比。“退信”并不是单一故障，而是分为三种类型，各自对应不同的 SMTP 代码和完全不同的处理方法。接收服务器返回的代码已在 RFC 5321 中标准化。如果用同一种方式处理三者，原本的列表卫生问题可能演变成基础设施危机。

硬退信 - 永久性失败

SMTP 代码：5xx - 通常是 550 5.1.1 User Unknown 或 550 5.1.2 Bad Destination Mailbox Address

地址不存在、域名已过期，或者收件人三年前就离开了公司。重试无法修复硬退信。第一次之后仍反复尝试，会向 ISP 表明你没有妥善管理列表，因为正常发件人不会持续向失效地址发送邮件。

处理：立即并永久加入抑制列表。不要留待日后的再互动活动使用，应从活跃列表中删除。

软退信 - 暂时性失败

SMTP 代码：4xx - 通常是 421 Service not available、450 Mailbox unavailable 或 452 Insufficient storage

地址有效，但由于临时原因投递失败，例如邮箱已满、接收服务器停机，或发送速率受到限制。多数 ESP（Amazon SES、SendGrid、Postmark）会在 24-72 小时内自动重试。如果过了这个时间窗口仍然失败，就应按硬退信处理。

处理：让 ESP 负责重试。如果超过 72 小时仍未恢复，就将该地址加入抑制列表。

拦截退信 - 基于策略的拒绝

SMTP 代码：5xx - 通常是 550 5.7.1、554 5.7.1、Google 的 550 5.7.26 或 Microsoft 的 550 5.7.515

地址确实存在，但接收服务器仍然拒绝邮件，原因在于发件方，而不是收件人。你的 IP 可能已被列入拦截名单，SPF 记录可能有误，或 DKIM 签名验证失败。这属于基础设施紧急问题，抑制联系人并不能解决。

处理：不要改动收件人列表，先修复发送基础设施。

表格未涵盖第四种故障：静默过滤。Gmail 有时会用 250 OK 接收邮件，随后直接将其放进垃圾邮件箱，甚至完全丢弃。这种情况不会计入邮件退信率，而可能表现为打开率大幅下降。退信率正常而互动率骤降，可能是静默垃圾邮件过滤的迹象。如果退信数据看起来正常，但互动率持续下滑，就应排查这种情况。

正常的邮件退信率是多少？

正常的邮件退信率通常低于 2%，低于 0.5% 可视为健康水平。真正需要关注的并非行业平均值，而是可能触发 ISP 限速和 ESP 账户暂停的自动化阈值。一次越线就可能引起额外审查，持续忽视则可能导致账户被暂停。

• 低于 0.5% - 最佳。列表干净，基础设施稳定，ISP 更有可能信任你的邮件。应尽量保持在这个范围。
• 0.5%-2.0% - 可接受。常见于较旧的 B2B 地址库或发送频率较低的发件人。未必存在迫在眉睫的风险，但应在突然升高的问题累积前查明原因。
• 2.0%-5.0% - 危险区。ISP 可能开始限制或过滤邮件。即使订阅者多年来一直打开你的营销邮件，收件箱送达率也可能下降。
• 高于 5.0% - 严重。这种发送模式可能与批量垃圾邮件相似。Amazon SES 可能在这一水平采取措施，包括暂停账户，以保护共享 IP 池的信誉。

另一个同样重要的数字是垃圾邮件投诉率。Google 2024 年发件人要求将 0.3% 列为不应达到的投诉率，也就是 3 次投诉对应每发送 1,000 封邮件。超过这一水平后，无论退信率多低，Gmail 都可能加强过滤或在网关拒收邮件。

邮件退信率为何骤升：根本原因

在开始抑制联系人之前，先查看发送日志中的错误代码，它们会告诉你具体哪里出了问题。邮件退信率突然升高大多可归结为三个原因，而且每个原因都需要不同的应对措施。如果把三者都当成列表卫生问题，可能花一周清理地址，却仍未修复故障源头。

列表老化与数据质量差

如果日志中充斥着 550 5.1.1 User Unknown，说明地址数据已经过时或存在错误。据粗略估算，邮件列表每月会自然流失约 2% 的有效性，因为人们会更换工作、公司会被收购、域名也会过期。两年前很干净的列表，如今可能已经失去相当一部分有效地址。

拼写错误会进一步加剧问题，例如 gmal.com、yahoomail.com、hotmal.com。这些错误可能通过注册表单，并一直潜伏到实际发送时才暴露。如果你曾购买过列表，应把它视为高风险来源。购买的列表中可能混有专门用于识别批量发件人的垃圾邮件陷阱地址，即使只命中一个，也可能导致 Spamhaus 收录。

身份验证失败

如果看到 Google 的 550 5.7.26 或 Microsoft 的 550 5.7.515，邮件退信率上升可能是发件人身份检查失败造成的，而非收件地址有误。需要核查以下三项：

• SPF：是否已授权发送 IP？是否意外超过 10 次 DNS 查询的限制？
• DKIM：加密签名是否有效，并与 From 域名对齐？
• DMARC：在 SPF 或 DKIM 仍验证失败时，策略是否已设置为 p=reject？

如果配置最近出了问题，或你要从头开始设置，我们的SPF 记录设置指南介绍了完整流程，包括如何审查 include 链，提前发现查询次数超限，避免演变成拦截退信。

IP 或域名信誉导致拦截

如果看到 554 5.7.1 Service unavailable; Client host [x.x.x.x] blocked using Spamhaus，说明发送 IP 已被 Spamhaus 拦截。这与收件人列表无关，而与该 IP 的历史表现有关。在 ESP 的共享 IP 池中，其他发件人的行为也可能给整个地址池带来问题。

IP 拦截通常可以处理，但仅更换 IP 并不能保证邮件退信率迅速恢复。域名信誉更难摆脱，因为更换 IP 后它仍会跟随域名。由域名信誉问题引起的拦截退信，可能需要连续数周进行干净、低量的发送才能恢复，而不是简单更换 IP。

排查流程：按这个顺序修复

邮件退信率骤升时，修复顺序与修复措施本身同样重要。跳过步骤可能造成假象：你抑制了联系人，但根本原因仍会在下一次发送中制造新的退信。请依次执行以下步骤。

第 1 步：立即清除硬退信地址

导出退信报告，筛选所有硬退信，也就是包含 “User Unknown” 或 “Bad Destination” 的 5xx 代码。立即将它们从活跃列表中删除。不要保留这些地址用于今后的再互动活动。每次向失效地址发送邮件，都会给接收方 ISP 留下一个负面数据点，而且这些数据会不断累积。

第 2 步：审查身份验证记录

在发送下一个营销活动前验证身份认证配置。一条错误的 SPF 记录就可能让主要邮箱服务商把发往整个活跃列表的邮件判为拦截退信。

# Check your SPF record - count each DNS lookup mechanism (must stay at or under 10)
dig txt yourdomain.com +short

# Check your DMARC policy - p=reject blocks everything if SPF/DKIM are failing
dig txt _dmarc.yourdomain.com +short

# Check your DKIM selector - replace "selector1" with your actual selector name
dig txt selector1._domainkey.yourdomain.com +short

如果你要管理多个域名的身份验证，SPF 查询限制很容易成为陷阱。某个域名单独看可能毫无问题，另一个域名却会继承嵌套的 include: 链，在不知不觉中将查询次数推高到 12，随后 Gmail 可能因 SPF 错误而硬性拦截来自该域名的所有邮件。

第 3 步：检查拦截名单

使用多 RBL 检查工具检测发送 IP，MXToolbox 就可以。被拦截名单收录可能让邮件退信率在一夜之间大幅上升。以下名单可能实际影响主要邮箱服务商的投递：

• Spamhaus SBL/XBL/ZEN：第 1 级。被收录可能严重影响 Gmail、Outlook 和 Yahoo 的投递。暂停发送，查明原因后尽快申请移除。
• SpamCop：第 1 级。影响同样可能很大。根据收录原因，保持几天干净发送后或许可以自动移除。
• UCEPROTECT Level 3：许多主要服务商似乎并不直接采用。可以监测，但应优先处理已有证据支持的投递问题。

第 4 步：隔离发送域名

如果退信骤升源于一次营销群发，在查明原因前，应停止使用主域名 @company.com 发送。设置独立子域名，例如 @newsletters.company.com，并为它配置自己的 SPF 和 DKIM 记录。如果该子域名的信誉受损，发票、支持工单和合同仍可继续从主域名发送，不过共享的信誉信号意味着隔离并非绝对。

TrekMail 如何处理基础设施问题

多数邮件退信率问题可分为两类：一类是地址列表数据质量差，责任始终在发件人；另一类是身份验证基础设施配置错误，此时托管服务的设置很重要。TrekMail 会协助处理基础设施部分，减少身份验证相关拦截退信反复发生的可能性。

传统方式：你要为 25 个客户域名手动管理 SPF、DKIM 和 DMARC。一个错误的 include: 链就会破坏整个域名的 SPF。你花三小时查看 DNS 日志，最后才发现一次拦截退信是由一条过时记录导致的，它让查询次数超过了 10 次限制。

TrekMail 方式：在添加每个域名时，SPF/DKIM/DMARC 向导会生成并验证相应记录。身份验证会在设置过程中处理，无须手动统计查询次数，也不必在 11pm 排查 TXT 记录的拼写错误。

对于管理多个客户的服务机构，BYO SMTP 可提供额外的隔离层。客户使用 TrekMail 托管 IMAP 邮箱，同时连接自己的 Amazon SES 或 SendGrid 账户发送外发邮件。如果一个客户损害了发送信誉，导致其账户被暂停，你可以更换 API 密钥，而不必动其邮箱。在单独恢复发送账户期间，托管基础设施仍可保持不变。

Starter 套餐为 $3.50/month，包含 50 个域名和托管 SMTP。Nano 套餐无须信用卡，支持 10 个域名使用 BYO SMTP。如果你已有发送服务，只需要托管和妥善配置的身份验证层，就可以免费开始使用。请比较 TrekMail 套餐并核对最新条款，选择适合你的方案。

让邮件退信率保持低于 0.5% 的三个习惯

控制住当前问题后，以下三个运营习惯有助于让邮件退信率长期处于安全范围，而无须持续进行大量手动维护。完成初始设置后，它们都不需要很高的额外成本。

注册时实时验证

不要等到发送时才发现虚假地址。在注册表单中加入验证 API，例如 ZeroBounce、NeverBounce 或类似服务。这些工具可在地址进入列表前发现拼写错误、一次性地址和角色账户，而这几类地址常常会推高邮件退信率，例如 info@、admin@、postmaster@。一次验证调用通常只需一美分的一小部分。ESP 账户被暂停后则可能需要人工审核，并让你数天无法发送邮件。

逐步停用不活跃订阅者

被弃用 18 个月的邮件地址可能在下一次发送时产生退信。如果订阅者 180 天没有打开邮件，这是一项风险信号，但由于打开率数据并不完整，它并非绝对证明。发送一封再互动邮件；如果仍无互动，就主动取消其订阅。这通常比等待地址失效，并在未来营销活动中计入退信率更划算。

用子域名隔离营销邮件

尽可能不要用主企业域名发送批量营销活动。简报群发产生的邮件退信率可能影响 CEO 发送合同所用域名的信誉。为 @marketing.company.com 配置独立的 DNS 记录。如果营销子域名的信誉受损，核心业务会获得更好的隔离，但服务商仍可能参考共享的域名信誉信号。要深入了解域名信誉为何比 IP 信誉更难恢复，请阅读我们的邮件域名信誉及其下降原因指南。

修复根本原因，而非表面症状

邮件退信率高只是信号，不是问题本身。硬退信意味着列表数据质量差，拦截退信意味着基础设施出了问题。用同一种方式处理两者可能一个也修不好，只会推迟下一次骤升。

先清理列表，再审查身份验证，然后检查拦截名单。在下一个营销活动开始前，把营销邮件从主域名迁出，而不是等到下一次事故发生后再处理。

如果你需要一套能够为多个域名妥善处理身份验证，并可在不改动邮箱的情况下更换发送账户的邮件基础设施，TrekMail正是为此而设计。Nano 套餐无须信用卡，Starter 套餐为 $3.50/month，付费套餐提供 14 天免费试用。