TL;DR

Substack 自定义域名邮件认证要拆开做：先让 publication 域名能访问，再确认发送身份和 DNS 记录，最后用 Gmail、Outlook、企业邮箱各测一轮。别在发刊当天改 DNS。

上线前要准备什么？

项目准备内容备注
域名后台登录权限、DNS 管理权限不要只找代购商截图
Substack 后台publication 设置权限主账号操作
邮箱样本Gmail、Outlook、企业邮箱测试送达
回滚方案旧记录截图写错能恢复
时间窗口非发刊日避免影响读者

我通常把 DNS 修改安排在周二或周三上午。这样出问题还有工作日可以联系域名商或平台支持，不会卡在周末和发刊前一小时。

第一步：先区分两个域名问题

自定义域名是读者访问地址，例如 newsletter.example.com。邮件认证关注发件身份，例如邮件是否能被邮箱服务商识别为可信来源。它们都可能要求你改 DNS，但不是同一件事。

Substack 的自定义域名文档会要求你按后台提示添加记录。这里最容易错的是把根域名、www、子域名混在一起。若你决定用 newsletter.example.com，就不要同时在多个入口乱配，先让一个入口稳定。

第二步：按后台逐条写 DNS

操作时不要手打长字符串。复制记录类型、主机名和值，再保存截图。常见记录可能是 CNAME 或 TXT，具体以 Substack 后台和域名商界面为准。若域名商自动补全根域名，要避免写成重复主机名。

字段易错点
TypeCNAME 和 TXT 不能混
Host子域名是否自动补全
Value末尾点、空格、换行
TTL生效需要时间
旧记录冲突会导致验证失败

Google Workspace 关于 SPF、DKIM 的文档可以帮助理解邮件认证：SPF 用来声明哪些服务器可代表域名发信，DKIM 用签名证明邮件未被中途改动。Newsletter 创作者不用变成邮件工程师，但要知道这些记录不是装饰。

如果域名以前接过企业邮箱、营销工具或另一个 Newsletter 平台，要先盘点旧记录。最容易出错的是多个 SPF TXT 并存、旧 CNAME 没删、验证记录写到错误子域名。别急着清空，先截图备份，再按一个平台一个用途整理。

第三步：测试送达怎么做？

先发一封短测试，不要直接发付费长文。测试时看四件事：能否访问自定义域名、邮件是否收到、发件人显示是否符合预期、是否进入垃圾箱或促销分类。

记录样本邮箱、收到时间、所在分类、是否有安全警告。若 Gmail 正常、企业邮箱异常，就不要立刻怪 Substack；企业网关可能有自己的过滤规则。若多个邮箱都异常，再回头查 DNS 和平台提示。

第四步：发刊前怎么复核？

发刊前一天做最后检查：域名能打开，后台没有验证错误，上一封测试邮件能搜索到，订阅页和付款页都能访问。不要在正式发刊当天改标题、域名、发件身份和付款设置。一次只改一个变量，出了问题才知道是谁。

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

域名、付款、邮件认证都属于高风险后台操作。我建议固定主账号、主设备和操作记录：谁改了哪条 DNS、何时保存、何时验证通过。远程团队不要让每个人都登录域名商后台。

如果主理人经常出差，处理域名和发刊设置时可以使用 AdSense / YPP 友好的稳定网络 同类的固定工作环境思路：固定设备、固定入口、固定负责人。它不提升邮件送达率，但能减少后台安全提醒和误操作。

FAQ

可以同时接 Cloudflare 吗？ 可以，但要知道 DNS 最终由谁托管。很多错误来自域名商和 Cloudflare 两边都改，结果生效的不是你以为的那一份。

DMARC 一定要立刻设严格吗？ 新手不要一上来设得太激进。先确认 SPF、DKIM 和发信流程稳定，再逐步收紧策略，避免误伤正常邮件。

读者收不到怎么办？ 先让读者搜 publication 名称和发件人，再查垃圾箱、促销分类和公司邮箱规则。大面积异常再回到 DNS 与平台支持路径。

相关阅读

来源与时间戳

最后核对：2026-05-21。主要参考 Substack 自定义域名与域名访问异常文档，以及 Google Workspace 的 SPF、DKIM 基础说明。