首先识别 Netcore CE 或 Netcore Email API
Netcore 帐户标签不足以选择DNS配方。 Netcore 为其客户参与平台 (CE) 和电子邮件 API 发布了单独的域设置说明。产品登录页面将电子邮件 API 标识为以前的 Pepipost。记录哪个产品、租户或子账户发送消息以及应用程序是否使用SMTP 、API 集成或 CE 活动。不要仅仅因为旧的 Pepipost 文章都带有 Netcore 名称，就将它们应用到 CE 屏幕上。 网芯产品登录, CE域设置, 邮件API验证.
在添加发送域之前清点真正面向客户的流量。收据、登录链接和营销活动可能具有不同的应用程序所有者和发件人域。对于每个，保留基线消息或提交失败、配置的发件人、当前域状态以及谁控制权威DNS 。以下步骤描述了记录的分支；帐户生成的主机名和值优先于示例。
电子邮件 API：将DNS验证与批准分开
保留的电子邮件API设置指南描述了发布仪表板提供的 SPF TXT且独特 DKIM TXT记录，然后使用检查DNS记录。如果SPF所有者已存在策略，请将所需的授权合并到该策略中，而不是添加另一个候选策略 SPF记录。不要将完整的示例策略粘贴到其他合法发件人的权限上。 DNS验证后，域进入审批流程，其中包括自动检查和手动审核。经过验证的DNS记录本身并不能确定该域已获准发送。 电子邮件 API 域验证和批准.
将两个结果保留在单独的工作表字段中。如果DNS正确但仍待批准，请调查帐户的审核状态和请求的业务信息。重复的DNS编辑可能会在未经批准的情况下掩盖工作配置。相反，活动帐户并不证明特定的发件人域或子帐户已准备就绪。
Netcore 的解释指南还描述了运营商在检测到现有策略时必须发布的修订后的SPF值。将该建议值与当前权威记录进行比较：自仪表板首次读取以来，另一个团队可能已更改DNS 。保留有意的权限并评估完整的查找路径。对于DKIM ，请使用与所选域关联的主机名和值。单独的选择器可以提供不同的服务，但其中的值会发生冲突 选择器 不能通过堆叠任意键来解决。 电子邮件 API SPF和DKIM说明, SPF处理规则.
CE：验证每个生成的DNS行
CE 文档指定设置 → 电子邮件域 → 添加域。输入域后， DNS配置屏幕会提供每条记录的用途、类型、主机名、值和状态。记录类型可以包括TXT 、 CNAME 和MX ；复制实际为租户提供的行，而不是强加电子邮件 API 两 TXT 模型。该指南表示，所有生成的记录都必须进行配置和验证。使用验证，然后在成功时完成流程。 CE 添加电子邮件域.
同一 CE 指南区分成功、待定、错误和已迁移。待处理和错误不允许发送。它还警告，在验证后编辑主机名会使域处于非活动状态，并需要重新验证所有记录。将主机名编辑视为具有中断风险的受控更改。下载DNS设置的可用性对于证据移交很有用；它不能证明记录已发布或接收者已验证消息。
请勿重新指向组织的普通入站 MX记录 仅仅因为生成的行使用MX 。首先确定租户的确切所有者和用途。发送或退回子域可以有自己的DNS配置。所审查的公共文本并不证明通用 CE 主机名、 MX目标或DKIM选择器是合理的。
自定义信封：发布和激活是不同的步骤
Netcore Email API 单独记录了一个自定义的 Return-Path 过程。它描述了选择子域、发布提供的CNAME映射以及要求交付团队为帐户启用自定义信封/ Return-Path和DKIM 。该记录过程意味着仅发布的CNAME并不能证明消息已切换身份。在依赖此选项之前，请确认当前的租户说明和激活状态。本文保留了 Pepipost 时代的命名，因此不要将其目标或支持流程推广到 CE。 电子邮件 API 自定义Return-Path.
确定为什么需要定制信封。仅当实际信封域满足发件人域时，它才能提供对齐的SPF路径 结盟 要求和SPF通过。相关子域可以满足宽松对齐，而严格对齐则需要精确的域相等。经过验证、对齐 DKIM签名 可能已经供应了 DMARC 小路。不要仅仅因为DMARC仅需要一种对齐的传递机制而删除提供商所需的DNS记录。 DMARC对齐规则.
填写产品特定的 Netcore 工作表
每个租户/子帐户和发送域使用一份副本。将每个生成的DNS行复制到单独的编号条目中，而不是将多个用途合并为一个。
- 产品：CE/电子邮件 API。租户/子账户：______。申请或活动：______。
- 预期来自域：______。当前配置的发送者：______。 DNS管理机构和运营商：______。
- 生成的行号：______。目的： ______。所有者： ______。类型： ______。确切的价值证据：______。权威结果及UTC时间：______。
- 保留现有SPF权限：______。完成 DNS 查找评估：______。
- 域DNS状态：______。 API 批准状态（如果适用）：______。证据日期：______。
- 计划更改 CE 主机名吗？ ______。重新验证和中断所有者：______。
- 需要定制信封吗？ ______。出版所有者：______。提供商激活确认：______。收到的信封标识：______。
- 测试工作流程和消息 ID：______。来自域：______。 SPF域/结果：______。每个DKIM
d=/s=/ 结果： ______。 - 接收者DMARC结果：______。对准方式及通过路径：______。
- 弹跳处理检查：______。回滚路线：______。发布批准人：______。
诊断规则：缺少权威数据是发表问题；等待 API 批准是一个服务批准问题；发布后的不同信封是激活或路由问题。在进行另一次更改之前，将故障分配给正确的所有者。
虚构的诊断：经过验证的DNS 、旧信封
虚构的训练示例，不是 Netcore 测试结果。应用程序发送收据 receipts.example。其所有者已发布该帐户的DKIM记录并请求自定义信封： bounce.receipts.example。收到的消息仍然使用不相关的服务信封，但DKIM通过 d=receipts.example。受信任的接收者报告DMARC通过。
该工作表解释了这两个发现： DKIM提供对齐的通过路径；定制信封切换尚未得到证实。管理员检查提供程序是否激活以及应用程序是否使用预期的租户。添加更多SPF权限 receipts.example 不会更改该消息中服务拥有的信封。确认激活后，新收据必须显示预期的信封和成功的退信处理。
在第二个虚构的 CE 案例中，经过验证的主机名在活动启动期间被编辑，并且域变为非活动状态。正确的响应是完成所需的重新验证并保持发送暂停，直到 CE 允许为止。电子邮件 API 批准票将解决错误的产品工作流程。
验收与恢复
在权威DNS上查询确切的记录所有者，然后将递归结果与时间戳进行比较。检查收到的签名以及仪表板。已发布的DKIM密钥证明可用性，而不是应用程序使用该密钥；成功的 API 提交证明服务已接受，而不是收件箱放置。使用受控交易和接收者，评论包中没有真正的重置令牌或客户数据。 DKIM验证.
保存更改前的DNS和应用程序设置。如果新路由失败，请暂停受影响的发件人，仅恢复更改的配置并测试新消息。在切换传输之前检查排队的发送以避免重复。将不相关的域和活动保留在变更之外。
本手稿未测试任何实时 Netcore 租户、 DNS更改或收到的消息。工作表和示例是准备材料。在发布之前仍需要当前产品/租户适用性、激活和批准证据、权威DNS 、实时消息测试、视觉审查和 SME 人工批准。