支柱指南 · 24 分钟阅读 · 更新于 May 2026

2026 年的邮件送达率 — 标准、预热与反馈循环。

送达率是营销活动进入收件箱与同一营销活动进入垃圾邮件文件夹之间的差异。它是三项认证标准 (SPF、DKIM、DMARC)、一个信誉得分 (IP + From 域名),以及两项运营纪律 (名单卫生、退信处理) 的函数。本指南走通这六者 — 附具体语法、RFC 编号、AcelleMail 的工具,以及一份可粘贴进运维手册的按日预热排期。

本指南内容

  1. 送达率到底是什么
  2. SPF — 发件方策略框架
  3. DKIM — 密码学签名
  4. DMARC — 对齐与报告
  5. BIMI 与品牌 Logo 加成
  6. 信誉 — IP 与域名评分
  7. IP 预热 — 6 周排期
  8. 退信、投诉、反馈循环
  9. 名单卫生 — 抑制与确认
  10. AcelleMail 的送达率工具
  11. 常见问题与修复
  12. FAQ

§1 · 定义

邮件送达率到底是什么。

送达率是您发出的邮件抵达收件人主收件箱的比率 — 与投递 (消息被收件方邮件服务器接受) 和发送 (您把它交给发送流水线) 不同。一条消息可以发送成功、被投递到收件方邮件服务器、最终落入垃圾邮件文件夹 — 这是投递成功而送达率失败。人们关心的数字 — 打开率、点击率、转化 — 取决于送达率,而不是投递。

邮箱服务商 — Gmail、Outlook、Yahoo、Apple iCloud Mail、Proton、主要的地区服务商 — 都对每一封入站消息运行一个多阶段评分流水线。各服务商的阶段大致相同,只是权重不同:

  1. 连接时检查。反向 DNS、HELO/EHLO 合理性、TLS 支持、IP 是否在 RBL (Spamhaus、SpamCop 等) 中。
  2. 认证检查。SPF 通过/失败 (RFC 7208)、DKIM 签名验证 (RFC 6376)、DMARC 对齐 (RFC 7489)。三项都干净通过,下游评分才最宽松。
  3. 内容评分。垃圾关键词密度、链接信誉、图文比、From-name 是否与 From-address 匹配。
  4. 信誉查询。服务商对您发送 IP 与 From 域名的内部记录 — 历史退信率、投诉率、过往发送的互动表现。
  5. 互动信号。收件人 (或同一群组的收件人) 此前是否打开或点击过您类似的消息?近期互动是最强的单一正向信号。
  6. 处置。收件箱、推广分区 (Gmail)、垃圾邮件文件夹或拒收。处置结果又反馈回信誉。

下面五节针对阶段 2 (认证) 与阶段 4 (信誉)。阶段 1 主要是发送中继的工作;阶段 3 和 5 是内容 + 受众决策,超出送达率指南范围。阶段 6 是输出。对一个典型的商业发件方,把阶段 2 和 4 做对,可以把收件箱投放从 60-80% 提升到 95%+。

本指南为自托管运营者撰写,因为您才是调节旋钮的人。在 SaaS 上平台帮您抽象了大部分;在自托管上,您拥有 SPF 记录、DKIM 密钥对、DMARC 策略、IP 预热排期。好消息:标准是公开且稳定的。坏消息:没有捷径。

§2 · SPF

SPF — Sender Policy Framework。

SPF (RFC 7208) 是被授权代表您域名发送邮件的 IP 地址公开清单。您将其以一条 TXT 记录发布在发送域名上。当邮箱服务商收到一条声称来自 @yourcompany.com 的消息时,它会查询 yourcompany.com 处的 SPF 记录并询问:这条消息是否来自所列 IP 之一?是,则 SPF 通过;否,则 SPF 失败。

语法

v=spf1 include:amazonses.com ~all

读作:"SPF 版本 1,授权 Amazon SES 授权的任何东西,对其他一切软失败。"末尾的 ~all 是兜底子句。~all = 软失败 (标记可疑但接受);-all = 硬失败 (拒收);?all = 中立 (无意见)。在 DMARC 健康前使用 ~all,之后再收紧到 -all

多个发件方 (例如出站走 Google Workspace + 营销走 SES + 事务走 Mailgun) 通过多个 include: 机制串接:

v=spf1 include:_spf.google.com include:amazonses.com include:mailgun.org ~all

10 次 DNS 查询上限。RFC 7208 §4.6.4 将 SPF 解析的 DNS 查询总数限制在 10 次。每个 include: 算一次。一种常见失败:串接 5+ 厂商触碰上限,SPF 随后被解析为 permerror 并被当作失败。如果接近上限,用 dig TXT yourcompany.com + SPF flattener 审计。

AcelleMail 中的 SPF

AcelleMail 的 SendingDomain 模型在 app/Model/SendingDomain.php:154 暴露 getSpf(),它读取全局 spf_record 设置并渲染 TXT 记录值。第 363 行的 verifySpf(string $ipOrHostname) 方法包装 Mika56\SPFCheck 库 — 运行时查询活动 DNS 并断言 RESULT_PASS。管理 UI 中的验证面在记录存在且授权发送 IP 时显示绿色,否则显示红色。

实操贴士:SPF 只认证信封发件人 (SMTP 级别的 MAIL FROM),不认证可见的 From 头。这一区别正是 DMARC 对齐要解决的 — 见§4

§3 · DKIM

DKIM — DomainKeys Identified Mail。

DKIM (RFC 6376) 为每一封出站消息附加密码学签名。收件方服务器从 DNS 的 TXT 记录拉取您的公钥,针对特定消息头与正文验证签名,数学校验通过即认证消息真实。SPF 说"这个 IP 被允许代表我们发送";DKIM 说"这一封消息的正文与 From 头自签名以来没被篡改"。

机制

  1. 您生成一对 RSA 密钥对 (最低 1024 位,新部署建议 2048 位)。
  2. 公钥以 TXT 记录形式发布到 DNS 的 {selector}._domainkey.{yourdomain}。selector 是您挑选的任意字符串 (例如 k1mail20251208),用于在不中断在途消息的情况下轮换密钥。
  3. 私钥留在您的发送服务器上。MTA (或发送中继) 用它给每封出站消息签名,加入一个 DKIM-Signature 头。
  4. 收件方邮件服务器从签名头读取 d= (域名) 与 s= (selector),查询 {s}._domainkey.{d},拉取公钥并验证。

AcelleMail 中的 DKIM

SendingDomain::generateDkimKeys() 位于 app/Model/SendingDomain.php:221,通过 PHP 的 OpenSSL 绑定生成一对 1024 位 RSA 密钥对,把私钥存到 dkim_private,公钥存到 dkim_public。selector 从模型上的 dkim_selector 读取,若无则回退到全局 dkim_selector 设置。DNS 记录值通过 $this->getDomain()->getDkimDnsRecord() (第 270 行) 渲染,并在"待发布的值"旁附带复制按钮展示给运营者。

密钥生成模式 (来自 generateDkimKeys()):

$config = [
    'digest_alg' => 'sha256',
    'private_key_bits' => 1024,
    'private_key_type' => OPENSSL_KEYTYPE_RSA,
];
$res = openssl_pkey_new($config);
openssl_pkey_export($res, $privKey);
$pubKey = openssl_pkey_get_details($res)['key'];

验证:$this->getDomain()->verifyDkim() 查询 DNS 的 {selector}._domainkey.{domain},并将已发布的公钥与本地存储的值对比。模型上完整的 verify() 方法 (第 300 行) 在一次调用中编排身份 + DKIM + SPF + DMARC 检查。

厂商托管的 DKIM

如果您通过 Amazon SES、SendGrid、Mailgun 或任何在其侧签名的厂商发送,您发布的是厂商的 selector + 公钥,而不是自己生成。AcelleMail 驱动级的 SignsDkimOnServer 能力 (见 app/SendingServers/Capabilities/SignsDkimOnServer.php) 标记远程处理 DKIM 的驱动;UI 随即显示要发布的厂商 CNAME 记录,而不是生成本地密钥对。SES 使用三条把 _domainkey 委派给 amazonses.com 的 CNAME — 一次设置后,SES 会为您轮换底层密钥。

§4 · DMARC

DMARC — 对齐、策略与报告。

DMARC (RFC 7489) 位于 SPF 与 DKIM 之上。它做三件 SPF 与 DKIM 单独都不做的事:

  1. 对齐。要求经过 SPF 验证的信封域名 DKIM 签名域名匹配可见的 From 头域名。没有对齐,SPF 与 DKIM 可以为一个不同于收件人看到的域名通过 — 这正是钓鱼利用的缺口。
  2. 策略。告诉收件方服务器对齐失败时怎么办:none (什么都不做,只报告)、quarantine (投递到垃圾邮件)、reject (在 SMTP 层拒绝消息)。
  3. 报告。聚合报告 (RUA — 来自您域名所有发送的日度 XML 报告) 与取证报告 (RUF — 按失败的单独报告) 发送到您指定的地址。报告让您看清谁在以您的名义发送邮件。

语法

_dmarc.yourcompany.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100; aspf=s; adkim=s"

读作:"DMARC 版本 1,隔离对齐失败的消息,将聚合报告发送到 dmarc@yourcompany.com,对 100% 的失败消息应用策略,SPF 与 DKIM 都要求严格对齐。"

标准上线流程

  1. 第 0 天:发布 p=none,rua= 指向一个有人监控的邮箱。接收报告 7-14 天。这是仅观察 — 没有消息被拒收。
  2. 第 14 天:审阅报告。识别合法发件方 (您自有的 SES、CRM 的发送 IP、事务性服务商),并把它们全部带入 SPF + DKIM 对齐。
  3. 第 30 天:收紧到 p=quarantine; pct=10。未对齐邮件对 10% 收件人进入垃圾邮件。观察报告两周。
  4. 第 45 天:升级到 pct=50,然后用 2-4 周升到 pct=100
  5. 第 60-90 天:收紧到 p=reject。现在未对齐邮件在 SMTP 层硬退 — 冒用您域名的钓鱼者看到硬拒。

别跳过上线流程。从无 DMARC 直接跳到 p=reject 是最常见的自残式送达率灾难:某个被遗忘的事务发件方 (您的 CRM、支持工具、计费系统) 在 p=reject 传播的瞬间开始硬退。

邮箱服务商强制要求

截至 2024 年 2 月,Gmail 与 Yahoo 要求任何向其域名每日发送 > 5,000 封的发件方部署 DMARC,加对齐的 SPF 或 DKIM,加一键 List-Unsubscribe (RFC 8058)。撰写本文时 Microsoft 365 已与同一标准对齐。"商业发送"的门槛已永久上移 — 对任何超过约 1,000 联系人的名单,DMARC 都不再可选。即便您的名单仍小,也应尽早配置。

§5 · BIMI

BIMI — 品牌 Logo 加成。

BIMI (Brand Indicators for Message Identification) 在收件人收件箱中您消息旁显示品牌 Logo。Gmail、Yahoo、Apple Mail、Fastmail 自 2025 年起支持。它是送达率邻近功能 — 本身不是认证 — 但要求 DMARC 处于 p=quarantinep=reject 作为前置,这也是它进入本指南的原因。

配置步骤 (DMARC 处于 quarantine 或更严之后):

  1. BIMI SVG Tiny PS 规范创建您 Logo 的 SVG 版本 — 方形、标识外无文字、路径简洁。
  2. 将 SVG 托管在公开可访问的 HTTPS URL 上。
  3. 可选地从 CA 获取 Verified Mark Certificate (VMC) — Gmail 要求它才显示带蓝色对勾的徽章,约 $1,500/年。未注册品牌可用更便宜的 Common Mark Certificate (CMC) 替代。
  4. 发布 BIMI 记录:default._bimi.yourcompany.com TXT "v=BIMI1; l=https://yourcdn/logo.svg; a=https://yourcdn/vmc.pem"

BIMI 对送达率的影响是间接但可度量的:已发布案例 (Yahoo Mail 试点数据、Mailchimp BIMI 报告) 中收件箱内品牌 Logo 把打开率拉高 5-20%。它也是强力的促动函数 — 不先收紧 DMARC 就无法启用 BIMI,所以团队拿它作为认证清理的胡萝卜。

§6 · 信誉

信誉 — 邮箱服务商到底在评什么。

认证是二元的 — 记录要么解析并对齐,要么不。信誉是连续的:每家邮箱服务商分别对您的发送 IP 和 From 域名维护一个 0-100 的得分。两个得分共同构成路由决策 (收件箱 vs 推广 vs 垃圾邮件 vs 拒收)。

信号

最强正向

互动

收件人打开、点击、回复、把消息移出垃圾邮件。现代 (2020 年后) 服务商评分中最大的单一正向信号。

量信号

发送一致性

稳定的周度发送 (每周二 10K) 信号合法运营。无历史的 50K 突发触发量级异常检测。

最强负向

投诉率

收件人点击"举报垃圾"。目标 < 0.1% (每千分之一)。高于 0.3%,各服务商的路由会在 48 小时内崩塌。

负向

退信率

硬退信 (5xx — 地址不存在) 信号名单卫生差。目标 < 2%。持续高于 5%,多数服务商会强力节流。

硬失败

垃圾陷阱命中

发送到服务商种入名单购买源或从废弃邮箱重新激活的地址。一次"原始陷阱"命中 = 在多数主要服务商上立即入黑名单。

中立但被关注

退订率

健康名单每次发送 0.1-0.5%。退订好过投诉 — 它是"这与我无关"的礼貌版本。不要让退订变难。

在哪查看您的信誉得分

  • Google Postmaster Tools (postmaster.google.com) — Gmail 视角的 IP 与域名信誉,以及认证合规、加密率、垃圾率。免费。
  • Microsoft SNDS (postmaster.live.com/snds/) — Outlook.com 的 IP 级数据、发件方信誉分类。免费,需注册。
  • Yahoo Sender Hub — 较新,通过 Yahoo Postmaster 页面注册。按域名的汇总统计。
  • 服务商仪表盘 — Amazon SES Reputation Dashboard 展示退信 + 投诉率与阈值。SparkPost、Mailgun、SendGrid 都有类似的。

至少每周看一次。先行指标 (垃圾率趋势、IP 信誉下跌) 比下游影响 (打开率下跌) 早数天出现 — 等您注意到某场营销活动表现不佳时,信誉问题已经存在两周了。

§7 · IP 预热

IP 预热 — 6 周排期。

一个新发送 IP 从零信誉起步。邮箱服务商按设计对来自新 IP 的高量进行节流 — 这是抵御"雪鞋垃圾发件方"开云实例突击发送的主要防线。预热是在 4-6 周内逐步提升发送量、同时保持在按日与按时节流上限内的实操,以有机方式建立信誉。

每个 IP 只做一次。多数团队从来不做,因为 Amazon SES、SendGrid 与 Mailgun 的共享 IP 是预热好的。预热确有必要的场景:SES 上的独享 IP (通常 > 100 万封/月才值得申请一个)、新云实例上自托管的 Postal MTA、从一个 ESP 切到另一个并更换域名的迁移。

排期

每日发送量 受众群组 关注指标
150互动最活跃的 5%打开率 > 30%
2100互动最活跃的 5%退信 < 2%
3-4200-500互动前 10%收件箱投放 (服务商工具)
5-71K-2K前 25%投诉 < 0.1%
8-145K → 20K前 50%SES reputation dashboard 转绿
15-2125K → 100K前 75%Postmaster Tools spam < 0.1%
22-42满日发送量完整名单 (排除 6 个月以上不活跃)打开率稳定,退信低

排期基于 SparkPost / Postmark / SES 发布的预热建议,合并为一张按周的表格。如果看到投诉率向上,放慢节奏;只在服务商确认每一步都信誉绿灯时才加速。

AcelleMail 中的预热追踪

AcelleMail 的 SendingServer 模型有一等公民的预热状态。warmup_enabledwarmup_strategy_idwarmup_started_at 位于 sending_servers 表;app/Model/SendingServer.php:333isWarmupEnabled() 门控发送时的决策。配套的 SendingServerWarmupLog 表记录预热窗口内的每次发送,带日期、状态与序列化 meta 载荷 — 见 app/Model/SendingServerWarmupLog.php

模式:为发送服务器分配一个 WarmupStrategy (定义按日发送量曲线的一行记录),将 warmup_enabled 翻为 true,把 warmup_started_at 设为 now()。发送流水线的 SendingServerWarmupUsage 追踪今日计数,并拒绝超过策略每日上限的派发。当策略的第 N 日上限超过您完整日发送量时,服务器毕业、预热模式自动关闭。

DynamicRateTrackerInMemoryRateTracker 类 (app/Library/) 在 SMTP 层处理按分钟 / 按小时的速率限制 — 即便不在预热中,AcelleMail 也会执行中继公布的速率上限,以免队列突发触发服务商侧节流。

§8 · 退信 + 投诉

退信、投诉与反馈循环。

硬退信 vs 软退信

硬退信是永久失败 — 典型的 5xx SMTP 码:地址不存在、域名无法解析、收件人邮箱永久禁用。AcelleMail 的 BounceLog 模型在 app/Model/BounceLog.php:33 定义 HARDSOFT 常量;硬退信立即抑制地址。软退信是瞬态的 — 4xx 码:邮箱满、服务器临时不可用、消息过大。软退信按退避计划重试;跨发送多次软退的地址最终被降为硬退。

AWS SES 退信通知的分类映射 (AcelleMail 的 BounceLog.php:32 文档引用的来源):退信类型包括 Permanent (硬),子类型 General / NoEmail / Suppressed / OnAccountSuppressionList;Transient (软),子类型 General / MailboxFull / MessageTooLarge / ContentRejected / AttachmentRejected;以及 Undetermined (按软处理,重试)。

投诉

投诉是收件人在邮件客户端中点击"举报为垃圾"。投诉通过反馈循环 (FBL) 到达 — 一种按服务商的通知渠道,ISP 把被举报的滥用消息转发给您。AcelleMail 的 FeedbackLoopHandler 位于 app/Model/FeedbackLoopHandler.php,通过 IMAP/POP 处理入站 FBL 消息,并解析 Abuse Reporting Format (ARF, RFC 5965) 头以提取原始 message ID 与反馈类型。

AcelleMail 处理的 ARF 反馈类型 (按第 35 行的 FeedbackLoopHandler::FEEDBACK_TYPES):

  • abuse — 收件人明确标记为垃圾。立即抑制。
  • fraud — 收件人标记为钓鱼。抑制 + 记入安全审查。
  • virus — 收件人杀软标记了载荷。抑制 + 审计内容。
  • other — 通用投诉。抑制。
  • not-spam — 明确的"这不是垃圾"举报 (罕见)。从抑制中排除 — 见 EXCLUDED_FEEDBACK_TYPES

参与 FBL 的主要邮箱服务商:AOL、Yahoo、Microsoft (通过 JMRP)、Comcast、BlueTie。Gmail 不运行公开 FBL — 他们通过 Postmaster Tools 仪表盘与聚合的 DMARC 报告交付"标记为垃圾"反馈。

抑制规则

  1. 硬退信 → 永久抑制。永不重试;地址已死。
  2. 投诉 → 永久抑制。收件人已主动要求停止。再发送在多数司法辖区都违法,且会毁掉信誉。
  3. 30 天内 3 次软退信 → 降为硬,抑制。持续的软退信是邮箱满或持续连通问题 — 当死处理。
  4. 退订 → 对营销抑制,对事务不抑制。订单回执与密码重置照常;营销活动停止。
  5. 垃圾陷阱命中 → 升级到调查。把该订阅者的整个获取来源拉下来。名单很可能被购买或抓取地址污染。

§9 · 名单卫生

名单卫生 — 让信誉保持在高位的纪律。

认证是一次性配置。信誉是运营纪律。能拨动指针的七项习惯:

  1. 所有营销注册都启用双重确认。地址进入活跃名单前确认一次点击。消除拼写错误、角色地址 (info@sales@) 与抓取地址。给注册增加 10-20% 摩擦;削减 50-80% 的退信/投诉风险。
  2. 一键退订 (RFC 8058)。指向一键 URL 的 List-Unsubscribe 头。Gmail 与 Yahoo 自 2024 年 2 月起对其域名 > 5K/天的发件方要求。让退订比投诉更容易 — 本来要点"垃圾"的收件人就点了"退订"。
  3. 抑制前先唤回。90 天未打开的订阅者收到"我们想继续保持相关"的营销活动。打开 → 保留。未打开 → 移入落日队列。180 天后仍未打开 → 抑制。
  4. 退信自动抑制。分钟级处理退信 webhook;在下一场营销活动前从活跃发送名单移除。AcelleMail 的 BounceLog::record()vbrandsync 风格的退信 webhook 处理器自动完成此事。
  5. 永远不要导入购买的名单。购买名单会种入垃圾陷阱。一次陷阱命中,您的域名在 Spamhaus 上 30+ 天。算式从来不成立 — 购买名单是永久的信誉沉没。
  6. 按互动度细分。对活跃 50% 发送频率加倍,对沉睡 50% 减半。提升整体打开率,降低投诉率,并给邮箱服务商一个强烈的"这位发件方很相关"信号。
  7. 限制自动化节奏。欢迎序列 + 购物车挽回 + 购后 + 生日 + 唤回一周内可能产生 8 条消息。把按收件人的自动化消息总数限制在每 48 小时一条,事务 (回执、密码重置) 硬性例外。

§10 · AcelleMail 工具

AcelleMail 的送达率工具 — 源代码交付什么。

直接从 app/Model/app/Library/ 下的源树拉取。每一条都是真实的模型、能力接口或库类 — 不是营销话术。

app/Model/SendingDomain.php

DKIM / SPF / DMARC 验证

generateDkimKeys() 在第 221 行 (通过 OpenSSL 生成 1024 位 RSA)。verifySpf() 在第 363 行包装 Mika56\SPFCheckverify() 在第 300 行,一次调用编排身份 + DKIM + SPF + DMARC。

app/Model/BounceLog.php

退信分类

HARD / SOFT / UNKNOWN 常量。BounceHandler 处理入站退信邮件;SES webhook 载荷直接解码到 AWS 退信类型分类法。

app/Model/FeedbackLoopHandler.php

FBL 处理 (ARF / RFC 5965)

通过 IMAP 处理 AOL、Yahoo、Microsoft JMRP 反馈循环。解析 ARF 头以还原原始 message ID + 反馈类型。在 abuse / fraud / virus / other 上自动抑制。

app/Model/SendingServerWarmupLog.php

预热状态追踪

针对 WarmupStrategy 的按日发送日志。与 SendingServerWarmupUsage 配对,实现日上限执行。SendingServer 上的 isWarmupEnabled() 门控派发路径。

app/Library/DynamicRateTracker.php

按分钟 / 按小时的速率限制

每台发送服务器上的 quota_value / quota_base / quota_unit。默认上限 — 100/分钟、1K/小时、10K/天 — 匹配 SES sandbox 模式上限。随着中继提升您限额,按服务器调整。

app/Library/IdentityStore.php

已验证发件方注册表

跨暴露 SupportsRemoteDomainVerify 的驱动缓存按域名 + 按邮箱的验证状态。避免每次发送都重复检查已验证域名;按 TTL 刷新。

app/SendingServers/Capabilities/

驱动能力标志

SignsDkimOnServerSupportsRemoteDomainVerifyReceivesWebhooksSendsCustomVerificationEmailSupportsCustomReturnPathAllowsCrossSendingDomain。UI 只展示每个驱动实际需要的步骤。

app/Model/TrackingDomain.php

自定义点击追踪域名

让您从 links.yourcompany.com 而非中继默认追踪域名提供点击跳转。提升收件箱内品牌一致性;隔离链接信誉与通用 ESP 基础设施。

§11 · 故障排除

常见送达率问题与修复。

"打开率一夜下跌 30%"

先查:Apple Mail Privacy Protection (MPP)。Apple 在其代理服务器上打开邮件,把打开率基线虚高 20-40%;iOS 更新可能重置代理,看起来像真实下跌。

再查:Postmaster Tools 垃圾率突涨。若 > 0.1%,您在 Gmail 已进入垃圾箱区间。

修复:若是 MPP,无需担心 — 转用点击率作为互动信号。若是信誉,暂停冷群组,用 2 周仅向活跃用户发送的节奏重建互动。

"Gmail 把我们投到推广,不是收件箱"

现实:自 2013 年起,推广就是 Gmail 商业发件方的收件箱。打开推广分区邮件的收件人算作正向互动。别浪费信誉追主分区;在推广优化互动。

"DMARC 报告显示第三方在以我们名义发信"

几乎总是:您拥有的某域名上有一个被遗忘的事务发件方 (Salesforce、Zendesk、Stripe 回执)。修复:逐个识别,将其 include: 加入 SPF、CNAME 加入 DKIM,重新测试。对齐后,把 DMARC 升级到 p=reject

"我们上了 Spamhaus 黑名单"

立即停止发送。spamhaus.org/lookup 识别上榜类别 (ZEN、SBL、XBL、PBL)。PBL 是策略性的,容易修;SBL 是信誉;XBL 与恶意软件相关。

修复:通过 Spamhaus 的下榜表单请求下榜,记录纠偏动作 (强力抑制、审计获取来源、暂停发送 24 小时)。多数上榜在快速行动并有记录时 24-72 小时内清除。再次上榜清除较慢。

"退信率从 1% 跳到 8%"

要么名单导入污染了活跃集合,要么您对长期沉默的群组发送,一次性收割了全部死地址。修复:暂停发送,回溯抑制退信地址,审计最近的获取来源,接下来 2 周仅对 90 天内活跃群组发送,直到退信率恢复。

"Outlook.com 投到 Junk,Gmail 没事"

按服务商的信誉不同。Outlook 对新域名往往更严;Gmail 更看重互动。修复:注册 Microsoft SNDS,识别您 IP 的上榜分类,对活跃 Outlook 收件人发送慢速爬坡营销活动,观察 SNDS 在 2-4 周内转绿。

§12 · FAQ

邮件送达率 FAQ。

SPF 与 DKIM 与 DMARC 都要部署吗,还是一个就够?

三者都要。SPF 认证发送 IP;DKIM 认证消息正文与头;DMARC 把 From 头绑到二者之一,并告知收件方在对齐失败时怎么办。Gmail、Yahoo 与 Outlook 把不发布三者全部的现代商业发件方视为可疑。2024 年 2 月的 Gmail/Yahoo 批量发件方要求让这成了硬底线,而非建议。

如果用 SES 或 SendGrid 的共享 IP,可以跳过预热吗?

可以 — 这正是共享 IP 的价值。SES 生产 IP 是已预热的成熟信誉;您继承它。预热仅在您切到独享 IP (通常 > 100 万封/月才值得申请一个) 或在新云实例上启用自托管 Postal MTA 时才需要。

好的投诉率是多少?

低于 0.1% (每千分之一) 是健康。低于 0.05% 是优秀。持续高于 0.3%,各服务商的路由会在 48 小时内退化。Amazon SES 执行硬性 0.1% 投诉率上限 — 超过则账户被暂停审查。

有办法在发送营销活动前测试送达率吗?

两个实操工具:一份种子名单 (您在 Gmail、Outlook、Yahoo、Apple、Proton 上维护账户;先把营销活动发给种子名单;检查收件箱 vs 垃圾)。以及第三方种子服务 (GlockApps、Mailtrap、Litmus),按 $50-100/次给您一份跨 30+ 服务商的投放报告。种子名单免费 + 慢;第三方付费 + 全面。

送达率问题修复需要多久?

认证误配 1-4 小时加 DNS 传播。信誉恢复是 2-6 周的纪律性发送 — 仅活跃群组、低节奏,观察指标重建。Spamhaus 上榜在快速行动时 24-72 小时清除。最长的尾巴是从投诉率突涨恢复 — 突涨快,爬升慢。

营销邮件应该用子域名吗?

应该。从 marketing.yourcompany.comnews.yourcompany.com 发营销;从 notify.yourcompany.com 发事务;从根域发企业邮件。信誉是按域名的 — 隔离营销可避免某场营销活动的投诉率突涨影响您的密码重置送达率。所有主流 SaaS 发件方的标准做法。

BIMI 是什么,值得付出成本吗?

BIMI 在支持的客户端 (Gmail、Yahoo、Apple、Fastmail) 中您消息旁显示品牌 Logo。SVG 托管 $0,Verified Mark Certificate (VMC) $1,500/年,后者是 Gmail 显示蓝色对勾的条件。已发布案例显示打开率提升 5-20% (Yahoo Mail 试点数据、Mailchimp BIMI 报告)。对 B2C 订阅者 > 10 万的发件方值得;以下边际。

Apple Mail Privacy Protection (MPP) 会破坏打开追踪吗?

MPP 把打开像素路由经过 Apple 代理,所以每一封 Apple Mail 消息在投递的瞬间看起来都被"打开"。打开率对 Apple 读者而言成了投递指标,而非互动指标。转用点击率、回复率、转化作为互动信号;将整体打开率仅当作基线偏移后的先行指标。约 30-40% 的消费者邮件打开经过 MPP。

一键退订是否真的必需?

对 Gmail 或 Yahoo 域名每日 > 5,000 封的发件方:是,自 2024 年 2 月起。技术要求是一个指向一键 POST URL 的 List-Unsubscribe 头 (RFC 8058)。按钮必须无需登录或确认页就能处理退订。未满足是被路由到垃圾邮件的理由。

通过更换发送 IP 能否提升送达率?

很少是对的招式。换 IP 需要全新预热 (4-6 周降级量),而底层信誉问题通常来自 From 域名或名单质量,而非 IP。例外:IP 上有确认的 RBL 上榜且不清除,或 ESP 迁移且新 ESP 要求其自有 IP。先解决名单质量与认证。

已认证的域名。已追踪的退信。收件箱级的信誉。

AcelleMail 开箱即用交付 SPF/DKIM/DMARC 验证、ARF 反馈循环处理、IP 预热状态机与按服务器的速率限制。本指南中的每一项主张都映射到源树中 AcelleMail 的 app/Model/app/Library/ 中的一个类。

获取 AcelleMail — $80 试用在线演示