域名邮箱不是装饰，是访问、收发信和信任验收
买好域名只是开始。真正要完成的是：用户能打开正确网站，客户邮件能收到，品牌邮件能正式发出，SPF / DKIM / DMARC 能解释，账号负责人和恢复路径能被下一位负责人接住。
上一课留下的是选品验证评分表：主方向、备用方向、暂停线，以及下一笔验证要补的证据。它帮助你判断一个方向是否值得继续，不会替你拿到域名、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 也不是看见就照抄策略。你可以直接读完正文和表格，不需要逐个点击；只有要对照自己当前缺口时，再打开对应的互动项。
不是"域名能打开"就完成，而是四层都能验收
独立站的域名邮箱不是单点配置，它会同时影响用户信任、支付审核、广告验证、客服送达和后续邮件营销。你要验收的是链路，不是截图。
访问
用目标市场网络打开主域、www 和旧链接，最终都落到你认定的主域版本。
A / CNAME 指错、HTTPS 未就绪、主域没统一，后面广告、收录和支付资料都会跟着乱。
当前验收层显示通过，只说明这一层的证据能对上。网站能打开，仍不代表退款咨询会送达；MX 正确，也不代表品牌邮件已经获得信任。把这个结果当成局部验收，而不是整条链路的完成。
下一步不要随机再改一条 DNS 记录。先把当前的通过或返工点带到身份一致性里，核对顾客、支付审核和客服邮件看到的商家，是否能用同一套名称、域名和联系方式解释。
用户和审核系统看到的，应该是同一个商家
如果网站域名、客服邮箱、PayPal 邮箱和政策页联系人互相不一致，用户和审核系统都会更难信任这个店。
政策页
Shipping、Return、Privacy、Contact 页面里的公司名、域名和联系邮箱必须讲同一个故事。
身份信息对齐，不等于 DNS 已经配置正确。它只说明你知道每个公开触点应该说成谁。接下来要把这条身份线落到具体记录上，确认哪一条负责网站访问、收信、发信或第三方验证。
阅读下面的记录表时，不必背术语。每看一条，只回答三件事：它服务哪一层、你在哪里验证它，以及失败时会影响哪一段顾客或审核流程。
2026 年选域名：先让人记住，再谈关键词
好域名不一定要极短。对跨境品牌，更重要的是清楚、易读、容易说出口，并且不同国家的顾客都能理解。关键词堆砌不再是第一优先级，品牌记忆比塞满关键词更重要。
避免数字混排、连字符、含义不清的缩写；中文品牌也不要混用难读的拼音。能被顾客记住，比看起来像关键词更有用。
对大多数跨境品牌，.com 仍然是默认选择。它不是资格证明，但能减少顾客对陌生后缀的解释成本。
下单前核对商标、社交账号，以及主要电商和广告平台上的名称可用性。域名可注册不等于品牌没有冲突。
稳定、能使用的域名通常比为了完美关键词等待几周更好。只有在不损害记忆度、不把品牌做得过于普通时，才加入关键词。
DNS 不用背概念，但要知道每条记录负责什么
A、CNAME、MX、TXT 是这篇的最低识别能力。你不用成为 DNS 专家，但不能不知道改哪条会影响网站、收信、发信和验证。
决定邮件应该送到哪个服务，企业邮箱能不能收信主要看它。
Cloudflare Email Routing、Google Workspace、Microsoft 365 或国内企业邮箱都会要求自己的 MX 记录。
同一域名通常不要把多个邮箱服务的 MX 混在一起，否则收信路径会不稳定。
先确认记录到底应该改在哪里
新手最容易把注册商、DNS 托管和 Shopify 域名页混在一起。注册商管续费和 Nameserver，DNS 托管管 A/CNAME/MX/TXT，Shopify 域名页管店铺连接和 TLS 状态。路径不清楚时，改对值也可能改错地方。
Shopify 内购买或连接的域名
Shopify Admin 里看 Settings > Domains，确认主域、www、TLS 状态和 Shopify 给出的 A / CNAME 目标值。
什么时候用：适合先确认店铺访问层是否正常，再去 DNS 后台改记录。
暂停信号：Shopify 页面显示未验证时，不要凭记忆猜 IP 或 CNAME，先回到它给出的目标值。
Cloudflare Registrar / DNS
Cloudflare Dashboard 里进入对应站点，再到 DNS > Records 修改 A、CNAME、MX、TXT；注册商、DNS 托管和 Nameserver 要分开记录。
什么时候用：适合已经把 Nameserver 切到 Cloudflare，或者域名本身就在 Cloudflare Registrar。
暂停信号：如果 Nameserver 已经切到 Cloudflare，去旧注册商里改 DNS 记录通常不会生效。
Namecheap / GoDaddy 等注册商加外部 DNS
注册商后台主要看续费、域名锁、2FA 和 Nameserver；真正的记录修改要去当前 DNS 托管后台。
什么时候用：适合域名购买处和 DNS 托管处不是同一个平台的团队。
暂停信号：最常见误判是把注册商当成 DNS 托管，结果改了半天记录，Shopify 和邮箱仍然读不到。
注册商对比：把续费和长期可控性一起看
不按首年促销给结论。请逐家记录续费价、DNS 面板是否能清楚控制记录，以及 2FA、域名锁和隐私保护是否符合你的要求。
Cloudflare Registrar
Cloudflare Registrar 的注册定位是 at-cost / no-markup；域名需要使用 Cloudflare DNS。把这个定位和实际续费价、DNS 面板可控性、2FA、域名锁、隐私保护一起核对。
Namecheap
Namecheap 是常见的起步选项，购买流程直观；仍按同一套标准核对续费价、DNS 面板控制和账户安全项。
GoDaddy
GoDaddy 是老牌注册商，生态和引导较多；比较时不要只看首年折扣，要看续费价、DNS 控制和附加销售项带来的操作成本。
阿里云 / 腾讯云等国内方案
阿里云、腾讯云等国内方案通常更适合中文操作和本地采购；如果后续使用 Shopify、Cloudflare 和海外邮箱，再比较 DNS 迁移与协同可控性、2FA、域名锁、隐私保护和续费。
- 续费价：不要只看首年优惠，要记录实际续费周期和价格。
- DNS 面板可控性：确认 A、CNAME、MX、TXT 是否能清楚、稳定地管理。
- 账户安全：核对 2FA、域名锁和隐私保护是否可用并符合你的要求。
从买域名到能收发邮件，按这 5 条记录验收
这不是让你背 DNS，而是给第一家 Shopify 店一条最小路径：先让主域和 www 正常，再让 support@ 能收信，最后把 SPF、DKIM、DMARC 做成能被邮箱和邮件工具认可的发信链。
Shopify 主域能打开
操作在 Shopify Domains 里连接第三方域名，按后台给出的值填写根域名记录，然后把主域统一成一个版本。
证据Shopify Domains 截图、根域名打开截图、HTTPS 正常截图、旧链接跳转结果。
暂停线主域和 HTTPS 未稳定前，不开广告、不提交支付审核、不把政策页全部换成新域名。
www 指向同一主域
操作按 Shopify 或 DNS 托管后台给出的目标值设置 www，不要让根域名和 www 分别打开两个版本。
证据www 记录截图、www 打开结果、主域跳转结果、移动端打开截图。
暂停线www 和根域名不一致时，不更新广告落地页和品牌外链。
support@ 能稳定收信
操作先确定唯一收信方案，再填 MX；创建 support@、orders@、hello@ 等角色邮箱，并做真实收信测试。
证据MX 记录截图、角色邮箱创建截图、三封测试邮件、政策页联系邮箱截图。
暂停线收信未验收前，不把 support@ 写进 Contact、Refund、Shipping 或支付资料。
SPF 只有一条合并记录
操作把邮箱、Shopify/订单通知、客服工具和邮件工具的发信源合并进同一条 SPF，不要各加一条。
证据合并前后 SPF 字符串、涉及服务商清单、发信工具验证截图。
暂停线SPF 多条冲突时，不发营销邮件，不扩大订单通知或客服自动化。
DKIM 通过，DMARC 从 p=none 观察
操作逐个发信工具开启 DKIM，再新增 DMARC p=none 和报告邮箱；先观察合法发信源，再考虑收紧策略。
证据DKIM 通过截图、DMARC 记录、报告邮箱、测试邮件 header 或认证检查结果。
暂停线SPF/DKIM 未通过或合法发信源不清楚时，不直接把 DMARC 改成 quarantine / reject。
勾选一条记录，只代表你能拿出这一条的验收证据。它不会替 MX、发信认证或恢复路径通关。下一步只把最早未通过的一条带到字段抽屉，确定去哪里查、留什么证据、没过时暂停哪个外部动作。
先分清最低上线配置和发信加固，再决定改哪一条记录
DNS 对新手难，不是因为记录名称多，而是访问、收信和发信认证会在同一次上线压力里混在一起。这个控制台不替换上面的五条验收，而是把下一次变更拆成两个能证明的层级：先让顾客和客服能到达，再让品牌邮件的身份逐步变得可验证。
上线最低配置
先定位实际 DNS 编辑处，保存当前来源和字段，再分别验收根域、www 与角色邮箱。
它不能证明：这不是批量发信授权，也不表示 DMARC 可以直接进入 quarantine 或 reject。
看懂 Host 和 Value，不把课堂示例当成生产配置
每张卡只解释字段长什么样、由谁提供和什么时候不能继续。实际值必须从你当前 Shopify、邮箱或邮件工具后台复制，不要从这篇课、旧截图或别人的域名照抄。
Shopify 的 www 字段示例
- Type
- CNAME
- Host / Name
- www
- Value
- shops.myshopify.com.
这是 Shopify 当前文档中的字段示例。只在你的 Shopify Domains 连接说明一致时使用，不把它复制到其他建站目标。
Shopify 域名排查说明DMARC 监控字段示例
- Type
- TXT
- Host / Name
- _dmarc
- Value
- v=DMARC1; p=none; rua=mailto:[email protected]
这是字段语法示例，不是可直接上线的值。报告地址必须由你控制，且在所有发信源和认证结果已复查前保持监控策略。
Google 推荐的 DMARC 推进方式SPF 合并记录的字段边界
- Type
- TXT
- Host / Name
- @
- Value
- One merged v=spf1 value for every current sender
先列出所有真实发信源，再按服务商当前说明合并为一条 SPF，并检查评估时的 DNS 查询数量。不要为每个工具各加一条 SPF。
RFC 7208 SPF 查询上限只勾选当前层级真正完成的关卡
当前层级还缺 3 项。缺任一项时，不把“看起来能用”升级为下一层授权。
写来源、预期和复查，不把记忆当作 DNS 配置
字段可以留空。它们的作用是让下一次复查知道值从哪里来、什么结果算通过、什么时候停止继续改。
改完后仍在等待，且还有一个发信源没有盘清时，先做什么？
先选真实症状，再把同一条路径带进下方排查台
你的选择会同步选中下方 DNS 排查台对应的案例。它只帮助排序下一步，不会替你修改域名、邮箱或发信工具。
保存、恢复、清除和 JSON 导出只在当前浏览器执行，不会把内容发送给 Ecomwith、Shopify、邮箱服务或 DNS 提供商。这是课堂记录，不是域名、邮件、合规或账户管理系统。不要填写账号、密码、恢复码、支付信息或客户数据。
域名能打开，不代表邮箱能进收件箱
很多新店的真实问题是：主域已经能访问，但 support@ 发出的邮件还是进垃圾箱，或者平台验证邮件收不到。按字段打开这个抽屉，先看它在哪里、谁会读取、错了会坏什么，再把证据带进 Store Launch Readiness Scanner。
A / AAAA：主域访问证据
一项企业邮件研究将邮件风格特征、有限的 LinkedIn 社交特征及其组合纳入监督式分类比较，再用多类分类器和交叉验证评估。对本课能借用的判断很有限：投递表现变化时，分别记录身份认证、实际发信行为和收件结果，再对照每一层证据，不要把变化直接归因给某一条设置。研究使用匿名企业邮件扫描样本和有限社交资料，只提供受约束的离线相关性比较，不能证明当前店铺的送达率、真实攻击者行为，也不能外推到其他行业或平台； 查看研究原文。
字段抽屉给的是排查范围，不是一次把所有 TXT 都改掉的指令。先对照当前字段留下最小证据；如果它影响网站访问、收信或发信之一，就暂停同一条外部动作，先复查这一层。
报错时先排查记录，不要靠猜反复修改
域名和邮箱配置最怕"改一下试试"。你需要先判断是传播等待、记录冲突、邮箱方案混用，还是发信认证没有对齐。
刚改完还没生效
Shopify 或邮箱后台仍显示未验证，但你确认 DNS 已经保存。
先看记录主机名和值是否完全一致，再看 TTL 和最近修改时间。
DNS 传播、缓存或证书签发还没完成，不一定是配置错误。
记录修改时间，等待一个合理窗口后再复查；不要在等待期间反复改值。
可接手证据：保存 DNS 后台截图、验证后台截图、修改时间和复查时间。
真正会做 DNS，是敢改、会记、能回滚
很多返工不是因为 DNS 难，而是因为没人记录改了哪条、为什么改、从哪里复制、失败后怎么恢复。每次变更都按这张小表走，后面接 Shopify、企业邮箱、广告域名验证和邮件工具都更稳。
先找来源
不要凭记忆填值。先打开 Shopify、邮箱服务或邮件工具后台，复制它明确给出的 host、type 和 value。
例：Shopify 给 www 的 CNAME；Google Workspace 给 MX；邮件工具给 DKIM 的 TXT / CNAME。
再拍现状
改 DNS 前先记录旧值。尤其是 MX、SPF、DKIM、DMARC，不要删除后才发现不知道原来是什么。
例：旧 MX 指向转发服务，新 MX 要切到 Workspace；旧 SPF 里已有 Shopify / Klaviyo 发信源。
一次只改一组
不要同时改网站访问、收信、发信和认证。一次只改一类记录，写清影响范围和预期验证时间。
例：今天只切 Shopify 主域；邮箱 MX 和 DKIM 等下一轮再动。
最后验收和回滚
验证通过才关闭任务；失败时先回到旧值或进入排查台，不要继续叠加第二个猜测。
例：主域能打开、HTTPS 正常、support@ 收到测试邮件、SPF/DKIM 检查通过。
这不是给技术同学看的形式主义。它解决的是三个月后你忘了谁改过 DNS、为什么邮件突然收不到、SPF 里哪一段还能删的问题。
记录主机名，例如 @、www、_dmarc、selector._domainkey。
写清 A、CNAME、MX、TXT，不要只写"加了一条记录"。
记录 DNS 后台显示的 TTL 和单位，例如 300 秒；复查传播窗口时要带上这个值。
保留修改前后值，尤其是 SPF 合并前后的完整字符串。
写值来自哪个后台或官方文档，避免后续团队不知道为什么这样填。
说明影响网站访问、收信、发信认证、广告验证还是邮件工具验证。
写清失败后恢复哪个旧值、谁执行、什么时候复查。
真实上线压力下，先判断能不能继续
DNS 和邮箱最危险的时刻不是填写记录，而是"看起来差不多了"就继续开广告、接支付、改政策页或发营销邮件。这个练习区让你先写不安全动作、继续条件、第一证据和暂停线。
Shopify 主域切换
根域名能打开，但 www、HTTPS、主域版本和旧链接还没有全部验收。团队想马上开广告和支付审核。
只凭"首页能打开"就继续，把广告、支付、Search Console 和客服链接都指过去。
暂缓放量。只有 Shopify 显示 connected、主域已选择、根域和 www 都走 HTTPS、旧链接能落到同一版本，才进入下一步。
Shopify Domains 页面、根域 / www 移动端截图、HTTPS 证书状态、旧链接抽样记录。
Shopify 域名设置、DNS A / AAAA / CNAME、旧链接和广告落地页。
未通过前，不切主域、不提交支付审核、不放广告预算。
接 Shopify 时，不要让多个版本都像主站
Shopify 域名连接的关键不是"我填过 DNS 了"，而是 Shopify 后台、根域名、www、HTTPS、旧链接和广告落地页最终都能解释成一个主域。
先判断你要的是收件入口，还是完整企业发信能力
这一步不要做价格榜。起步阶段的关键判断是：现在只需要品牌收件，还是已经需要正式客服回复、团队协作、订单通知和营销邮件发信。
Cloudflare Email Routing
起步阶段先拥有 support@、hello@ 这类品牌收件入口，也可以创建自定义地址和 catch-all 规则。
Email Routing 本身解决入站收信和转发；每条规则只能转发到一个已验证的目的邮箱（verified destination）。从这个转发目的邮箱回复，不会自动把品牌地址变成发件身份；如果要稳定从品牌域正式发信，需要另接独立 sending plan，例如 Cloudflare Email Service / Email Sending、Google Workspace 或 Microsoft 365。
一旦你要正式从品牌域回复客户、多人协作或接营销邮件工具，就要准备完整企业邮箱或独立的专业发信方案。
Google Workspace 和 Microsoft 365 的共同主线是先启用方案并添加域名，再按顺序完成验证、收件、发信认证和角色邮箱；不要把买完套餐当成完成。
购买邮箱方案并添加域名
先购买或启用 Google Workspace、Microsoft 365 等邮箱方案，再在服务商后台输入要使用的自定义域名；这一步建立方案和域名范围，不等于 DNS 已验证。
完成域名所有权验证
按后台给出的要求添加 DNS TXT 记录，确认服务商能证明你控制这个域名后，再继续切收件路径。
添加 MX 记录
清理不再使用的旧邮箱 MX，按 Google 或 Microsoft 的当前要求切换收件路径，并保留优先级和值。
补齐 SPF、DKIM、DMARC
不要只完成收件；合并 SPF、逐个启用 DKIM，再用 DMARC 观察合法发信源和报告邮箱。
创建正式邮箱角色
创建 hello@、support@、orders@、founder@ 等角色邮箱，完成收信和从品牌域回复的测试，并把管理员与恢复路径记入记录。
SPF、DKIM、DMARC 不是术语，是发信可信度的验收项
今天用自定义域名发邮件，没有认证就像没有身份证明。短期表现是进垃圾箱，长期表现是订单通知、客服回复和营销邮件都变得不稳定。
DMARC
把 SPF / DKIM 与 From 域对齐，并告诉收件方认证失败时怎么处理。
SPF/DKIM/DMARC 不只是填 DNS，而是验收发信身份
请先选择现在最薄弱的一项。详情区会告诉你去哪里查、什么证据算通过、看到什么信号就先暂停。这样复制出去的不是一句结论，而是团队能执行的验收记录。
SPF 发信来源表
继续条件不是上线授权。它只说明当前场景有足够证据做下一次受控动作；其他记录仍要逐项验收。若暂停线被触发，先保留旧值和测试证据，不用“看起来差不多”替代复查。
域名邮箱最后要能被接手，不是只能靠一个人记得
DNS 最怕"谁都能改一点，谁也不知道改了什么"。把注册商、DNS、邮箱后台、续费、恢复路径和变更日志都写清楚，后面才不会被基础设施拖住。
现在做一个域名邮箱上线判断
场景：域名已经能打开，Cloudflare Email Routing 也能把 support@ 转发到个人邮箱。但你还没有正式发信方案，SPF / DKIM / DMARC 没配，政策页联系邮箱和 PayPal 邮箱也不一致。下一步应该做什么？
把这篇教程变成一份域名邮箱上线复制笔记总结
这一课交付的不是"我买了域名"。你要交付的是谁拥有域名、谁能改 DNS、邮件怎么收、怎么发、怎么认证、怎么恢复。
先核对主域、收信路径、发信认证和暂停动作有没有写反；确认后再复制。
域名与企业邮箱复制笔记总结 当前压力: Shopify 主域切换 - 根域名能打开，但 www、HTTPS、主域版本和旧链接还没有全部验收。团队想马上开广告和支付审核。 第一证据: Shopify Domains 页面、根域 / www 移动端截图、HTTPS 证书状态、旧链接抽样记录。 本周动作: 暂缓放量。只有 Shopify 显示 connected、主域已选择、根域和 www 都走 HTTPS、旧链接能落到同一版本，才进入下一步。 暂停动作: 未通过前，不切主域、不提交支付审核、不放广告预算。 复盘窗口: 刚改完还没生效 - 记录修改时间，等待一个合理窗口后再复查；不要在等待期间反复改值。 下一步路线: 准备接 Shopify - 把主域名、HTTPS、DNS 传播和旧链接都验收完，再进入 Shopify 店铺搭建。 邮箱方案: Cloudflare Email Routing - Email Routing 本身解决入站收信和转发；每条规则只能转发到一个已验证的目的邮箱（verified destination）。从这个转发目的邮箱回复，不会自动把品牌地址变成发件身份；如果要稳定从品牌域正式发信，需要另接独立 sending plan，例如 Cloudflare Email Service / Email Sending、Google Workspace 或 Microsoft 365。 域名邮箱认证验收: SPF 发信来源表 - SPF 已合并为一条，包含当前真实发信源；旧发信源删除前先留截图。 DNS 字段证据: A / AAAA：主域访问证据 - 保留 Shopify Domains 截图、根域名打开截图、HTTPS 状态和旧链接跳转结果。 Scanner 输入: 带到 Store Launch Readiness Scanner：主域 URL、HTTPS 状态、是否有旧链接或 www 分裂。 DNS 记录核对进度: 1/5 DNS 上线层级: 上线最低配置 - 只证明域名访问、HTTPS 和 support@ 收信有一条可复查的最小路径。 当前层级关卡: 0/3 记录找错题: 还未选择。 故障树入口: 网站或 HTTPS 还没稳定 - 先比对当前 host、value、修改时间和验证页状态，不在等待期间继续猜值。 这次记录或变更的名称: ___ Host / Name: ___ TTL: ___ 当前值的权威来源位置: ___ 预期目标或通过证据: ___ 保存或观察时间: ___ 传播或复查证据: ___ 快速自测: 还未选择，先完成上线判断。 域名注册商 / DNS 托管: 例如：域名在 Cloudflare Registrar，DNS 也由 Cloudflare 托管，负责人是... Shopify 主域 / HTTPS 状态: 记录主域、www、HTTPS、旧链接和验证状态。 角色邮箱 / 收信测试: support@、orders@、hello@ 分别转到哪里，最近一次测试时间。 正式发信方案: Google Workspace / Microsoft 365 / 其他发信工具，以及客服回复、订单通知、营销邮件的发信域。 SPF / DKIM / DMARC 状态: 记录每条认证记录、服务商、测试结果和下一次复查日期。 DNS / 认证排查记录: 记录症状、第一检查项、可能原因、下一步和截图证据。 DNS 字段证据 / Scanner 输入: 记录 A/CNAME/MX/SPF/DKIM/DMARC 里当前最薄弱字段、在哪里查、谁读取、错了会坏什么，以及要带进 Scanner 的证据。 DNS 变更继续/暂停记录: 记录压力场景、不安全动作、继续条件、第一证据、修复位置和暂停线。 账号负责人 / 续费 / 恢复路径: 写清管理员、2FA、备用邮箱、续费提醒、恢复入口和紧急联系人。 变更日志位置: DNS、邮箱、发信工具每次修改记录在哪里维护。
域名邮箱过关后，再接 Shopify、支付和政策页
本课完成标准：你能说明域名在哪里、DNS 谁能改、Shopify 主域是什么、邮箱怎么收发、SPF/DKIM/DMARC 处于什么状态，以及主账号失效时怎么恢复。只会说“域名已经买了”不算完成。
Basics 关联阅读
把域名邮箱接回选品和后台设置
域名和企业邮箱先服务真实市场与订单路径，再进入后台配置。下面的链接帮助继续核对商品方向和店铺设置，但不证明认证、送达或上线结果。