在更改DNS之前路由 Oracle Cloud 邮件
Oracle Cloud 不是单一的电子邮件发送配置。首先确定实际创建和传输消息的服务。使用 OCI 电子邮件传送、Fusion 通知和 Eloqua 活动的基础设施应用程序可以共享企业发件人域，同时具有不同的激活工作流程。本文提供了路由和验收计划。它没有建立通用的Oracle云 SPF 包括或 DKIM选择器.
Oracle 明确从 OCI 电子邮件交付中排除 Fusion Apps、云通知服务、经典 IDCS、Oracle Integration Cloud Generation 2 和 OTMGTM DKIM 控制台程序。这些路线需要特定于产品的说明或支持。共享域的不同服务密钥需要不同的选择器。看 OCI 电子邮件传送配置DKIM.
建立产品和运输库存
向应用程序所有者询问确切的产品名称、环境、区域、消息类型和传输设置。单独标记为 Oracle Cloud 的屏幕截图是不够的。记录应用程序是否提交到电子邮件传送端点、发出托管 SaaS 通知或委托发送到其他服务。请勿使用 IP 地址或营销页脚作为产品的唯一证明。
从正在评估的工作流程中捕获一条无害的基线消息。保留其时间戳、接收者、消息 ID、可见发件人、 Return-Path 和DKIM d= 和 s= 值。将它们与应用程序配置进行比较。如果所有者无法将消息连接到特定环境，请保留配置，而不是扩大DNS权限以适应猜测。
分配正确的配置所有者
对于已识别的 OCI 电子邮件传送路由，电子邮件域和批准的发件人资源属于该服务。批准的发件人是区域资源，因此在一个区域中配置的发件人不会在另一区域中建立批准。看 OCI 管理批准的发件人。对于 Fusion，记录的DKIM过程是手动的，并且根据环境重复，而不是 OCI 控制台操作。看 Fusion 应用程序配置电子邮件安全.
为每个产品和环境创建单独的变更记录。 DNS所有者应从适用的工作流程接收精确的记录所有者、类型和值。应用程序所有者必须单独确认激活。这两项批准回答了不同的问题：所需信息是否公开发布以及预期发送者是否实际使用该信息。
评估身份验证而不混淆身份
SPF评估其SMTP身份的授权； DKIM验证与签名域关联的签名。熟悉的显示名称和批准的发件人条目都不能证明 DMARC 结盟。 DMARC成功需要通过对齐的SPF或DKIM结果，具体取决于适用的对齐模式。使用 RFC 7208发件人策略框架, RFC 6376域名密钥识别邮件 和 RFC 9989基于域的消息身份验证报告和一致性 对于这些区别。
对于每个路由，在观察到的经过身份验证的域旁边写下预期的发件人域。然后解释哪条路径提供对齐。如果提供商拥有的信封域通过SPF但与组织发件人域不同，请检查DKIM ，而不是假设单独SPF就足够了。不要削弱组织的DMARC策略来隐藏未识别的路由。
Oracle 云路线工作表
使用以下字段为每个业务工作流程创建一行：
- 应用程序和确切的 Oracle 产品：____；环境或 Pod：____；地区或领域：____。
- 消息类型和企业主：____；观察到的传输或终点：____。
- 基线消息 ID 和 UTC 时间戳：____；受控接收器：____。
- 可见自：____；信封域：____； DKIM d= 和s=: ____。
- 适用的第一方程序：____；检查的排除程序：____。
- DNS记录所有者和发行值来源：____；激活所有者和证据：____。
- 预期的协调机制：____；观察结果：____；未解决的范围：____。
- 试点决策、回收所有者和人员批准：____。
将不受支持的路由保留为单独的未解析行。成功的 OCI 测试不得将 Fusion 行变为绿色。这种隔离可以防止共享品牌名称被视为共享技术范围。
错误的 Oracle 路线的虚构诊断
仅虚构示例：Fusion 发票通知身份验证失败后，Northstar Services 添加 OCI 电子邮件传送DKIM记录。新的选择器可以正确解析，但发票仍然带有原始签名身份。 DNS查找证明发布，而不是 Fusion 已采用密钥。该团队识别 Fusion 环境并请求其支持的激活程序。仅当实际 OCI 应用程序仍需要 OCI 记录时，它才会保留 OCI 记录。
诊断课程是在更改记录之前使消息与生成服务保持一致。本文未测试任何实时 Northstar 租户、 DNS区域或消息。
接受和剩余的门
仅在正确的产品流程、权威DNS 、应用程序激活和受控接收消息证据一致后批准指定的工作流程。重新测试更改的区域、自定义发件人域和备用通知类型作为不同的路由。存档经过编辑的样本和确切的变更修订版，然后在商定的试点期间监控回归情况。
最初广泛的 Oracle 云主题仍然是一个范围。本路由文章并不是每个 Oracle 服务的配置指南。现场租户检查、发布的值、 DNS和接收器测试、目视审查、SME 人工批准和发布仍有待确定。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989 第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。