纯文字版教程展开阅读
域名和企业邮箱不是建站装饰。它们会影响用户信任、支付审核、广告审核、客服送达和后续邮件营销。
上一课留下的是选品验证评分表：主方向、备用方向、暂停线，以及下一笔验证要补的证据。它帮助你判断一个方向是否值得继续，不会替你拿到域名、DNS 权限或企业邮箱。
那份评分表没有证明域名已接通、邮件能收发、发信身份通过认证，或 Shopify、支付、订单已经可以放行。它只把需求、竞争、毛利、履约和表达的商业证据写清楚，不等于基础设施完成。
只有当地址、收信、正式发信或恢复路径成了当前最早的基础设施阻塞，才进入本课。要留下的是DNS 与企业邮箱认证清单，不是“域名买好了”或“可以开店”的结论。
先把一次购买和一封退款咨询读通
先别急着看记录表。假设顾客从广告来到 brand.com，完成下单后发现尺寸不合适，于是写信给 support@ 申请退款。这里的“申请退款”是顾客发给商家的客服邮件。这一次购买和这封邮件，会依次穿过访问、收信、发信和身份一致性四层。
- 先让人到对地方。顾客打开根域名或 www 时，都应落到同一个 Shopify 主域，并看到正常 HTTPS。网站能打开，是后面所有检查的前提，但它本身还不能证明邮箱和品牌身份已经准备好。
- 再确保顾客能找到你。MX 是决定发给 support@ 的邮件送往哪个邮箱服务的 DNS 记录。域名能打开，不代表退款咨询、平台通知或支付验证邮件已经真的送到团队手里。
- 然后让回复真的来自你。当团队用品牌域回复退款申请或发送订单通知时，SPF 说明哪些系统可以代表该域发信，DKIM 则为邮件加上可验证的签名。两者没有过关，邮件可能发得出，却不容易被收件箱信任。
- 最后把身份说成同一件事。政策页、客服邮箱、支付账户和网站域名都要能解释为同一个商家。顾客需要知道该向谁求助，审核系统也会从这些公开信息里判断店铺是否自洽。
本课先从“访问”这层读起，是因为店铺地址和 HTTPS 没有确认时，其余测试没有可靠起点；这不是要你现在改 A 记录，也不是暗示你该优先选择某个服务商。
后文会用政策页、MX、Cloudflare Email Routing 和 DMARC 分别说明身份冲突、收信路径、只收不发的边界，以及认证失败邮件该如何处理的风险。Cloudflare Email Routing 不是默认推荐的完整邮箱方案；DMARC 也不是看见就照抄策略。把正文和表格读完，就能完成这条判断链；需要对照自己当前缺口时，再回看相应的记录或服务商页面。
四层里任何一层有证据，只能说明这一层暂时能对上：网站能打开，仍不代表退款咨询会送达；MX 正确，也不表示品牌邮件已经受信任。先把每一层当作局部验收，而不是把其中一项通过当成整条链路完成。
接下来先核对身份一致性，再落到具体 DNS 记录。顾客、支付审核和客服邮件看到的商家，应当能用同一套名称、域名和联系方式解释；随后再逐条确认哪项记录负责访问、收信、发信或第三方验证。
先把域名和邮箱验收到信任与送达
很多新店买了域名就算完成，结果企业邮箱没认证、DNS 记录混乱、客服地址不统一，后面支付、广告和邮件都容易出问题。
本课把域名邮箱拆成访问、品牌一致性、邮箱认证和账户归属四件事。能访问只是第一步，能稳定送达和被审核接受才算完成。
本课判断口径
- DNS：把域名指向网站、邮箱和验证服务的一组记录。
- 邮箱认证：SPF、DKIM、DMARC 等帮助收件方判断邮件是否可信。
- 品牌一致性：域名、邮箱、政策页、支付账户和客服入口表达同一个身份。
本课产出：DNS 与企业邮箱认证清单。读完后，用这个产出来判断本课是否真正完成。
下一步怎么接：域名邮箱要进入 Shopify 和支付验收
域名和邮箱不是品牌装饰。DNS、SPF/DKIM/DMARC、support@ 和续费负责人会直接影响收款、通知邮件、客服和找回账号。
- Shopify 路线：Shopify 初始化，把域名、通知邮箱和后台权限接到店铺基础设置。
- 支付路线：支付网关设置，确认收款审核里的邮箱、主体和网站信息一致。
今天先验收访问、发信和账户归属
域名邮箱这课不要停在买好域名。真正要交付的是一套别人接手也能恢复的基础设施：谁持有域名、谁能改 DNS、谁负责企业邮箱、认证记录在哪里查。
| 任务 | 验收证据 | 常见返工原因 |
|---|---|---|
| 域名访问 | 主域、www、HTTPS、Shopify 主域状态记录 | A/CNAME 指错或主域没有统一 |
| 企业邮箱 | MX、收发测试、客服别名、恢复邮箱 | 只做转发，不能稳定发信 |
| 邮件认证 | SPF、DKIM、DMARC 的 TXT 记录和值 | 多个 SPF 混写或 DKIM 没启用 |
完成标准
你能用品牌邮箱发一封测试邮件，用户能打开正确域名，团队能找到 DNS 记录和恢复路径。做不到这三点，不要急着接支付和邮件营销。
DNS 证据表：每次改记录都要留下可回滚信息
DNS 不是把后台给你的值复制进去就结束。真正能交接的记录，要写清楚记录名、类型、值、TTL、负责人、测试结果和回滚旧值。 否则一出问题，团队只知道“好像改过”，但不知道该恢复哪一条。
| 证据模块 | 要记录的字段 | 它证明什么 | 会卡住哪里 | 保存位置 |
|---|---|---|---|---|
| 域名所有权与权限 | 注册商、DNS 托管、能改 DNS 的账号、2FA、域名锁、续费日 | 域名没有卡在单个人或单个服务商手里 | 域名转移、续费、紧急回滚 | 域名资产表 |
| Shopify 访问记录 | 根域名 / www 记录类型和值、主域、HTTPS 状态、移动端和桌面端打开结果、旧 URL 跳转 | 用户和搜索引擎会到同一个店铺 | 广告落地页、支付审核、SEO canonical、政策页切换 | DNS 变更记录 + Shopify Domains 页面路径 |
| 收信路径 | MX 服务商、优先级和值、support@ / orders@ / hello@、外部测试发件人、时间、message ID | 企业邮箱真的能收信，不只是转发 | 客服入口、支付审核、订单通知 | 邮箱验收表 |
| 发信认证 | SPF 合并值、DKIM selector 和状态、DMARC 策略和报告邮箱、所有发信源 | 这个域名可以发出相对可信的邮件 | 订单通知、客服回复、邮件营销、DMARC 收紧 | 认证变更记录 + 测试邮件 header |
| 变更窗口与回滚 | TTL、变更时间、负责人、变更前值、变更后值、复查时间、回滚值 | DNS 改坏时可以恢复 | 上线窗口、客服工作时间、广告投放启动 | 发布记录 |
| 公开身份一致性 | Contact / Privacy / Refund / Terms URL、客服邮箱、支付邮箱、发信域名 | 公开页面、支付资料和发信身份是同一个品牌 | 审核、纠纷、客服承诺 | 政策页版本记录 |
最低完成线
不是“记录都加上了”就算完成，而是有一张表能说明改了什么、怎么测过、旧值是什么、没通过前哪些动作不能放行。
本课输出：DNS 和邮箱认证检查表
把域名、访问、收信、发信和防冒用拆成可验收的基础设施。
| 对象 | 检查项 | 通过标准 |
|---|---|---|
| 域名访问 | A/CNAME、HTTPS、主域和 www 跳转 | 目标市场设备都能打开正确站点 |
| 企业邮箱 | MX、收信、发信、别名和恢复邮箱 | 订单、客服和团队邮件都能正常收发 |
| 认证记录 | SPF、DKIM、DMARC、DNS 变更记录 | 发信不明显进垃圾箱，责任人知道恢复路径 |
先明确：域名和企业邮箱解决的是什么问题
用户第一次接触你的品牌时，域名和邮箱往往是最先暴露的身份信号。它们不只是看起来专业一点，而是会直接影响你的网站可信度、客服体验、广告与支付审核、以及后续发信的稳定性。
域名和邮箱的真实作用
- 建立品牌识别：用户更容易记住 `brand.com`，而不是平台生成的临时地址。
- 提升信任感：`[email protected]` 明显比个人邮箱更像真实商家。
- 支撑业务配置：Shopify 绑定独立域名、支付审核、广告账户、客服系统都依赖你有稳定的品牌域名。
- 影响发信质量：没有 SPF、DKIM、DMARC 的自定义域邮箱，后续订单通知、营销邮件和客服回复都更容易进垃圾箱。
最常见误区
- 只关注域名是否便宜：忽略 DNS 管理、隐私、续费、迁移体验和后续邮箱配置。
- 把邮箱转发当成正式企业邮箱：纯转发适合起步收件，不等于完整的企业发信方案。
- 先发邮件，后补认证：2026 年这样做很容易导致邮件送达率差、被标垃圾邮件或被拒收。
域名怎么选，什么标准更适合 2026
好的域名不一定必须非常短，但一定要清晰、稳定、可读、便于国际用户理解。过去那种偷偷塞关键词有利 SEO的思路，今天已经不是优先级最高的事情了。
优先品牌可记忆性
先考虑是否容易记住、容易拼写、容易口头传播，再考虑是不是带关键词。
拼写要简单
避免数字、连字符、容易误读的缩写、中文拼音混搭和需要反复解释的命名。
优先 `.com`
如果你的目标是跨境品牌化，`.com` 仍然是默认优先级最高的后缀。
查商标和社媒
不仅要查域名是否可注册，也要看商标、Instagram、TikTok、X 和 Amazon/Shopify 上是否已有强占用。
更实用的起名规则
- 如果你做品牌，优先选品牌词 + 通用感强的名字，而不是强行做品类词堆叠。
- 如果你是小团队试水，宁可先选一个稳定可用的好域名，也不要为了等更完美的名字拖慢上线。
- 关键词可以有，但不要把SEO 友好建立在牺牲品牌感和记忆成本上。
域名注册商怎么选
新手常问哪家最便宜，但更重要的是：DNS 管理是否稳定、价格是否透明、隐私保护是否默认、后续迁移麻不麻烦、和你要用的邮箱或 Shopify 连接是否顺手。
Cloudflare 官方文档强调 Registrar 以 at-cost / no-markup 方式提供注册服务。
缺点是需要域名使用 Cloudflare DNS。
适合先买域名再逐步迁移 DNS 或邮箱方案的人。
但很多人会额外留意续费价和附加销售项，不建议只看首年低价。
但如果后续主要围绕 Cloudflare、Shopify 和海外邮箱生态，最好提前考虑 DNS 迁移与协同成本。
选注册商时看这几个点
- 首年价和续费价是否都透明。
- DNS 管理台是否足够清晰，能方便添加 A、CNAME、MX、TXT 记录。
- 是否支持二步验证、域名锁定和隐私保护。
- 后续接入 Shopify、邮箱和 DNS 托管是否顺畅。
先确认记录到底应该改在哪里
注册商、DNS 托管和 Shopify Domains 页面不是同一个概念。注册商主要管续费、域名锁、2FA 和 Nameserver；DNS 托管才是改 A、CNAME、MX、TXT 的地方；Shopify Domains 页面负责告诉你主域、www 和 TLS 是否已经接上。路径不清楚时，最容易出现的问题是值复制对了，但改在旧平台里，Shopify 和邮箱服务根本读不到。
| 场景 | 先看哪里 | 为什么要这样分 | 暂停信号 |
|---|---|---|---|
| Shopify 内购买或连接的域名 | Shopify Admin 里的 Settings > Domains，确认主域、www、TLS 状态和 Shopify 给出的 A / CNAME 目标值。 | 先确认店铺访问层，再去当前 DNS 后台改记录。 | Shopify 显示未验证时，不凭记忆猜 IP 或 CNAME。 |
| Cloudflare Registrar / DNS | Cloudflare Dashboard 对应站点的 DNS > Records。 | Nameserver 已经切到 Cloudflare 时，真正读取的是 Cloudflare DNS。 | 如果还去旧注册商里改 DNS 记录，通常不会生效。 |
| Namecheap / GoDaddy 等注册商加外部 DNS | 注册商后台看续费、域名锁、2FA 和 Nameserver，记录修改去当前 DNS 托管后台。 | 域名购买处和 DNS 托管处可能不是同一个平台。 | 把注册商当成 DNS 托管，改完后 Shopify 和邮箱仍然读不到。 |
注册完域名后，DNS 这几类记录一定要认识
很多新手是被 DNS 配置卡住的。其实你不用成为 DNS 专家，但至少要理解常见记录各自负责什么，否则之后连 Shopify、邮箱和验证都很难配顺。
配置 DNS 时最容易犯的错
- 重复加 MX 记录：不同邮箱服务的 MX 记录混在一起，导致收件混乱。
- TXT 记录格式写错：SPF、DKIM、DMARC 少一个字符都可能认证失败。
- 没考虑 TTL 和传播时间：改了记录后立刻测试失败，不一定是配置错，也可能只是 DNS 还没传播完成。
域名怎么连接到 Shopify
如果你用 Shopify 建站，独立域名接入是必做项。Shopify 官方帮助文档支持你连接第三方域名，也可以从 Shopify 直接购买域名，但无论哪种方式，核心都是把网站访问权正确指向 Shopify。
推荐连接顺序
连接 Shopify 时的实操建议
- 网站 DNS 和邮箱 DNS 尽量集中、有文档记录，不要让团队里谁都顺手改一下。
- 正式切主域名前，先确认旧链接、广告落地页和像素配置不会被破坏。
- 上线后检查 HTTPS、主域跳转和收录规范，不要让多个版本同时可访问。
企业邮箱方案怎么选
企业邮箱不是只有Google Workspace 或 Microsoft 365两个答案。你真正要先判断的是：你现在需要的是完整邮箱套件，还是先要一个稳定的品牌收件入口。
把 Email Routing 理解成入站收信和转发；正式从品牌域发信，需要另接 Cloudflare Email Service / Email Sending、企业邮箱或其他发信方案。
价格变化快，先看下方官方边界；这里真正要判断的是 Gmail 生态、协作方式和发信认证是否适合你。
不要只看套餐便宜不便宜，先看团队是不是已经在 Outlook、Teams、Excel 里协作。
但如果核心业务围绕 Shopify、海外用户和国际团队，仍要评估长期兼容性与海外送达表现。
怎么选更合理
- 如果你只是想先收品牌邮件：可以先用 Cloudflare Email Routing 做转发。
- 如果你要正式对外发邮件、多人协作、管理文档：更适合直接上 Workspace 或 Microsoft 365。
- 如果你未来要发营销邮件或大量订单通知：从一开始就应该考虑域名认证和送达率，不要只看价格。
官方时效边界：价格、TLS 和发信认证先按当前页面核验
- Google Workspace：官方 pricing 页面当前显示 Business Starter 年付约 $7 USD/用户/月，并可能有结账时限时优惠；购买前看结账页、地区税费和续费价格。
- Microsoft 365 Business Basic：官方 pricing 页面当前显示年付约 $6 USD/用户/月；实际可购买性、税费和地区价格以结账页为准。
- Cloudflare Email Routing：把它当作入站收信和转发，不要当成完整企业邮箱；正式出站发信另接 Cloudflare Email Service / Email Sending、Google Workspace、Microsoft 365 或其他发信方案。
- Shopify TLS / SSL：第三方域名 A / CNAME 指向 Shopify 后，TLS 证书签发最多可能需要 48 小时；HTTPS、主域和 www 稳定前，不放行广告、支付审核或大规模邮件。
- Google sender guidelines：所有发件人至少用 SPF 或 DKIM；批量发信还要 SPF、DKIM、DMARC 和 From 域对齐。不要等进垃圾箱后再补。
Cloudflare Email Routing 适合什么，不适合什么
这是很适合新手起步的收信方案，但前提是你知道它的边界。很多人误以为它能完全替代企业邮箱服务，这就会在后面发信时踩坑。
Cloudflare Email Routing 的关键边界
- 适合收件转发：比如把 `[email protected]` 转发到你现有的 Gmail 或 Outlook 邮箱。
- 支持自定义地址和 catch-all：Cloudflare 官方文档支持创建自定义地址，也支持 catch-all 和 subaddressing。
- 每个规则默认只转发到一个目的地：Cloudflare 文档明确写了单个地址的当前转发实现只支持一个 destination。
- 出站发信要单独规划：Cloudflare 当前 Email Service 文档把入站 Email Routing 和出站 Email Sending 分开说明，不要把 Routing 单独当成完整企业邮箱平台。
所以你该怎么理解它
- 它适合先有品牌邮箱入口，不适合直接当完整企业邮箱平台。
- 如果你回复客户邮件，直接从转发后的 Gmail 回信，发件人通常仍会显示为目标邮箱，而不是你的品牌地址。
- 如果你要稳定从品牌域发信，应该上 Workspace、Microsoft 365，或明确接入单独的出站发信服务。
DNS 变更继续/暂停判断：判断域名和邮箱能不能继续上线动作
最危险的不是填写 DNS 记录，而是配置看起来差不多就继续开广告、提交支付审核、改政策页或发营销邮件。每次主域、MX、SPF/DKIM、DMARC 变更前，都先用这张表判断能不能继续。
| 压力场景 | 不安全动作 | 继续条件 | 第一证据 | 暂停线 |
|---|---|---|---|---|
| Shopify 主域切换 | 只因首页能打开就继续开广告、接支付审核和更新客服链接。 | Shopify 显示 connected、主域已选择、根域和 www 都走 HTTPS、旧链接落到同一版本后再继续。 | Shopify Domains 页面路径、根域 / www 移动端打开结果、HTTPS 状态、旧链接抽样。 | 未通过前不放广告、不提交支付审核、不切主域。 |
| 企业邮箱 MX 切换 | 客服高峰期反复改 MX，或只测一封自己的邮件。 | 唯一收信方案确定、旧 MX 清理、support@ / orders@ / hello@ 外部测试通过后再继续。 | MX 列表、角色邮箱后台路径、三封测试邮件、Contact 页 URL / 版本记录。 | 未通过前不迁移客服入口、不发上线通知。 |
| SPF / DKIM 发信认证 | 每个工具让你加什么就加什么，然后群发测试。 | SPF 合并成一条，DKIM 逐个发信源开启，再进入小流量测试。 | 合并后的 SPF、DKIM 通过状态、测试邮件 header 或认证检查结果。 | SPF/DKIM 未通过前不群发，不收紧 DMARC。 |
| DMARC 策略收紧 | 直接改成 reject，觉得最安全。 | 先用 p=none 观察，确认合法发信源通过后，再逐步收紧。 | DMARC 记录、报告邮箱、合法发信源清单、最近测试认证结果。 | 观察完成前不直接 reject，不批量切换发信域。 |
正式企业邮箱上线时，SPF / DKIM / DMARC 一定要配
这是很多独立站团队真正忽略但影响极大的地方。今天你用自定义域名发邮件，如果没有认证，很多服务商会把你当作低信誉发件方处理。
Google Workspace 官方帮助也会在没配 SPF 时给出明确风险提示。
Google 官方文档建议在 SPF 和 DKIM 已稳定认证至少 48 小时后，再逐步开启 DMARC。
更稳妥的上线顺序
- 先验证域名所有权。
- 再加对应邮箱服务的 MX 记录。
- 再完成 SPF 和 DKIM。
- 观察认证稳定后，再上线 DMARC，并从 `p=none` 这类较保守策略开始。
域名邮箱认证验收清单：SPF/DKIM/DMARC 要能被验证
SPF、DKIM、DMARC 不是填完 DNS 就结束。真正的验收，是你能说清楚谁在代表品牌域发信、在哪里查验证状态、什么证据算通过，以及看到什么信号必须先暂停。否则 support@ 能收信，也不代表订单通知、客服回复和邮件营销都能稳定送达。
| 验收项 | 先说人话 | 去哪里查 | 通过证据 | 暂停信号 |
|---|---|---|---|---|
| SPF 发信来源表 | 告诉收件方哪些服务器可以代表这个域名发邮件，不是提升打开率的按钮。 | DNS TXT、企业邮箱后台、Shopify 订单通知、客服工具和邮件营销工具的发信域页面。 | 只保留一条合并后的 SPF TXT，当前真实发信源都在同一条记录里，并通过服务商验证。 | DNS 里有多条 v=spf1，旧服务商还留在记录里，或者新工具要求添加 SPF 但无人合并。 |
| DKIM 签名状态 | 像邮件的签名章，帮助收件方确认邮件来自被允许的系统，途中没有被篡改。 | Google Workspace、Microsoft 365、客服工具、邮件营销工具的 DKIM / Sending domain 页面，以及 DNS TXT 或 CNAME。 | 每个正式发信工具都显示 DKIM 通过；测试邮件原文里能看到 DKIM=pass。 | 只有企业邮箱 DKIM 通过，客服或邮件营销工具还没开启；或者 selector 记录填错主机名。 |
| DMARC 观察策略 | 新站不要一上来就拦截，先用 p=none 观察哪些系统在代表品牌域发信。 | _dmarc TXT、DMARC 报告邮箱、发信工具认证页，以及测试邮件里的 SPF/DKIM alignment。 | 存在 _dmarc TXT，策略从 p=none 开始，报告邮箱可用，合法发信源清单能解释订单通知、客服和营销邮件。 | SPF/DKIM 还没通过就想改 reject；From 域和认证域不一致；团队没人看报告邮箱。 |
| 角色邮箱收发测试 | support@ 能收到转发不等于企业邮箱完成，还要能从品牌域正式回复。 | support@、orders@、hello@ 收件箱，客服工具发信设置，Gmail 原文 / 邮件 header，政策页联系邮箱。 | 三类角色邮箱至少完成一次收信和回复测试；政策页、PayPal/支付邮箱、客服发件域保持一致。 | 只能转发到私人邮箱，不能从 support@ 正式回复；政策页邮箱和支付/客服邮箱互相不一致。 |
复制笔记总结要写什么
不要只写“SPF/DKIM/DMARC 已配置”。要写：SPF 合并后的完整值、每个 DKIM selector、DMARC 策略和报告邮箱、最近一次测试邮件、发信工具后台状态、下一次复查日期和负责人。
Google Workspace 和 Microsoft 365 怎么接自定义域
两者都支持自定义域邮箱，只是管理逻辑略有不同。对大多数独立站卖家来说，重点不是谁更高级，而是谁更适合你现有协作方式。
通用接入流程
自定义域邮箱是核心能力之一，Business Starter 已足够多数小团队起步。
Microsoft Learn 文档说明支持通过 Domain Connect 自动配置，Cloudflare 也在支持列表中。
上线前检查清单
到这一步，你的目标不是看起来已经有域名和邮箱，而是让网站访问、品牌邮箱收件、正式发信和 Shopify 使用都已经进入稳定状态。
必须确认的事项
- 域名已经买好，并开启二步验证、域名锁和隐私保护。
- 根域名与 `www` 版本的指向逻辑清晰，没有多版本混乱。
- Shopify 连接后的主域名已确定，HTTPS 正常。
- 企业邮箱已能正常收信，正式角色邮箱已创建。
- SPF、DKIM、DMARC 已按计划配置，不是空白状态。
- 团队内部知道谁负责 DNS，避免多人无记录修改。
行动建议
- 起步阶段最稳妥的组合通常是：稳定注册商 + Cloudflare DNS + Shopify 独立域名 + 正式企业邮箱方案。
- 如果预算有限，可以先用 Cloudflare Email Routing 收件，再逐步切到 Workspace 或 Microsoft 365 发信。
- 不要把 DNS 当成技术同学以后再处理的问题，它是你的品牌底座之一。
域名邮箱要按访问、收信、发信和防冒用验收
ICANN 把域名注册视为通过注册商取得名称使用权的流程；Google sender guidelines 要求发件域配置 SPF 或 DKIM，并建议设置 SPF、DKIM、DMARC。Virginia Tech 在 Revisiting Email Spoofing Attacks 中研究了伪造邮件如何进入用户收件箱，这说明品牌域发信不能只看能不能发出去。
四层验收
- 访问：根域名、www、HTTPS、主域跳转都正常。
- 收信：support@、orders@ 等角色邮箱能稳定收件。
- 发信：订单通知、客服回复和营销工具都通过同一域名认证。
- 防冒用：SPF、DKIM、DMARC 有记录、有测试、有变更日志。
DNS 记录核对器：从买域名到 SPF/DKIM/DMARC 验证
第一家 Shopify 店不需要把 DNS 学成网络工程，但必须知道自己改了哪些记录、每条记录影响什么、什么时候可以放行。最小路径不是域名买完就结束，而是主域能打开、www 指向一致、support@ 能收信、SPF 只有一条合并记录、DKIM 通过并用 DMARC p=none 先观察。
| 核对项 | 要改的记录 | 具体动作 | 要留证据 | 暂停线 |
|---|---|---|---|---|
| Shopify 主域能打开 | 根域名 A / AAAA 或 Shopify 要求的记录 | 在 Shopify Domains 里连接第三方域名，按后台给出的值填写根域名记录，并统一主域版本。 | Shopify Domains 页面路径、根域名打开结果、HTTPS 状态记录、旧链接跳转结果。 | 主域和 HTTPS 未稳定前，不开广告、不提交支付审核、不把政策页全部换成新域名。 |
| www 指向同一主域 | www CNAME | 按 Shopify 或 DNS 托管后台给出的目标值设置 www，不让根域名和 www 打开两个版本。 | www 记录值、www 打开结果、主域跳转结果、移动端打开结果。 | www 和根域名不一致时，不更新广告落地页和品牌外链。 |
| support@ 能稳定收信 | MX 记录 + 角色邮箱 | 先确定唯一收信方案，再填 MX；创建 support@、orders@、hello@ 等角色邮箱，并做真实收信测试。 | MX 记录值、角色邮箱后台路径、三封测试邮件、政策页联系邮箱 URL / 版本记录。 | 收信未验收前，不把 support@ 写进 Contact、Refund、Shipping 或支付资料。 |
| SPF 只有一条合并记录 | TXT：一条 v=spf1 | 把邮箱、Shopify/订单通知、客服工具和邮件工具的发信源合并进同一条 SPF，不要各加一条。 | 合并前后 SPF 字符串、涉及服务商清单、发信工具验证结果。 | SPF 多条冲突时，不发营销邮件，不扩大订单通知或客服自动化。 |
| DKIM 通过，DMARC 从 p=none 观察 | DKIM TXT/CNAME + _dmarc TXT | 逐个发信工具开启 DKIM，再新增 DMARC p=none 和报告邮箱；先观察合法发信源，再考虑收紧策略。 | DKIM 通过状态、DMARC 记录、报告邮箱、测试邮件 header 或认证检查结果。 | SPF/DKIM 未通过或合法发信源不清楚时，不直接把 DMARC 改成 quarantine / reject。 |
我的建议是先把这五项做成复制笔记总结的一部分。后面接 Shopify、支付、政策页和邮件工具时，不要重新猜 DNS 到底有没有做好。
DNS 字段证据抽屉：域名能打开，不代表邮箱能进收件箱
很多新店的真实卡点不是“域名打不开”，而是主域已经能访问，但 support@ 发出的企业邮箱还是进垃圾箱，平台验证邮件也偶尔收不到。这就是典型的企业邮箱进垃圾箱问题。这里不要把 DNS 当成一堆缩写背下来，而是按字段问四个问题：在哪里查、谁会读取、错了会坏什么、要带什么证据进 Store Launch Readiness Scanner。
| 字段 | 在哪里查 | 谁会读取 | 错了会怎样 | 要留下的证据 |
|---|---|---|---|---|
| A / AAAA | DNS 后台的根域名记录、Shopify Domains、浏览器打开结果和 HTTPS 状态。 | 买家浏览器、Shopify、搜索引擎、支付和广告审核。 | 主域打不开、打开旧站、HTTPS 长时间未就绪，后续审核资料都显得不可信。 | Shopify Domains 截图、主域打开结果、HTTPS 状态、旧链接跳转结果。 |
| CNAME | www CNAME、Shopify 目标值、广告或邮件工具给出的验证主机名。 | 浏览器、Shopify 域名验证、广告域名验证、邮件工具验证。 | www 和主域分裂，工具验证失败，营销链接打开异常。 | CNAME 值、www 打开结果、主域跳转结果、工具验证页状态。 |
| MX | DNS MX 记录、企业邮箱或转发服务后台、support@ / orders@ / hello@ 收信测试。 | 客户邮件、平台通知、支付服务、客服工单和账号恢复邮件。 | 客户联系不到你，平台验证邮件收不到，客服看起来像无人响应。 | MX 列表、角色邮箱后台、三封测试邮件、政策页联系邮箱截图。 |
| SPF TXT | DNS 里的 v=spf1、企业邮箱、订单通知、客服工具和邮件营销工具的发信域验证页。 | Gmail、Yahoo、Outlook 等收件方，以及邮件工具认证检查。 | support@ 能发出但更容易进垃圾箱；多条 SPF 冲突时认证可能直接失败。 | 合并前后 SPF 字符串、真实发信源清单、工具验证通过截图。 |
| DKIM | Workspace / Microsoft 365 / 客服工具 / 邮件营销工具的 DKIM 页面，以及 DNS selector 记录。 | 收件方、邮件营销平台、客服系统和 DMARC 对齐判断。 | 客服回复或营销邮件显示未认证，DMARC 后续无法安全收紧。 | 每个工具的 DKIM pass 状态、selector、DNS 记录和最近测试邮件 header。 |
| DMARC | _dmarc TXT、DMARC 报告邮箱、测试邮件里的 SPF/DKIM alignment、各发信工具认证状态。 | Gmail、Yahoo、Outlook 等收件方，以及品牌防冒用和送达率排查。 | 合法订单通知、客服回复或营销邮件可能被隔离；无人看报告时也不知道谁在冒用。 | _dmarc 记录、报告邮箱、合法发信源清单、最近一次测试认证结果。 |
带进 Scanner 的不是一句“DNS 已完成”，而是主域 URL、HTTPS 状态、root 与 www 是否一致、角色邮箱测试时间、SPF 完整值、DKIM 通过的发信工具、DMARC 策略和报告邮箱。这样后面做上线检查时，才知道问题卡在访问、收信、发信还是防冒用。
一个很常见的真实例子是：网站已经能打开，support@ 也能从邮箱后台发信，但 Gmail 测试邮件进了垃圾箱。这里不要先改文案。先查发信工具里的 DKIM 是否 pass，再确认 SPF 只有一条合并记录，最后查 _dmarc TXT 是否存在并且有报告邮箱。缺 DMARC、DKIM 未通过或 SPF 没合并，都可能让客服回复和订单相关邮件看起来不可信。
修复时先补 DKIM 和单条 SPF，再用 p=none 增加 DMARC 观察策略，发一封外部测试邮件，保存 Gmail 原文里的 authentication-results。证据齐了之后，再继续客服入口、邮件活动或支付审核相关动作。
复制笔记总结：域名邮箱上线要能被下一位负责人接住
如果网站域名、客服邮箱、PayPal 邮箱和政策页联系人互相不一致，用户和审核系统都会更难信任这个店。
这份笔记不是为了做文档形式，而是为了避免以后某个人离职、手机换号、邮箱收不到、DNS 被误改时没人知道怎么恢复。域名邮箱这类基础设施，最怕只存在一个人的脑子里。
可复制模板
- 当前压力：正在切 Shopify 主域、切 MX、补 SPF/DKIM，还是准备收紧 DMARC。
- 第一证据：Shopify Domains 页面、DNS 记录、角色邮箱测试、测试邮件 header、认证检查结果。
- 本周动作：只放行一个主动作，例如统一主域、清理旧 MX、合并 SPF 或开启 DKIM。
- 暂停动作：证据不足时，不开广告、不提交支付审核、不群发邮件、不把 DMARC 直接改成 reject。
- 复盘窗口：记录修改时间、TTL、复查时间、负责人和失败后的恢复旧值。
- 下一步路线：交给 Shopify、支付配置、政策页和邮件课程前，带上域名注册商、DNS 记录、SPF/DKIM/DMARC 状态、邮箱负责人和续费提醒。
如果你只能说"域名已经买了"，但说不清谁能改 DNS、support@ 发到哪里、SPF/DKIM/DMARC 是否通过、失败后怎么恢复，这一课就还没有完成。