建立 Taleo 版本和消息所有者
Oracle Taleo 不是一个足够的配置标识符。记录组织是否使用 Taleo Enterprise Edition、Taleo Business Edition、Sourcing 或集成工作流程。确定特定租户、生产或暂存环境、消息类型和预期发送者。本文是一份以证据为主导的准备和验证指南。公共研究并未建立当前第一方租户特定的 SPF 和 DKIM 设置配方，因此原始配置范围仍处于保留状态。
版本 22a 的历史 Oracle Sourcing 配置页面明确区分了企业版和商业版集成，并包括企业路由的允许集成发送电子邮件设置。这支持识别哪个系统产生消息的需要。它是历史文档，而不是有关当前租户界面或支持的身份验证设置的声明。 Oracle Taleo 配置设置
从实际通知的示例开始，其交付很重要。招聘确认、候选人信件、推荐通知和帐户安全消息可能有不同的所有者。不要假设招聘人员的普通邮箱发送的消息会确定 Taleo 应用程序的行为。在建议DNS更改之前清点工作流程。
将应用程序设置与电子邮件域证明分开
配置的公司电子邮件域、集成端点或候选地址不是DKIM密钥。同样，允许集成发送并不授权其在DNS中的基础设施。仅检查应用程序的工作流程设置以确定消息的来源。身份验证证据必须将消息连接到实际的信封身份和签名域。
尽可能保留收到的消息的基线，包括发件人域， Return-Path、 DKIM d= 和 s= 值，以及接收者的身份验证结果。从共享的故障排除材料中编辑申请人内容和标识符。不要仅仅为了获得通过/失败标签而将候选数据发送到公共标头分析工具。
如果没有发出消息，请在更改身份验证之前检查工作流触发器和操作日志。抑制或禁用的通知不同于接收者拒绝发送的消息。将应用程序执行、 SMTP接受和收件人传递作为变更单中的单独观察。
请求提供者提供准确的处方
请租户管理员或 Oracle 支持人员确认版本、模块、环境和外向交付路由。请求预期发件人域的准确记录：类型、完整所有者、值、 选择器、任何返回路径配置和所需的激活步骤。询问处方涵盖哪些工作流程以及更改是全域范围的还是特定于环境的。这是建议的证据请求，而不是声称经过审查的公共文档可以保证特定的支持工作流程。
还请求密钥轮换和回滚指导、任何发件人批准要求以及每种消息类型的安全测试方法。如果支持人员提供的文档仅在登录后可用，请让授权管理员将相关的当前说明和适用性声明与票据一起保留。在检查其实际内容之前，请勿报告已审查的此类文件。
不要仅仅因为两个系统都处理招聘而使用 Fusion HCM 设置。不要从 Oracle 所有权推断 OCI 电子邮件传送区域或选择器。历史论坛值和第三方配方可以作为调查线索，但它们不是关闭本指南范围保留所需的第一方生产配方。
在应用建议的DNS更改之前验证它
获得适用的处方后，将其与权威区域进行比较。识别DNS 主机、现有TXT策略、选择器所有权和其他授权发件人。保留变更前的值并获得正常的变更批准。在替换记录之前，管理员必须解决现有所有者的任何冲突。
SPF需要针对给定域的单一策略，并在评估期间限制 DNS 查询机制。添加第二条v=spf1记录并不是添加提供程序的安全方法。正确的策略所有者是由正在评估的SMTP身份确定的，而不是由读者在电子邮件客户端中看到的地址确定的。 SPF RFC 7208
DKIM将签名域和选择器连接到公钥。发布选择器不会使服务开始签名。捕获权威DNS答案和提供商激活的证据。在提供商批准的转换间隔内保留以前的选择器，而不是在新选择器出现后立即删除它们。 DKIM RFC 6376
通过接收者证据接受每个工作流程
通过每个批准的 Taleo 工作流程向受控收件人发送无害的消息。记录发起事件、环境、消息标识符和时间戳，以便将应用程序日志和接收到的消息连接起来。检查可信接收者的结果，而不仅仅是复制到消息中的签名标头。
为了 DMARC，将可见的From域与实际下传递的SPF域或DKIM签名域进行比较 结盟 模式。不相关的 Oracle 域下的身份验证可能有效，但与公司的 From 域不一致。因此，成功的SMTP切换或SPF传递本身是不够的。 DMARC RFC 9989
如果投递失败，请保留准确的退回或拒绝及其发生的阶段。单独的DNS查找错误、签名缺失、域错位和收件人策略决策。避免削弱组织的DMARC策略来补偿一个未识别的工作流程。首先确定哪条路由失败以及是否激活了预期的身份验证方法。
Taleo 证据请求工作表
在组织提供现场证据之前，以下建议的工作表故意不完整。
- 产品标识：版本、模块、发行版或当前服务版本、租户和环境。
- 消息来源：触发器、应用程序所有者、发件人地址、回复目的地和业务重要性。
- 提供商规定：第一方文档或支持参考、确认的适用性、记录集、激活和轮换说明。
- DNS审核：权威提供商、现有策略、变更所有者、冲突审核和回滚值。
- 工作流程矩阵：每行一行用于确认、信件、推荐或其他范围内的消息；预期发件人和测试收件人。
- 身份验证证明：信封域、 DKIM d= 和s=,接收结果、对齐模式和证据时间戳。
- 批准决定：接受的路线、排除的路线、剩余的提供商问题和 SME 签名。
误认为身份验证的集成切换的虚构诊断
这个例子是虚构的。管理员在招聘环境中启用集成电子邮件，并假设公司的域现已通过身份验证。候选者通知到达具有提供商域SPF通行证但未对齐的测试邮箱 DKIM签名。 DNS管理员被要求将 Fusion SPF示例复制到公司的策略中。
正确的下一步是确定 Taleo 版本和确切的通知途径，然后获取其适用的处方。集成设置解释了为什么可以发出消息；它没有解释如何对 From 域进行身份验证。该团队保留工作策略并收集特定于路线的支持答案。最终诊断仍然是临时的，直到DNS 、激活和新接收器测试建立一致的身份验证。
范围和发布门槛
这份手稿提供了有用的准备和测试规则，而不是发明的 Taleo 设置方法。当前的提供商配置证据、租户发布的记录、实时DNS 、真实消息测试、目视审查和 SME 人工批准都在等待中。在这些差距得到解决之前，最初的广泛提供商主题必须保持不被接受。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989 第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。