你点击发送，服务器返回 250 OK。两周后才发现邮件没有进入收件箱：它可能在垃圾邮件箱中，也可能因网关策略而在收件人登录前被丢弃。主题和内容同样可能影响结果，另一个可能原因则是持续数周下降的邮件域名信誉。
自 Google 和 Yahoo 在 2024 年二月收紧要求后，符合其定义的发件人和流量必须遵守明确标准。未达到门槛可能降低投递表现或造成拒收，但不代表所有邮件都会被静默屏蔽。本文介绍域名信誉下降的原因、不同错误码提供的线索和恢复方法。如果还需建立 DNS 基础，请先阅读在自有域名上设置邮箱。
邮件域名信誉究竟是什么
邮件域名信誉汇总 Google、Microsoft 和 Yahoo 等邮箱服务商根据历史发信行为形成的信任信号。投诉率高、身份验证失败和名单维护不当都可能损害信誉。业界不存在通用分数或固定恢复时间，各服务商会采用自己的信号并关注近期行为。
信誉也不会自动恢复为默认值。拥有多年良好历史的域名可能承受偶发错误，而受到大量投诉或身份验证失败影响的域名可能需要数周或数月才能改善。结果取决于原因、服务商和后续流量质量。
部分信号可能在根域名层面聚合，但各服务商处理子域名的方式并不完全相同。如果 marketing.example.com 被列入拦截名单，ceo@example.com 不会因此自动进入垃圾邮件箱，不过相关信号仍可能产生影响。分离有助于降低风险，但不是绝对屏障。
最高分类与持续适用的要求
Google 将某个域名归类为批量发件人时，参考标准约为每天向个人 Gmail 账户发送 5,000 封邮件；即使随后减少流量，该分类也可能继续适用。这并非所有服务商都采用的永久状态。对于受规则约束的流量，推广邮件一键退订和发布 DMARC 策略等要求仍然适用；一般规则本身并不强制使用 p=quarantine 或 p=reject。请核实最新政策。
如果每天向 Gmail 发送的邮件低于 ~100 封，Postmaster Tools 可能因数据不足显示 "No Data"。种子账户测试和退信分析只能提供有限线索，不能取代真实数据或保证结论准确。
域名信誉下降的 4 类常见原因
域名信誉下降时，通常应检查四个方面：投诉率、身份验证对齐、SPF 查询限制和永久退信。这并非全部原因。确认影响当前流量的因素，有助于避免采用错误修复方式。
1. 投诉率达到 0.3% 的风险
垃圾邮件投诉可能迅速影响域名。Google 和 Yahoo 会公布各自的门槛与标准。投诉率达到 0.3%，即 3 次投诉/每 1,000 封邮件，会提高过滤风险，并可能影响特定缓解措施的适用资格，但不会造成普遍且即时的拦截。Google 建议保持在 0.1% 以下。0.3% 是风险门槛，不是目标。请核实适用于当前流量的规则。
Yahoo 可能采用不同的基数计算或展示指标。在断言它只以进入收件箱的邮件为分母前，请查看其最新定义。
示例场景：发送 1,000 封邮件，其中 900 封自动进入垃圾邮件箱，100 封进入收件箱，1 人投诉。
示例计算：1 次投诉 ÷ 100 封收件箱邮件 = 1.0% 投诉率。
示例结果：该数值是示例上限的 3×，实际计算仍取决于服务商定义。
打开率可能先下降，但单独的打开跟踪并不可靠。数据充足时，Google Postmaster Tools 可能显示 "Low" 或 "Bad"，界面和标签也可能变化。应结合退信、投诉和 SMTP 响应判断。
2. 身份验证未对齐与伪造信号
即使 SPF 和 DKIM 均已配置，只要两者都未与可见发件人域名对齐，DMARC 仍会失败。DMARC 只要求对齐的 SPF 或 DKIM 其中之一通过，并非两者必须同时通过。反复失败可能损害信誉并呈现为伪造行为，但诊断必须依据完整邮件头。
例如，你使用 Mailchimp 或 SendGrid 等 ESP。SPF 使用的信封发件人指向 mail.sendgrid.net，From 邮件头则指向 yourcompany.com。由于 IP 已授权，SPF 可以通过；但若 DKIM 也未对齐，DMARC 对齐就会失败。ESP 的自定义域名可根据配置对齐 SPF、DKIM 或两者。
在特定身份验证或策略场景中，尤其是高流量邮件，Microsoft 可能返回 550 5.7.515。这不一定是内容拦截，也不总能只靠修改 Return-Path 解决。请阅读完整响应，并按 ESP 文档配置自定义域名身份验证。
3. SPF 的 10 次查询限制 (RFC 7208)
SPF 不是无限列表。RFC 7208 第 4.6.4 节规定，一次 SPF 评估中触发 DNS 查询的术语最多为 10 个。加入 Google、Outlook、Zendesk、Mailchimp 和 CRM 后，可能已经接近限制。嵌套的 include: 指令在求值时也会消耗查询次数。
达到 11 次相关查询时，评估可能返回 PermError。不要假定某些服务商总会通过宽松解析器接受无效 SPF。症状取决于接收方和策略，因此应检查 SPF 结果及完整查询树。
4. 永久退信与地址探测
Microsoft 会关注永久退信。2-3% 可作为审查名单的示例性运营信号，但不是官方规定的自动化行为即时拦截门槛。应区分永久不存在的地址与由策略或身份验证造成的永久错误。可能看到 550 5.7.1，也可能出现 421 RP-001 等临时错误。
即使投诉率为 0%，其他原因仍可能造成拦截。这两类指标不同，但零投诉不保证投递。在联系 Microsoft 地址前，应验证名单并分析增强状态码。
服务商特定信息
要改善域名信誉，先确认哪个服务商在过滤或拒收邮件。各服务商采用不同信号和诊断工具。数据可用性、流量要求和功能都可能变化，应查看最新文档。
| 服务商 | 关注重点 | 主要诊断工具 | 重要说明 |
|---|---|---|---|
| Google (Gmail / Workspace) | 投诉与互动等信号 | Google Postmaster Tools | 发往 Gmail 的低流量 (<100/天) 可能显示 "No Data"；种子测试仅提供样本 |
| Microsoft (Outlook / 365) | 技术合规与 IP 信誉等信号 | SNDS (Smart Network Data Services)，需满足注册及数据条件 | 新 IP 通常应逐步增加流量；限速取决于流量和策略 |
| Yahoo / AOL | 内容与投诉等信号 | 符合资格时可用 Yahoo Sender Hub 与 CFL | Complaint Feedback Loop 需要注册，ARF 报告取决于覆盖范围和条件 |
诊断流程：隔离故障
不要猜测。只对你获准检查的系统执行以下只读查询，然后查看邮件头。结果能提供基础设施、身份验证或发信行为方面的线索，但无法自动确定唯一原因。
终端基础设施检查
修改策略前先检查身份验证栈。以下三项只读查询覆盖常见故障点；请将示例值替换为你有权检查的资源。
# Check SPF - count the includes, verify it ends in ~all or -all
dig txt yourdomain.com +short
# Check DMARC - p= should be quarantine or reject for live domains
dig txt _dmarc.yourdomain.com +short
# Check FCrDNS (Forward-Confirmed Reverse DNS)
# Step 1: Get the hostname from your sending IP
dig -x 1.2.3.4 +short
# Expected output: mail.yourdomain.com.
# Step 2: Verify the hostname resolves back to the same IP
dig mail.yourdomain.com +short
# Expected output: 1.2.3.4
如果 FCrDNS 检查失败，也就是 IP 与主机名不匹配，Gmail、Yahoo 等接收方的拒收风险可能增加，但并不存在统一的自动拒收规则。修正获授权的配置，等待 DNS 生效后再检查。
邮件头取证
向你控制的 Gmail 账户发送一封预期的测试邮件。打开邮件，点击三个点并选择 "显示原始邮件"。查找可信接收服务器生成的 Authentication-Results，不要信任发件人自行插入的副本。
问题信号，对齐失败：
spf=pass smtp.mailfrom=sendgrid.net
dkim=pass header.d=sendgrid.net
dmarc=fail (p=reject) header.from=yourcompany.com
SPF 通过，DKIM 也通过，但 DMARC 失败，因为两个域名都未与 yourcompany.com 对齐。该示例说明可能影响信誉的未对齐配置，但单个样本不能代表全部流量。
正常信号，身份验证已对齐：
spf=pass smtp.mailfrom=em.yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass
恢复方案
如果 Google Postmaster Tools 显示 "Bad"，恢复可能需要 2-4 周或更久的规范优质发信。这不是保证时间，也不是唯一可用的方法。应分阶段操作，并在增加流量前观察服务商响应。
阶段 1：审查名单
不要仅因联系人在 90 天内没有打开或点击就自动清除，因为打开跟踪并不完整。检查同意、真实活动、退信和保留义务；抑制已确认无效的地址以及不期待邮件的收件人。如果同一地址两次返回 User Unknown，应先分析增强状态码和抑制系统，再发送下一批。
阶段 2：技术修复
未经授权、未审查报告及全部合法发件人前，不要将 DMARC 从 p=none 改为 p=quarantine。应逐步部署策略；隔离能减少部分滥用，但不能独自阻止所有伪造。如果使用 1024 位 DKIM 密钥，请先核实算法、兼容性和服务商当前政策，再轮换为 2048 位并更新 DNS。必需 DNS 记录指南介绍 TrekMail 域名使用的格式。
阶段 3：逐步增加流量
先向期待邮件且近期活动有可靠信号支持的收件人发送，不要只依据最近 30 天的打开记录。以下计划仅供示例，必须按服务商、容量和响应调整：
- 第 1 天：50 封
- 第 2 天：100 封
- 第 3 天：200 封
- 第 4 天：400 封
每天查看可用数据。信誉下降时，可考虑暂停 48 小时后恢复到前一天的流量，但这不是通用规则。应根据当前数据和政策调整方案。
基础设施卫生：不易察觉的问题
两类基础设施问题可能在没有明显信号时影响信誉。即使身份验证正确，也应结合其他因素检查加密传输和 IP 池。
TLS 策略
许多服务商会在 TLS 可用时优先使用它，某些流量或政策则要求加密。这不表示每个 MTA 都必须对所有目的地强制 TLS 1.2；SMTP 可以使用机会式 TLS 或针对特定流量的强制策略。请核实 TrekMail 或所用服务商的当前配置和要求。
共享 IP 上的其他发件人
使用低价共享托管或 ESP 免费层级时，你可能与数千个发件人共用 IP。如果其他用户群发垃圾邮件，该 IP 可能进入 Spamhaus SBL，并影响你的邮件，即使滥用并非来自你的域名。影响和处理方式取决于名单与服务商。
月发送量超过 100k 时，独立 IP 可能提供更多控制，但并非普遍更好，而且需要足够流量和持续管理。较低流量可考虑严格管理地址池的服务商或外部 SMTP。TrekMail 的 BYO SMTP 选项可在方案支持时连接 Amazon SES、SendGrid 或 Mailgun；这不一定意味着 IP 归你所有、由你独占控制或具有良好信誉。
TrekMail 在其中的作用
邮件域名信誉是一项运营约束，而非营销变量。它需要准确的 DNS、负责任的收件人管理和合适的出站基础设施。
如果管理多个域名，请参考多域名邮件托管指南来规划结构并降低共同风险。需要深入了解身份验证时，可阅读邮件安全基础指南中的 DMARC 策略和 DKIM 密钥轮换说明。
根据当前方案和配置，TrekMail 可提供入站功能，例如固定费率存储、IMAP 邮箱、catch-all 路由和服务器端迁移；所述方案不按用户计费。出站邮件则连接兼容的 SMTP 服务商。设置向导可在接入时协助配置 SPF/DKIM/DMARC，但仍需验证 DNS 和每个流量来源，不能保证所有邮件自动通过身份验证。
原文所述方案价格从 $3.50/月起，另有需要信用卡的 14 天免费试用，以及无需信用卡、标为免费的 Nano 方案，包含 10 个域名和 5 GB。价格、限制、功能和条件可能变化，请在订购前查看 trekmail.net/pricing。
总结
常见原因包括投诉率超过 0.3%、ESP 配置造成 DMARC 未对齐、超过 SPF 的 10 次查询限制，以及永久退信。这不是全部原因，每一项都需要相应诊断。
域名信誉受损时，应以可靠标准审查名单，逐步修复技术层，并根据服务商响应增加流量。两到四周只是可能的参考范围，并非固定时间或唯一方案。
今天就通过获授权的查询检查 DNS。发现错误后，应规划修正并在下一次营销活动前验证结果。
