使用当前的服务台路线
此商品使用名称 Samanage。此处的实施过程仅限于当前 SolarWinds Service Desk 电子邮件设置，其记录的基础架构仍使用samanage.com名称。不要将其与旧的 Samanage 屏幕截图结合起来，也不要假设迁移时代的清单描述了当前帐户。在进行更改之前记录服务、数据中心、帐户类型和负责的管理员。
当前的第一方导航因帐户组织而异。 ITSM 使用“设置”>“帐户”>“电子邮件设置”。 ESM 具有围绕这些设置的组织或服务提供商上下文。记录您正在查看的上下文，以便为一个服务提供商配置的域不会假定覆盖每个服务提供商。 SolarWinds 服务台电子邮件设置
识别可靠性重要的消息：代理回复、与任务相关的消息、自动事件通知以及任何不同的面向客户的路线。还记录传入票据地址和转发规则。出站身份验证和入站事件创建是不同的流程；改变一个不能默默地破坏另一个。
了解依赖于身份验证的控制
当前指南将域身份验证记录为个性化电子邮件地址和自定义回复电子邮件地址的先决条件。它将个性化名称与个性化地址区分开来。自动通知不会像源自用户操作的消息那样受到影响。因此，测试实际的消息类别，而不是假设代理的个性化显示名称描述了每个发件人。 SolarWinds 服务台电子邮件设置
构建代理地址域和自动通知使用的固定身份的列表。帮助台可能包含来自子公司或承包商的代理，其电子邮件域具有不同的所有者。不要仅仅因为一个代理拥有该地址就授权该域名。确认该组织有权作为身份发送并且可以完成提供商的验证过程。
将回复目标视为功能依赖。支持地址可以将收到的邮件转发到服务台投递箱。经过验证的传出发件人并不能证明转发规则有效或回复已附加到预期事件。包括对指定事件进行无害回复测试，并确保它不会通知真正受影响的用户。
发布生成的三记录配置
当前记录的工作流程是电子邮件设置 > 电子邮件身份验证 > 添加自定义域。添加批准的域，展开其DNS设置，然后复制生成的三个 CNAME 记录。将它们发布到权威DNS中，返回帐户，并使用验证。预期成功状态为“已验证”。 SolarWinds 服务台电子邮件设置
使用实时生成的所有者和目标，而不是捏造的选择器或 一个记录 由另一位客户设置。对于每个条目，保留确切的公共值、关联的域、TTL 和更改引用。在进行更改之前，请DNS管理员检查同一所有者处预先存在的数据。冲突是调查配置的原因，而不是删除不相关密钥的权限。
检查DNS控制台如何处理相对名称和完整名称。成功的保存仍然可能创建错误的所有者或目标。查询预期的公共名称并根据需要遵循其CNAME解析。记录实际发表的内容和观察的时间。提供商验证和独立DNS证据应描述相同的记录集。
如果验证失败，请将这些结果与当前帐户生成的值进行比较。确认编辑后的DNS服务具有权威性，并且缓存有适当的过期机会。在不了解现有状态的情况下，请勿重复添加域或覆盖记录。如果提供商无法识别正确发布的记录，请保留确切的错误并让服务所有者参与其中。
分别处理SPF和本地接收控制
SolarWinds 文档include:_spf.samanage.com SPF 例子。根据实际包络路线和组织的现有授权检查其使用情况。请勿替换组织的整个政策或创建多个适用的政策 SPF记录。考虑嵌套DNS评估并保留已使用该所有者的合法发件人。 SolarWinds 服务台电子邮件设置 SPF RFC 7208
提供商还列出了特定于数据中心的接收许可列表。这些控制涉及您自己的邮件系统的接受程度；他们不会为外部收件人创建传递对齐的签名。与安全团队一起保留任何提议的许可名单更改，并在使用前验证当前的区域值。不要应用每个区域的地址或广泛的 URL 例外作为自动身份验证修复。
特别是，即使本地安全产品的身份验证错误，也可能会因异常而传递消息。保留底层身份验证结果，而不仅仅是收件箱位置。对安全链接、垃圾邮件过滤或附件访问的更改可能会产生更广泛的安全影响，并且需要进行自己的审查。本指南不规定绕过这些控制以使测试看起来成功。
不要重复使用 2025 年迁移计划
SolarWinds 的迁移通知描述了第二阶段的过渡日期为 2025 年 3 月 16 日。它解释了为什么未经身份验证的帐户可能会丢失自定义回复行为或保留个性化名称而无需个性化地址。使用该通知作为历史诊断上下文，而不是作为当前截止日期或特定租户完成迁移的证据。 SolarWinds 电子邮件服务迁移通知
如果长期帐户的回复地址意外更改，请将当前设置与记录的早期配置进行比较。身份验证状态可能相关，但不要认为这是唯一的原因。询问所有者是否重组了帐户、添加了服务提供商或更改了代理身份。在恢复任何内容之前记录实际的当前路线。
仅在确定没有活动帐户后才应删除旧的DNS记录， 选择器，或者消息路由取决于它们。迁移通知的存在时间不足以识别安全删除。将清理工作与获取经过验证、工作的发件人的直接任务分开。
验证代理消息和自动通知
创建授权测试事件并执行范围内的用户操作和自动通知路径。在受信任的接收者处捕获原始消息。分别记录可见的发件人地址和显示名称、回复、信封身份、所有 DKIM 签名域和选择器以及可信的身份验证结果。包括生成消息的服务提供商上下文和事件。
从收到的消息中读取DKIM d= 和 s=，并将它们与已发布的配置进行比较。选择器的存在仅证明记录可用；该消息实际上必须使用有效的签名。如果接收者看到多个相关签名，请保留所有相关签名。 DKIM RFC 6376
DMARC 需要可见 From 域的传递对齐身份验证路径。回复名称和显示名称不能替代该身份。提供商信封域的SPF通行证可以与缺乏SPF共存 结盟，而对齐的DKIM仍可能满足DMARC 。评估有效政策下的实际信息。 DMARC RFC 9989
如果一类通过而另一类失败，请在更改共享DNS之前比较发件人身份。用户操作消息可以使用代理地址，而自动通知则遵循不同的身份。如果邮件根本没有发送，请首先检查通知事件和可用的送达证据。身份验证记录无法修复缺失的触发器或故意抑制的目标。
误导性显示名称的虚构示例
仅虚构的书面案例：SW-01 假设用户操作消息显示 Alex Support，但其实际发件人仍然是提供商服务地址。回复是help@example.org ；确切的提供商地址、 DKIM和SPF结果未知。管理员应区分个性化名称和经过身份验证的个性化地址，然后分别测试代理操作、自动通知和回复事件路由。请勿更改接收许可名单来替代此证据。未检查任何服务帐户、事件或消息。
实施工作表和发布限制
- 帐户上下文：服务台产品、数据中心、ITSM 或 ESM、组织或服务提供商以及所有者。
- 身份清单：代理域、自动通知发件人值、显示名称设置和回复地址。
- DNS ：所有三个生成的 CNAME、现有数据、确切的发布名称、TTL、查找时间和已验证状态。
- 政策： SPF所有者和授权机制，有效的DMARC政策，以及单独批准的本地接收例外。
- 测试：事件参考、触发操作、接收者、发件人、回复、信封标识、 DKIM d=/s=值和对齐结果。
- 恢复：先前支持的设置、转发依赖项、通知暂停所有者和清理审核。
尚未检查真实帐户配置、迁移状态、 DNS 、收到的标头和屏幕截图。目视审查、人类 SME 批准和发布仍在等待中。该未发布的候选方案涵盖了当前记录的服务台路线；遗留配置和未经测试的服务提供商上下文仍处于搁置状态。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。