当 Jira 或 Confluence 应从组织的域发送通知时，使用 Atlassian Cloud 支持的自定义电子邮件工作流程。本指南涵盖了该组织管理模型。它不是 Statuspage、Trello、自托管数据中心或外部SMTP服务器的通用记录配方；这些产品和路线需要自己的第一方说明。
确认通知模型
确定组织、应用程序、预期的自定义发件人地址以及负责的管理员。区分从 Atlassian 拥有的域接收邮件和授予 Atlassian 使用您的自定义身份发送的权限。您无需编辑您的域名 SPF 只是为了接收从其他人的域发送的通知。
Atlassian 的 Jira Cloud 指南指导组织管理员通过 Atlassian Administration 添加自定义电子邮件地址。其组织设置工作流程将添加电子邮件域、发布生成的DNS记录、添加地址并使它们可供相关应用程序使用分开。用于管理帐户的域验证不能替代完成此电子邮件身份验证工作流程。
发布完整生成的记录集
通过当前的自定义电子邮件设置添加电子邮件域，并将显示的DNS所有者、记录类型和目标复制到更改请求中。 Atlassian文档二 DKIM CNAME 此身份验证模型中的记录和退回CNAME 。两条DKIM记录支持密钥轮换。弹跳域 CNAME别名 支持提供商管理的信封身份和SPF行为。
准确发布组织设置屏幕生成的记录。请勿使用从不相关的 Atlassian 产品复制的通用SPF TXT替换退回CNAME ，也不要发明 选择器 来自应用程序 URL 的目标。不要在必须保留其正常MX和其他记录的域的根部添加CNAME 。生成的所有者名称标识预期的别名。
检查DNS控制台是否需要完整的所有者名称或相对标签。重复的域名后缀丢失 后备选择器 或不正确的目标可能导致验证不完整。查询权威DNS服务并将每个答案与设置屏幕进行比较，然后再次按验证。
完成申请交接
记录匹配后，等待 Atlassian 的域配置完成并确认域状态为“活动”。匹配的DNS与完成的配置不同； Atlassian 记录称，这可能需要长达 72 小时。然后才能完成地址和申请的交接。添加所需的电子邮件地址，并根据当前的管理流程将其提供给目标应用程序。选择相关通知配置的批准地址。将所有权验证步骤、地址可用性和应用程序选择保留为单独的清单项目：当应用程序仍使用其以前的默认发件人时， DNS可能是正确的。
从确切的 Jira 或 Confluence 工作流程触发受控通知。捕获其原始外部标头。记录实际的发件人地址、 SPF smtp.mailfrom 域、 DKIM d= 和 s= 值以及受信任的收件人 DMARC 结果。成功的DNS检查器是必要的设置证据，而不是每个应用程序消息身份的证明。
评估对齐情况而无需猜测跳出格式
Atlassian 管理所提供别名的目标端；生成的值是特定于帐户的证据。不要在操作 Runbook 中对退回主机名模式进行硬编码。将收到的消息中实际看到的域与已发布消息下的 From 域进行比较 结盟 模式。
综合示例：来自notifications@example.com有一个传递 DKIM签名 带有d=example.com和不相关的传递SPF身份。精确匹配的DKIM路径可以满足DMARC 。如果缺少预期的自定义签名，Atlassian 拥有的域的有效签名不会自动与example.com对齐。在确定DNS出现故障之前，保留所有签名和完整路由。
您的组织仍然对保护其可见发件人域的DMARC策略负责。清查其他合法发件人并协调报告和执行。不要创建重复的 DMARC记录 或替换现有策略作为添加一个应用程序的附带步骤。
通过变革和退休保留授权
移动DNS托管、更改自定义通知地址、转移应用程序、轮换密钥或接收提供商更改记录的指示后重新测试。在正常操作期间保持两个DKIM授权完好无损。为域所有者和应用程序所有者分配验证和事件响应的明确责任。
停用自定义域发送时，首先更改或禁用依赖的应用程序配置，验证没有剩余通知依赖它，然后通过批准的DNS更改删除过时的授权。保留旧值和过渡回滚计划。本指南报告第一方文件调查结果和说明性测试，而不是实时 Atlassian 帐户执行情况。
记录三个切换门
为每个门使用单独的证据字段：生成的记录与权威DNS匹配；配置后域状态为“活动”；目标应用程序可以选择批准的地址。然后保留外部通知结果。如果DNS匹配但状态不是“活动”，请调查配置而不是猜测新记录。如果处于活动状态，但旧的发件人地址仍然存在，请检查地址可用性和应用程序选择。这些是建议的诊断分支，而不是执行的帐户测试。