建立 Eloqua 发送和品牌范围
将 Eloqua 营销活动和销售个性化消息视为可能不同的发件人域情况。在要求DNS所有者进行更改之前，先确定 Eloqua 实例、品牌和发送域。 Oracle 描述了在新订阅帐户的第一个活动之前转换为品牌域的情况。品牌先决条件本身并不是特定活动通过的证据 DMARC。看 Eloqua 电子邮件身份验证和品牌推广.
本文的范围是基于公共文档的 Eloqua 实施和验证计划。精确的按键， 选择器 名称、信封域和租户激活步骤必须来自当前的 Eloqua 入门或支持工作流程。不要仅仅因为 OCI Email Delivery 或 Responsys 也是 Oracle 产品就从它们复制记录。
确认 From 和反弹先决条件
在DNS发布或测试发送之前，请确认预期的发件人域与已配置的 Eloqua 反弹域的子域匹配。 Oracle 指出，不匹配可能会产生验证错误并阻止发送。其示例将go.example.com的发送子域与return@go.example.com或bounce@go.example.com配对。记录所选品牌实际配置的回弹地址和域名；不要将建议的反弹值视为现有配置。看 Eloqua 电子邮件身份验证设置、电子邮件退回地址和电子邮件默认值：发件人和回复地址。
检查电子邮件默认值和任何每个电子邮件的覆盖。 Oracle 指出，当配置了多个域时，可以更改反弹域。可编辑的“发件人”字段并不表明允许使用任意公司域。如果签名规则建议不同的发件人域，请在启用路由之前获取受支持的公司发件人及其配置的退回配对的帐户特定确认。如果该先决条件无法得到验证，请保留该状态。 DKIM 仅签署覆盖范围并不能消除此发送要求。
协调活动和公司发件人域
Oracle的身份验证设置页面描述 SPF 作为 Eloqua 部署的一部分，并在代表销售团队发送公司域签名规则时调用公司域上的公钥发布。这使得实际的来自域库存很重要，尤其是当营销活动和个性化销售消息使用不同的域时。看 Eloqua 电子邮件身份验证设置.
列出允许的发件人地址、其已确认的配置反弹配对以及生成每个地址的模板或签名规则。从主要活动路径和任何公司域路径捕获基线。从营销子域发送的测试无法建立销售人员公司地址的签名覆盖范围。单独保留 Reply-To，因为回复和身份验证具有不同的目的。
获取并发布特定于帐户的更改集
请求已识别实例和域的当前 Eloqua 说明。审核数据包应包括确切的公共DNS所有者、记录类型和值、预期的签名域、激活步骤以及现有品牌域的任何先决条件。公共文档建立了工作流程概念，但并未为每个帐户提供通用的复制粘贴记录集。
在发布之前，检查当前区域并确定现有的SPF授权。请勿在同一所有者处添加第二个SPF策略。 SPF标准定义了记录选择和 DNS 查询限制；拟议的增加必须通过现有机制进行评估，而不是作为一个孤立的字符串进行评估。看 RFC 7208发件人策略框架。保留不相关的合法发件人和不相关的DKIM选择器。
DNS所有者发布批准的更改后，确认权威响应并要求 Eloqua 所有者完成指定的激活。独立记录每一面。当应用程序仍然使用另一个身份进行签名时，可以存在公钥，并且当委派区域配置错误时，应用程序状态可以显示为就绪。
测试每个真实的活动路径
仅当发件人和配置的反弹配对通过 Eloqua 验证后，才从实际营销活动配置向受控接收者发送一个小型的、同意的测试。仅在确认其支持的发送配置和反弹配对后才包含个性化公司域路由。如果 Eloqua 在传输前阻止不匹配的发送方，请在诊断接收方身份验证之前解决该先决条件。记录自， Return-Path、 DKIM d= 和s=,以及接收系统的SPF 、 DKIM和DMARC结果。 DKIM签名 验证和DMARC 结盟 是不同的测试。看 RFC 6376域名密钥识别邮件 和 RFC 9989基于域的消息身份验证报告和一致性.
将已发送的消息与批准的域清单进行比较。当发件人地址动态变化时，测试多个代表值。不要从静态模板预览中推断一般覆盖范围。还要验证回复是否发送到预期邮箱以及跟踪的链接是否按预期运行，而不将任何测试视为身份验证证明。
Eloqua 域名接受工作表
对活动域和每个公司域签名案例使用单独的行：
- 实例和品牌：____；活动或签名规则：____。
- 实际发件人地址和域名：____；允许的域名所有者：____；受监控回复：____。
- 已为该品牌配置反弹地址和域名：____；证明发件人与配置的退回子域匹配的证据：____。
- 默认与每封电子邮件来自覆盖：____；如果启用了多个域，则选择已配置的域：____。
- 企业签名规则路由确认和帐户/支持参考：____；发送前 Eloqua 发件人验证结果：____。
- 帐户说明或支持参考：____；发布的记录所有者和类型：____。
- 现有SPF依赖项和建议合并：____； DKIM选择器和签名域：____。
- 权威DNS观察：____； Eloqua 激活确认：____。
- 受控测试时间戳和消息 ID：____；接收者： ____。
- SPF特性和结果：____； DKIM身份和结果：____；协调机制：____。
- 异常所有者、恢复路线和释放决定：____。
拒绝具有未配置或不匹配的反弹配对、未经确认的公司签名规则路由、从另一个实例复制的选择器或具有不同 From 域的成功样本的行。将丢失的帐户指令标记为未解决，而不是用第三方配方替换它们。
销售签名失败的虚构诊断
仅虚构示例：Riverbend 已单独确认帐户支持的企业发件人路由，为example.com配置其反弹配对，并通过了来自salesperson@example.com的销售消息的 Eloqua 发件人验证。来自news.example.com的活动路线也具有有效的配置反弹配对。这些是示例的明确假设，未观察到客户设置或选择任意公司 From 域的权限。
已传递的销售邮件通过d=news.example.com的DKIM ，但未通过DMARC因为虚构域使用严格的DKIM对齐 ( adkim=s),可见的发件人域是example.com ，并且没有对齐的传递SPF结果。因此，成功的营销活动样本不能证明该销售路线的一致性。在宽松的DKIM对齐下，那些相关的签名域和发件人域可以对齐；该示例不得推广到该模式。
团队保留有效的发送和退回配置，请求支持的公司路线的正确的特定于帐户的签名范围，并在激活后验证新的销售消息。如果“发件人”和“反弹”先决条件无效，则第一个诊断将是 Eloqua 的验证或阻止发送情况，而不是接收消息对齐失败。没有检查 Riverbend 帐户或消息。
关闭运营循环
身份验证工作后，将反馈循环加入作为单独的操作任务进行处理。 Oracle 描述了在DKIM设置后联系支持人员并完成相关确认过程。不要仅仅因为消息已签名就声称启用了投诉报告。看 Eloqua 电子邮件身份验证设置.
为失败的域更改保留回滚计划，保留工作选择器直到发送所有者确认退出，并在品牌、签名规则或发件人域更改后重新测试。身份验证不保证收件箱的放置或授权联系人列表。该纪录片候选者的帐户发布记录、实时DNS 、接收器测试、目视检查、SME 人工批准和发布仍有待完成。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989 第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。