定义调查邀请路线
本指南涵盖使用自定义发件人地址通过 QuestionPro 自己的电子邮件服务发送的调查邀请。它不会配置组织单独的SMTP服务，也不会假设每个 QuestionPro 产品共享相同的控件。在更改任何内容之前，记录帐户、产品、调查、预期发件人地址以及负责的域管理员。仅可识别的显示名称并不能说明进行身份验证的域。
QuestionPro 的邀请指南将域身份验证与对个人发件人收件箱的访问区分开来。其自定义地址工作流程是使用发件人地址控件从所选调查的分发区域到达的。验证域名后，还必须添加发件人地址并通过其收件箱确认。将它们视为单独的接受门。 QuestionPro定制邀请函
确定谁可以收到确认以及谁将处理受访者的答复。避免仅仅因为域存在而使用发明的邮箱。如果团队想要一个无人值守的地址，请通过负责的邮件服务建立回复处理，而不是假设 QuestionPro 提供邮箱。保持测试调查不包含受访者的个人数据，并使用授权的接收者进行受控测试。
验证帐户中的第一个域
记录的帐户路径是“用户配置文件”、“我的帐户”、“域身份验证”、“新域”。进入控制域，获取显示 SPF 指令，然后生成 DKIM 钥匙。发布已发布的 选择器 和公共价值并使用验证控制。提供商还需要有效的 DMARC记录。它的指导允许最多六个小时将生成的密钥在其电子邮件服务器上可用，并建议在DNS更改后等待六到十二个小时进行验证。 QuestionPro 域认证
将这些发布的时间间隔视为故障排除指南，而不是对特定DNS缓存或租户的承诺。将密钥生成时间与DNS发布时间分开保存。如果验证立即失败，请首先确定哪个先决条件仍待处理。重复生成新密钥可能会使证据更难协调，因此不要仅仅因为出现短暂的挂起状态而重新生成。
使用为该域发布的公共值。请勿复制其他客户的选择器或密钥，也不要将私人签名材料放入DNS中。选择器和签名域决定接收者从何处检索DKIM公钥。这就是为什么 一个记录 一个有吸引力但不正确的所有者姓名并不能修复实际的签名。 DKIM RFC 6376
QuestionPro SPF页面还会引导读者查看帐户生成的说明。仅将其应用于组织拥有或有权管理的域。公共电子邮件提供商的邮箱不会授予对该提供商的DNS的控制权。 QuestionPro SPF指导
保留现有SPF并接收邮件
编辑前，捕获当前权威 名称服务器, SPF记录, DMARC 策略以及建议选择器处的任何现有DKIM记录。识别使用相同身份发送的其他服务。新的提供商不得取代组织的正常邮箱授权或其他可操作的发件人。
在每个所有者处发布单个SPF策略，并在适当的情况下将授权机制合并到现有策略中。检查合并后的查找限制。 SPF评估SMTP身份；简单地将包含添加到可见的 From 域并不能确定收到的邮件将使用该域进行SPF 。在测试期间使用实际的信封标识。 SPF RFC 7208
发布后检查所有者的完整姓名。当将完全限定名称粘贴到相对名称字段时，附加区域的编辑器可以创建双重域。记录DNS界面中显示的值和公共答案。请勿将修改MX路由作为不相关的故障排除实验。邀请工作流程需要一个可用的发件人收件箱，但对调查服务进行身份验证并不表示迁移所有组织邮件。
处理已被另一个帐户使用的域
当同一域在另一个帐户中进行身份验证时，QuestionPro 会记录不同的分支：完成帐户流程并发布其域所有权记录，而不是假设需要新的SPF和DKIM设置。保留现有的签名记录，直到当前的租户指示确定所需内容。 QuestionPro 域认证
使用原始设置所有者、其他帐户所有者、现有公共记录和任何新的所有权证明创建帐户到域注册。第二个帐户的请求不应成为第一个帐户的意外密钥轮换。准确记录哪个帐户显示已验证状态以及哪些消息路由已经过测试。 “域已在某处验证”不足以接受新发送帐户的证据。
当前第一方材料中存在文档冲突：域身份验证页面和自定义邀请页面列出了相同许可证系列的不同域配额。本指南特意承诺没有数量配额。在规划其他域之前，请在实际帐户中或使用 QuestionPro 确认当前权利。这种冲突并不能证明发明缺失的控件或使用未经授权的帐户解决方法是合理的。 QuestionPro 域认证 QuestionPro定制邀请函
验证所选邀请而不是徽章
验证域和收件箱后，选择实际邀请中的预期发件人地址并发送受控测试。确认邮件的发件人和回复值、信封域、 DKIM d= 和 s= 值以及接收者的信任 Authentication-Results。如果提醒是部署的一部分，请单独测试提醒。将帐户和调查标识符与证据一起保存，以便结果不会意外归因于另一个工作区。
DMARC需要与可见的 From 域一致的传递机制。对齐的SPF或对齐的DKIM都可以提供通行证。保留实际情况 结盟 模式和策略范围，而不是假设提供者徽章证明所有接收者结果。域记录、验证状态和接收到的认证结果是不同类型的证据。 DMARC RFC 9989
QuestionPro 通过所选调查的分发区域、电子邮件、已发送和未送达计数来记录送达调查。它要求支持案例建立联系收件人的权限以及SPF 、 DKIM和DMARC的状态。将特定的失败信息与身份验证证据一起使用，而不是为每次退回更改DNS 。 QuestionPro 交付故障排除
收件人不存在、帐户限制或参与度不佳需要与丢失的DKIM密钥不同的响应。不要声称通过身份验证就可以保证收件箱。将同意和清单质量检查作为单独的运营责任。
QuestionPro 验收工作表
为每个发送帐户和域完成此建议记录。以下任何字段均不代表客户测试结果。
- 范围：在不依赖冲突配额、调查、发件人所有者和递送服务的情况下确认的帐户、产品、许可证权利。
- 域分支：首次身份验证或附加帐户所有权证明、原始设置所有者和现有依赖项。
- DNS ：发布的SPF指令、选择器和公钥、所有权记录（如果适用）、权威答案、TTL 和时间戳。
- 提供商计时：密钥生成时间、 DNS发布时间、验证尝试、确切状态和未解析的消息。
- 发件人地址：确认收件箱、选择发件人、回复收件人、回复处理所有者和验证完成。
- 收到的证据：邀请或提醒、接收者、信封域、 DKIM域和选择器、身份验证结果和对齐。
- 决策：剩余帐户或产品、回滚计划、配额澄清、人工审核员和批准状态。
第二账户回归的虚构诊断
这个例子是虚构的。为一个部门添加第二个研究帐户。管理员假设现有域必须从头开始进行身份验证，并建议替换其工作DKIM记录。原团队的活动仍然活跃。
更安全的调查可以识别附加帐户所有权分支，将租户发出的指令与现有记录进行比较，并保留工作签名密钥。然后，两个帐户都需要单独的受控邀请测试。如果当前接口与记录的分支不同，则更改将保留以供提供商澄清，而不是强制使用旧指令。这是一个说明性的决策路径，而不是已完成的租户变更。
证据和审查门
真实帐户资格、生成的值、域所有权、 DNS响应、密钥准备情况、收件箱确认和接收消息对齐尚未经过测试。冲突的域配额是特定产品范围的保留。人类 SME 审查、视觉审查和出版批准正在等待中。保持候选人不发布，并保留特定于客户的工作表以供以后验证。
保持第二账户决策可逆
在更改新研究帐户的共享域之前，请记录原始帐户所有者和候选记录名称。如果新指令与工作选择器重叠，请停下来询问这是所有权证明还是签名密钥更改。该虚构示例没有建立实际的选择器、成功的活动或已完成的迁移。维持现有路线，直到就预期的更改和回滚达成一致。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989 第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。