确认 OCI 电子邮件传送是传输
仅当应用程序实际通过 Oracle Cloud Infrastructure Email Delivery 发送时才使用此过程。在触摸DNS之前记录租赁、隔离、区域或领域、应用程序和所需的来自域。这很重要，因为 Oracle 产品名称本身并不能识别传输。 Oracle 从其 OCI 中排除了多项 SaaS 和集成服务 DKIM 控制台程序。看 OCI 电子邮件传送配置DKIM.
这是配置和验证计划，而不是已完成的租户更改。必须在相关服务和领域中生成或确认准确的DNS值。不要将SMTP凭据、私钥和租户机密保留在文章和证据包中。
准备域和发件人清单
决定哪个 组织域 旨在出现在“发件人”中以及哪个应用程序被授权使用它。验证对其公共DNS的控制。创建一个更改记录，列出使用该域的其他发件人，当前 SPF 授权、现有选择器和这些集成的所有者。全新的子域可以简化操作，但它必须适合业务身份和支持的提供商配置。
批准的发件人属于某个隔间并且是特定于区域的。 Oracle 要求批准发送地址，并讨论提交的信封和标头地址不匹配的额外授权影响。看 OCI 管理批准的发件人。因此，在将拒绝的提交诊断为DNS问题之前，请将应用程序端点区域与资源区域进行比较。
生成正确的DKIM记录
在适用的商业 OCI 控制台工作流程中，打开电子邮件域，添加DKIM密钥并生成提供商记录。 Oracle 描述了一个 CNAME 商业流量为 TXT 值，非商业领域为TXT值。使用为所选域和领域显示的确切所有者和值，而不是根据记住的区域代码组装的示例。看 OCI 电子邮件传送配置DKIM.
DNS运营商应检查所提供的所有者是否完全合格，或者是否必须相对于该区域输入。记录DNS接口应用其后缀后生成的全名。即使应用程序生成的值正确，重复的区域后缀也会导致发布错误。确认公共权威解析后完成服务端激活。不要删除其他应用程序的 选择器 为新的腾出空间。
使SPF与发送区域一致
Oracle 的SPF文档提供了区域相关的授权，包括单独的商业分组以及政府或其他领域的参考。不要假设商业包含适合主权或政府部署。看 配置SPF OCI 电子邮件传送。获取适用的当前值并与现有发送者一起对其进行评估。
在相关所有者处发布一项SPF策略并评估其 DNS 查询预算。保留其他合法授权，而不是用仅限 Oracle 的示例覆盖它。 SPF标准的记录选择和查询限制适用于组合策略。看 RFC 7208发件人策略框架。控制台中的SPF验证是有用的配置证据，但不能替代接收方 结盟 分析。
练习提交和接收者验证
首先验证应用程序是否使用批准的发件人配置通过预期端点提交。然后检查新收到的受控消息。记录可见的发件人、已发送的信封身份、每个相关的DKIM签名域和选择器以及可信接收者的身份验证结果。成功的SMTP提交证明接受处理，而不是在最终目的地成功进行身份验证。
使用交付的身份，而不是假设提交的信封未更改。 DKIM通行证显示签名验证； DMARC 另外还需要与 From 建立适当的关系。确定在已发布的对齐模式下哪个传递机制提供对齐。看 RFC 6376域名密钥识别邮件 和 RFC 9989基于域的消息身份验证报告和一致性。将递送、收件箱放置和身份验证保留为单独的结果字段。
OCI 电子邮件传送验收工作表
- 申请及留言目的：____；租赁或批准的内部参考：____。
- 隔间：____；终点区域：____；批准的发件人区域：____；领域：____。
- 电子邮件域名：____；提交的发件人和信封地址：____。
- DKIM记录来源：____；完全所有者：____；记录类型和目标：____。
- 权威DNS响应和时间戳：____；服务激活证据：____。
- 适用的SPF来源和现有政策审查：____； DNS 查询评估：____。
- 测试消息 ID 和接收者：____；观察到的信封域：____。
- DKIM d= 和s=: ____； SPF和DKIM结果：____； DMARC和对齐路径：____。
- 恢复设置、应用程序所有者和批准决定：____。
为每个区域或应用程序配置使用一个新行。不要仅仅因为辅助端点使用相同的可见域而将其标记为就绪。
区域发件人拒绝的虚构诊断
仅虚构示例：Cedar Lab 将应用程序端点移动到第二个区域。其DNS记录保持不变并正确解析，但提交在到达测试邮箱之前失败。团队发现批准的发件人仅存在于第一个区域。它验证预期的区域资源和授权，而不是重复编辑SPF 。
提交成功后，团队仍会检查新收到的DKIM和DMARC消息。解决区域资源问题并不意味着下游的协调。没有检查 Cedar Lab 的部署。
发布和维护门
仅在应用程序资源、 DNS和接收消息证据一致后才批准试点。根据适用的提供商指南，保留之前的回滚工作路径、记录密钥所有权并安排轮换。将域、地区或领域的更改视为新的验证事件。
所有租户发布的值、实时DNS检查、提供商激活、接收者观察、目视审查和 SME 人工批准仍然悬而未决。本文涵盖 OCI 电子邮件传送，而不是所有 Oracle 品牌的电子邮件服务，并且尚未发布。
在不丢失工作路线的情况下规划钥匙翻转
当前的 OCI 控制台文档允许每个电子邮件域有两个密钥，但一次只能有一个活动记录。它建议每六个月轮换一次。在替换任何内容之前记录活动选择器和批准的转换，并使用特定于服务的轮换指令，而不是假设添加第二个公钥会激活它。轮换计划并不是完整的测试。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989 第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。