你点击发送，服务器记录了 250 OK。这表示在某个 SMTP 阶段接受了请求，不等于进入收件箱，也不等于最终投递。邮件可能进入垃圾箱，或在用户看到之前接受其他检查。
不要把问题全部归因于内容，也不要只期待修改主题就能解决。下降的域名信誉可能与认证、IP、内容和发送行为一起影响结果。审查这些信号，有助于找出真正原因，而不是盲目改写邮件。
从 2024 年初开始，Gmail、Yahoo 和 Outlook 加强了身份与认证要求，但没有放弃内容分析，而是结合域名、IP、认证和行为信号。yourcompany.com 并不存在统一信用评分，信誉下降也不一定导致所有服务商同时封锁。本文介绍风险、检查和恢复思路。如果认证基础尚未完善，请先阅读企业安全邮件指南。
什么是域名信誉，它与 IP 信誉有何不同
域名信誉是各接收服务商根据可观察行为，对发送域名形成的评估。IP 信誉则关联服务器地址。更换 IP 或托管服务商可能改变部分信号，但不一定清除域名历史。
轮换 IP 以分散垃圾邮件的做法称为 snowshoeing，但不能保证避开过滤。服务商可能把发送模式关联到域名及其他身份。因此，迁移托管不等于自动重置信誉。
建立信任可能需要数周或数月稳定、合法的发送，而一次事件可能迅速损害评估。具体时间取决于服务商、流量和原因，不存在统一的下降或恢复期限。
可能改变发件人分类的门槛
所述 Google 政策的批量发件人门槛为向个人 Gmail 账户发送大约 5,000 封或更多邮件，统计窗口为 24 小时。这一分类按所述政策可能持续，即使之后降回每天 50 封。请核实当前标准，以及 Google 如何合并域名计算发送量。
向 5,100 个 Gmail 收件地址发送活动邮件，可能按适用统计方式进入该类别。要求包括 SPF、DKIM 和 DMARC 对齐，也包括控制投诉：0.3% 是重要风险水平，但不代表任何偏差都会立即触发无例外封锁。DMARC 只需有效且对齐的 SPF 或 DKIM 路径，不要求两者同时对齐。
Microsoft 在 2025 年五月引入高发送量要求。所述政策覆盖每天向 Outlook、Hotmail 或 MSN 发送 5,000 封或更多邮件的域名，要求 SPF、DKIM 和已发布的 DMARC 政策。不符合要求可能导致拒收，但细节和统计方式不一定与 Google 或 Yahoo 相同，应核实各服务商当前规则。
域名信誉为什么可能下降
投诉、无效收件人、发送量变化和认证失败，都可能影响发件人评估。这些信号可能相互作用，但并非每次下降都有公开门槛，也不一定形成自动恶性循环。以下是三个排查方向。
投诉率达到 0.3% 时的风险
投诉人数超过 3 人、发送规模为 1,000 名收件人时，就已出现风险信号，但不保证立即封锁。Google 和 Yahoo 都有投诉要求，但计算方法需要核实。在所述 Yahoo 计算方式中，分母可能是进入收件箱的邮件，而不是全部发送量。
例如发送 1,000 封邮件，其中 900 封进入垃圾箱，100 封进入收件箱。一人投诉。如果采用这一分母，就是 1 除以 100，投诉率为 1%，而不是 0.1%。这个例子说明分母如何改变指标解读，但单次投诉本身不保证立即封锁。应对照服务商实际提供的指标。
永久拒绝率
Microsoft 可能识别向不存在地址发送、类似地址空间探测的模式。这里约 5% 的数值是风险示例，不是统一公开门槛。以下代码可帮助开始排查，但不能独自证明唯一原因：
421 RP-001：可能与信誉或发送量有关的临时限制，应查看完整响应451 4.7.500：临时错误，应检查负载、策略和服务器上下文550 5.7.515：域名可能不符合高发送量认证要求
550 5.7.515 需要全面检查适用要求，而不只是对齐。记录可能缺失、错误，或未产生有效认证结果。存在 DNS 记录不代表邮件通过检查。DMARC 只需与可见 From 对齐的有效 SPF 或 DKIM，即使服务商还可能要求该类发件人同时部署两种机制。
共享 IP 的风险
某些共享托管让多个客户共用出站 IP。如果其他客户的流量损害 IP 信誉或导致进入 Spamhaus，你的连接也可能受影响，即使域名历史良好。但这并非所有共享服务或所有名单记录都会造成，结果取决于服务商控制和接收方策略。
风险指标速览
本表结合服务商参考值和运维示例，并不定义保证安全的区间或通用封锁门槛。应根据指标来源和真实流量解读。
| 指标 | 较低参考值 | 风险参考值 | 可能后果 |
|---|---|---|---|
| 垃圾邮件投诉率 | < 0.1% | > 0.3% | 按 Gmail 或 Yahoo 策略增加进入垃圾箱或拒收风险，不保证立即封锁 |
| 永久拒绝率 | < 0.5% | > 5.0% | Microsoft 可能返回 421 临时限制或 550 拒绝；数值为示例 |
| 认证失败率 | 0% | 任何失败 | 可能提示错误配置或身份伪造，需要检查上下文 |
| 发送量突增 | 逐步增加 | > 2×，在 24 小时内 | 可能出现临时延迟或检查；示例而非通用限制 |
域名信誉恢复思路
出现 550 错误或打开率下降需要诊断，但不一定证明信誉问题。隐私设置、图片加载和自动测量让打开率并不可靠。不要增加发送来强行突破过滤。应找出原因，减少受影响流量，并受控恢复。以下阶段和时间仅供参考。
阶段 1：初步诊断（第 0-24 小时）
调查期间暂停受影响的推广发送，只保留必要且预期的交易邮件，例如密码重置、账单和双重认证代码，并遵守适用发送条件。不要仅为制造互动而发送额外邮件，打开率不能保证恢复。
随后检查认证。以下命令是检查示例，不是可直接复制的配置。SPF 注释应按需要 DNS 查询的机制和修饰符预算理解，而不是认为达到允许上限就已违规：
# Check SPF - should have exactly one record, under 10 DNS lookups
dig TXT yourdomain.com | grep spf
# A healthy record looks like:
v=spf1 include:_spf.trekmail.net ~all
# Check your DKIM selector
dig TXT default._domainkey.yourdomain.com
# Check DMARC
dig TXT _dmarc.yourdomain.comSPF 错误可能来自 include: 和其他机制造成的查询过多。添加 Workspace、Mailchimp、Zendesk 和 CRM 会消耗预算，但不一定超过 10 次限制（RFC 7208）。超过限制时可能返回 PermError，而不是有效 SPF 结果。应检查完整求值过程，包括嵌套查询。只整合必要且获授权的发送许可。SPF 扁平化需要维护，也可能遗留过期授权，不应盲目使用。
如果缺少 DMARC，获授权管理员可在诊断期间发布 p=none。接收汇总报告需要有效 rua 目的地和相应授权。这一政策不请求按 DMARC 隔离或拒绝，但不会取消其他过滤。
检查域名和 IP 是否实际位于相关阻止名单。如果列入 Spamhaus SBL 或 XBL，应先修复原因，例如被入侵账户或错误中继配置，再按获授权流程申请移除。UCEPROTECT Level 3 的影响取决于接收方，不应假定所有服务商都忽略它，也不要在未确认列入时申请移除。
阶段 2：清理（第 1-3 天）
停止向已确认永久无效的地址继续发送，但不要删除所有返回 5xx 的地址。认证或策略拒绝可能源于可修复原因，而不代表地址不存在。决定抑制发送或重试前，应查看增强状态码和完整响应。
审查名单，考虑暂停向过去 90 天没有互动的群体发送。不要只依赖打开或点击，它们可能不准确或自动产生。优先联系期待这些邮件、已提供必要同意，并有可验证兴趣信号的收件人。这有助于提高名单质量，但不保证各过滤器如何评估。
阶段 3：逐步增加（第 4-30 天）
恢复中的域名从零突然增加到 10,000 封可能有风险。以下日程是渐进发送示例，不是通用硬性限制，也不保证恢复。应按真实需要、SMTP 响应和各服务商指标调整：
| 示例天数 | 每日参考发送量 | 收件群体 |
|---|---|---|
| 1 | 50 | 可验证兴趣最强的收件人 |
| 2 | 100 | 可验证兴趣最强的收件人 |
| 3 | 200 | 兴趣较强的收件人 |
| 4 | 400 | 兴趣较强的收件人 |
| 5 | 800 | 期待这些邮件的群体 |
| 6 | 1,500 | 期待这些邮件的群体 |
| 7 | 3,000 | 期待这些邮件的群体 |
如果拒绝、投诉或 421 限制增加，应暂停增量并调查。回到之前发送量并保持三天，是本例中的参考做法，而非固定规则。按结果和需要恢复，强行增加可能恶化问题。
预防：降低风险的运维习惯
事件解决后，应建立控制以减少复发。分离流量并持续监控有帮助，但可能需要工作投入，也不能让再次下降变得不可能。
按子域名分离
把活动发送与企业通信分开，便于管理身份、指标和策略。营销事件仍可能按服务商共享信号影响其他通信。可考虑以下三个流量类别，但不要假定信誉完全独立：
- 人与人通信：
user@company.com，与批量营销分开 - 营销邮件：
newsletter@marketing.company.com - 交易邮件：
receipts@alerts.company.com
子域名可以积累自身信号，但接收方也可能合并组织域及其他共享指标。营销子域名不会完全隔离企业主域名。管理多个客户或品牌时，多域名邮件托管架构应从一开始考虑分离及其限制。
每周监控
不要等用户投诉才检查，应定期审查可用工具，例如以下两个服务：
Google Postmaster Tools 的界面会变化，应核实 2025 年九月域名和 IP 信誉面板的调整在当前版本中的情况，以及哪些数据适用于自身流量。投诉、SPF/DKIM/DMARC 结果和投递错误都可能提供上下文。超过 0.1% 就值得及早检查，不要等到 0.3% 才调查。
Microsoft SNDS（Smart Network Data Services）主要提供向 Outlook、Hotmail 和 MSN 发送的 IP 信号，包括按可用数据展示的流量和潜在垃圾邮件陷阱指标。它不是统一域名投诉面板。出现陷阱信号时，应检查名单来源、授权和质量，而不自动断定名单通过非法收集获得。
TrekMail 架构如何帮助处理这些问题
管理多个域名的 DKIM、SPF 预算、发送量和 IP 信誉需要跟踪。及早发现问题可能减少后续工作，但负担取决于环境和事件。
使用托管 SMTP 的中小企业：所述 TrekMail DNS 向导引导配置 SPF、DKIM 和 DMARC，并在将域名标为就绪前验证记录。但这不保证每封邮件认证正确或实际送达，应测试选择器、路由和标头。初次配置时，在自有域名上设置邮件的指南介绍 DNS 流程。
使用自有 SMTP 的代理机构：如果服务商和套餐支持，将接收与发送分离可能简化出站传输更换。但这本身不会重置域名信誉。
传统方式：客户遇到信誉问题 → 迁移托管服务商 → 可能需要迁移 IMAP 历史并重新配置客户端。工作量取决于架构和迁移范围。
TrekMail 方式：客户遇到信誉问题 → 更换兼容的出站 SMTP 集成 → 可能保留邮箱及历史。仍需配置凭据、认证域名并测试发送，单独替换 API 密钥不一定足够。
在所述架构中，TrekMail 将 IMAP 邮箱与 SMTP 发送分离。Amazon SES、SendGrid、Mailgun 或其他服务商集成取决于支持、套餐和服务条件，并非任何服务商都自动适用于任何域名。更换传输可能避免移动邮箱，但不会清除域名历史，也不保证客户端无需调整。对代理机构来说，5 分钟处理与 3 天迁移说明一种可能差异，而非保证时间。使用自有域名创建邮件的指南帮助准备初始配置。
所述 Starter 每月从 $3.50 起，应核实当前价格、限制和功能。查看各套餐包含内容。
结论
域名信誉影响投递，但不保证进入收件箱。建立与恢复需要时间，并没有固定期限。将 0.3% 投诉视为重要风险信号，分离流量但不假定完全隔离，并验证实际认证。出现封锁时，应诊断原因、暂停受影响活动、停止向已确认无效的地址发送，并谨慎增加发送量。
Gmail、Outlook 和 Yahoo 使用多种过滤信号及各自策略。遵守要求可以降低风险，但不能保证邮件进入收件箱。
