确定前往炼金术士调查的路线
本指南涵盖使用记录的自定义电子邮件集成的 Alchemer 调查电子邮件操作和电子邮件营销活动。它不会将相同的设置应用于每个 Alchemer 产品、报告通知或导出。所保留的 设置DKIM和SPF记录指南 区分通过具有自定义域的 Alchemer 服务器发送与通过单独的SMTP集成发送。在准备DNS更改之前确定实际操作或活动使用的路由。
消息人士称，自定义集成可用于发送电子邮件操作和电子邮件营销活动，不适用于通过电子邮件发送报告或导出。它还说只有SMTP和 DKIM/ SPF集成路由可用于给定的操作或活动。这些范围限制至关重要：正确的集成可以存在，而无需被所调查的工作流程使用。这项工作中没有访问 Alchemer 帐户，也没有创建任何集成。
确认所有者和先决条件
该指南需要 Alchemer 帐户管理员来设置并与域管理员或 IT 团队协调以进行DNS发布。在收集配置值之前，记录业务工作流程、集成所有者、预期来自域和DNS所有者。不应假定可以编辑调查的用户有权为组织的域授权外部发送服务。
该指南描述了有效的 MX记录 作为此 Alchemer 设置的先决条件，并指出丢失MX数据可能会阻止保存或生成公钥。将其视为记录的产品要求，而不是通用声明 SPF 每个发件人本身都需要MX 。 RFC 7208 定义SPF单独的 SMTP 身份和评估规则。保持产品验证条件与协议要求不同。
选择记录的 Alchemer 服务器配置
保留的指南将授权管理员引导至“集成”、“数据连接器”，然后转到“自定义电子邮件设置”旁边的“配置”。它要求提供一个有意义的集成名称，并为新电子邮件邀请和操作提供默认值。 The Alchemer-server route is selected with the option to send emails using Alchemer's servers and set up SPF and DKIM . These are documented instructions, not a report that the current tenant displays or has completed them.
该配置采用域名和默认发件人地址。该指南解释说，可以在操作或活动中调整发件人地址的本地部分，但无法更改配置的域。记录实际的预期域，而不是假设有吸引力的发件人显示名称控制身份验证。新工作流程的默认设置不应被视为每个现有营销活动都使用该集成的证据。
从集成中获取准确的DNS值
该指南在集成中提供了SPF条目，并指导管理员生成DKIM公钥信息。必须保留实际授权设置中生成的DNS域名和DNS公钥。尽管文档说明了 选择器，本手稿没有发布特定于租户的密钥，也没有假设复制的示例数据适合真实帐户。 DNS审核不需要私人签名材料。
在合并提供的条目之前，请检查现有的SPF策略。提供商的说明不应被解释为允许在已有 SPF 策略的所有者处创建第二个SPF策略。 RFC 7208要求选择一个 SPF记录 并定义多个SPF记录的错误。准备一个完整的预期差异，保留其他批准的发件人，并检查评估的 DNS 查询项预算，而不是仅计算新的可见条目。
保留DKIM记录结构
Alchemer 指南警告说， DNS编辑器处理周围引号和拆分为字符串的长公钥的方式有所不同，并且额外的引号可能会使记录无效。 RFC 1035 将TXT RDATA 定义为一个或多个字符串。一条记录中的多个字符串不是多个DKIM策略。操作员应该将发布的字节与生成的公共值进行比较，而不是仅仅依赖于编辑器屏幕截图。
在建议的更改中记录确切的所有者、记录类型、值、TTL 和受影响的区域。不要仅仅因为此集成中未提及而覆盖不相关的选择器或删除现有的身份验证记录。最终的公共DNS状态需要在发布后进行授权观察。 No DNS lookup or write was performed for this manuscript.
区分保存、验证和实际活动使用
该指南称，Alchemer 在保存集成时尝试通过向其中一台服务器发送测试电子邮件并检查标头进行验证。它还表示集成必须在使用前进行验证，并在“已验证”列中标识出绿色复选标记。因此，保存具有记录的消息发送副作用，而不仅仅是本地表单更新。授权操作员在执行该行为之前必须了解该行为；这项工作没有保存或触发验证。
一个特别重要的例外是电子邮件营销活动测试链接。消息来源指出，该链接不使用DKIM / SPF信息，来自 Alchemer。它指导用户使用实时活动来测试该自定义路线。本稿件不发送此类活动或授权收件人联系。在执行任何后续测试之前，验收计划必须确定已批准的接收者和确切的类似生产路线。
建立接收消息身份表
对于授权样本，保留操作或活动标识符、所选集成、发送时间和可信接收系统。记录可见的发件人域、信封身份、 DKIM签名域、选择器、 SPF结果、 DKIM结果和 DMARC 结盟 结果。 RFC 8601 解释原因 Authentication-Results 需要一个可信的接收者边界；没有出处的复制合格线是不够的。
RFC 9989 定义与可见 From 域的对齐。成功的SPF或DKIM结果仅在其实际身份上下文中才有用。提供商的已验证状态和真实的收到消息表回答了不同的问题，都应该保留。既不能保证收件箱的放置，也不能验证消息背后的人为意图。
集成验收工作表
创建一个工作表，其中包含 Alchemer 调查范围、操作或活动、选定的路线、集成名称、预期发件人域、帐户所有者、 DNS所有者以及确切生成的公共记录。添加现有状态证据、批准的差异、提供商验证状态和接收消息表。包括一项具体检查，以确保样本不是来自排除的测试链接路径或来自报告/导出通知。
如果验证失败，请单独排除缺少MX先决条件、 DNS发布不匹配、密钥格式、缓存答案和错误的集成选择。不要在没有保留支持证据的情况下从一种红色状态推断原因。该指南的传播指南描述了可能的延迟，而不是允许将未观察到的记录标记为正确。记录实际观察时间并仅在授权的操作计划下重试。
虚构的诊断：测试链接给出了错误的身份
虚构的调查管理员配置自定义集成，然后使用活动测试链接并查看 Alchemer 拥有的发件人身份。管理员假设DKIM设置失败。记录的路由异常提供了不同的解释：该测试路径不使用自定义DKIM / SPF集成。下一步是在更改DNS或生成另一个密钥之前确认路由。
来自预期活动的授权后续样本将单独评估。这个例子是虚构的；未观察到任何活动、密钥、 DNS记录或收到的消息。它说明了特定于产品的诊断区别，而不是完整的配置。
发布状态
该目录需要当前的第一方设置证据以及来自确切产品和路线的接收消息身份表。保留文件设置证据，但租户适用性和原始接收消息表保持开放。所有六个释放门均保持打开状态。该草案并不声称 Alchemer 已被配置或测试，也未发生任何发送、凭证生成或发布。