Substack、beehiiv、Ghost 的域名问题不能混成一句「发信认证没配好」。Substack 更像品牌访问域名；beehiiv 和 Ghost 才会把你的域名放进发件人身份、DNS 记录、退信和域名声誉里一起考核。

我在 2026-05-24 比对的后台路径是：Substack Settings -> Domain，beehiiv Settings -> Domains，Ghost(Pro) Ghost(Pro) -> Domains。本文不覆盖冷邮件系统、企业邮箱迁移，也不承诺配置完成后一定进主收件箱。

##分清哪几个域名？

一套 Newsletter 至少有四个名字：网站访问域名、发信域名、根域名、跳转域名。中文创作者最常见的错误，是把 newsletter.example.com 能打开，误认为 [email protected] 已经被邮箱服务商认可。

名称例子主要影响看哪个后台
根域名example.com品牌、DMARC 继承、重定向域名商 / Cloudflare
访问子域名newsletter.example.com读者打开 publicationSubstack / beehiiv / Ghost
发信域名mail.example.com 或 example.comFrom、SPF、DKIM、DMARCbeehiiv / Ghost / Mailgun
链接域名click.example.com跳转跟踪、品牌链接beehiiv 或邮件服务商

Substack 官方文档写得很清楚：自定义域名要先在后台添加，再去 DNS 添加 CNAME；配置完全生效最多可能需要 36 小时。它还说明，自定义域名不会让 Newsletter 从你的域名发出，邮件仍从 Substack 的 publication 地址发送。

Substack 要不要配 SPF、DKIM、DMARC？

只用 Substack 发 Newsletter 时，先别急着自己写 SPF、DKIM、DMARC，第一步是确认自定义访问域名没有被误当成自定义发件域名。你要做的是让 www.example.com 或 newsletter.example.com 正确指向 Substack，并确认 Cloudflare 这类代理服务对 CNAME 使用 DNS only。

如果你同时用 Google Workspace、ConvertKit、beehiiv、Ghost 或企业 CRM 从同一个根域名发信，DMARC 仍然重要。原因不是 Substack 要你配置，而是 Gmail 和 Yahoo 会看整个 From 域名、SPF / DKIM 对齐、投诉率、退订和历史声誉。

一个实用做法是把 Substack 放在访问子域名上，把真正发信的工具放在单独子域名上。比如 read.example.com 给 Substack，mail.example.com 给 beehiiv 或 Mailgun。这样排查时不会把 CNAME 访问问题和发件身份问题混在一起。

beehiiv 的 DNS 记录怎么抄？

beehiiv 的自定义域名更像一套完整邮件系统。官方文档说，设置 custom domain 时可以同时配置 web domain、redirect domain、email sending domain；手动模式下要逐条复制 Type、Name、Value。beehiiv 还提醒，自定义域名用户必须配置 DMARC。

不要从网上复制别人的 SPF。beehiiv 会在自定义域名流程里生成记录，SPF 和 DKIM 通常通过 CNAME 交给平台处理；你真正要补上的，是 _dmarc 这条 TXT，以及报告邮箱。

DNS 项写在哪里排查重点
所有权 TXT根域名或指定 HostHost 是否被域名商自动补全
Web CNAMEnewsletter / www是否和旧站点 CNAME 冲突
Email CNAMEbeehiiv 后台给出的 Host不要改 Value，只复制
DKIM CNAME多条 selector 记录selector 少一条也会失败
DMARC TXT_dmarc.example.com新域名先用 p=none 观察
Branded link CNAMEclick 等子域名Cloudflare 代理可能影响验证

DMARC 报告邮箱建议单独建，例如 [email protected]。beehiiv 文档也提醒，报告地址会公开出现在 DNS 里；别填私人常用邮箱，否则报告量上来会淹没正常邮件。

Ghost 和 Mailgun 怎么分工？

Ghost(Pro) 默认会处理 newsletter 投递；如果你要启用 custom sending domain，Ghost 要求域名上有 DMARC 记录。Ghost 还写明，新 custom sending domain 没有历史声誉，会逐步预热，大约 6 周内部分 Newsletter 仍可能通过 ghost.io 发出。

自托管 Ghost 是另一套逻辑。Ghost developer docs 写明，批量 Newsletter 要在 Email newsletter settings 里配置 Mailgun API；普通 SMTP 不能承担批量 newsletter。SMTP 可以处理成员登录等非批量邮件，但不要拿它直接发大列表。

如果你迁移自 Ghost，自查顺序是：Mailgun 域名验证、DKIM、SPF、DMARC、Webhook、Ghost 后台 newsletter 设置，让一封测试邮件在 Gmail 的「显示原始邮件」里看到 SPF、DKIM、DMARC 结果，再安排正式迁移。

退信先看哪一行？

退信不要只截一句「delivery failed」，保存原文，尤其是 SMTP code、接收方域名、Authentication-Results、From、Return-Path、DKIM d= 域名。Gmail 和 Yahoo 都会把认证失败、PTR、TLS、退订和投诉率放进投递判断里。

现象常见线索第一动作
Gmail 4.7.27SPF authentication did not pass查 SPF 是否包含当前平台
Gmail 4.7.30DKIM authentication did not pass查 DKIM selector 和 CNAME
DMARC failFrom 域名未和 SPF / DKIM 对齐看 d= 和 Return-Path 域名
Yahoo 拒收未认证或 DMARC 策略触发查 SPF、DKIM、DMARC 三项
企业邮箱退回网关策略、附件、短链、信誉换纯文本测试样本
全部进垃圾箱新域名声誉低或投诉高降频、清单、做预热

Google 的 sender guidelines 还给了一个硬数字：发送到个人 Gmail 账号接近或超过每天 5,000 封时，会按 bulk sender 要求看 SPF、DKIM、DMARC、From 对齐、一键退订和投诉率。它建议 spam rate 保持在 0.30% 以下。

跨地区使用和团队协作怎么安排？

DNS、付款、发刊和邮件认证都属于高风险后台操作。不要让作者、运营、外包设计同时登录域名商和 Newsletter 后台；一个人改 DNS，另一个人只做复核，所有记录保存截图和时间。

如果团队成员经常跨城市或跨时区处理域名商、Stripe、Ghost Admin、beehiiv Domains 这些核心后台，可以把主账号绑定固定设备，并使用 长期稳定家庭 IP + 单设备绑定 这类固定工作环境。它不提升邮件送达率，但能减少后台登录提醒和责任不清。

上线前 30 分钟怎么检查？

发刊前不要再同时改标题、域名、发件人、付费墙和退订设置，用内部名单发一封短文，覆盖 Gmail、Yahoo、Outlook、企业邮箱四类地址；每个样本记录收件时间、分类、Authentication-Results 和退订入口。

时间点检查项不通过怎么办
T-30 分钟访问域名能打开回滚到平台默认域名
T-25 分钟Gmail 原文认证结果修 DNS，不发正式稿
T-20 分钟Yahoo / Outlook 是否收到记录退信，缩小样本
T-15 分钟退订入口可用暂停营销邮件
T-10 分钟付费链接和登录邮件分开测试付款和登录
T-5 分钟后台无验证错误保持原设置，不再改

新域名第一次群发时，少发比硬发更重要。Ghost 的 6 周预热机制就是这个思路，让域名积累正常互动，再逐步提高比例。beehiiv 或其他平台没有替你承诺主收件箱位置时，也按同样原则控制节奏。

Substack 发信域名认证 不覆盖什么

没有测试每一家域名商的 UI，也没有验证企业邮箱网关的私有规则。Cloudflare、Namecheap、GoDaddy、阿里云国际站的 Host 自动补全方式不同，最终以你后台实际展示的 Type、Name、Value 为准。

也不要把 DMARC 当成唯一答案。SPF、DKIM、DMARC 通过后，内容过度营销、列表来源不干净、退订入口难找、读者长期不打开，仍会让 Gmail、Yahoo 或企业网关把 Newsletter 分到垃圾箱。

相关阅读