决定您要更改的温室路线
目录名称 GreenHouse 涵盖了邮件不一定遵循相同路线的产品。本指南的主要程序是温室招聘域验证。记录实际功能、预期发件人域、发送帐户以及是否配置自定义SMTP路由。在进行影响共享公司域的更改之前，请获得DNS管理员的参与。
对于招聘，授权用户在配置 > 开发中心 > 电子邮件设置下注册域并获取生成的记录。 Greenhouse 的标准设置使用 gh-mail 子域。相反，Sourcing Automation 的电子邮件安全说明会将您引导至您的邮箱提供商，以获取 SPF 和 DKIM。请勿将成功的 Recruiting 验证视为连接的 Google 或 Microsoft 邮箱配置正确的证据。 招聘设置 · 采购自动化安全
慎重选择域名形式
检查域名的 DMARC 结盟 注册前的设置。 Greenhouse 记录了一个无 gh-mail 注册选项，在域名前使用感叹号以实现严格对齐的情况。该选项会更改生成的DNS范围，并且如果条目已存在，则需要进行有意的迁移。这不是削弱组织的DMARC政策的理由。 注册和严格对齐选项
在发布之前将生成的所有者和值与现有记录进行比较。保留完整的SPF授权清单和每个所有者一份保单。保持 CNAME 记录没有冲突的数据。不要仅仅因为根域接收邮件而重定向根域 MX记录 请求专用发送子域。如果控制台和计划的DNS范围不一致，请停止并澄清，而不是将子域值移植到顶点。
对于长DKIM值，首先使用DNS主机支持的 TXT 字符串处理。一个 TXT记录 可以包含多个字符串；对一个字符串的限制并不自动需要较弱的密钥。不要截断公钥。如果您的DNS服务无法正确表示其生成的格式，请向提供商寻求帮助。
验证注册域名和实际消息
使用电子邮件设置中的立即检查DNS记录。 Greenhouse 将复选标记描述为已验证状态，将省略号描述为待验证状态。保留结果状态以及准确的记录集和时间戳。 验证常见问题解答
原始验收设计：为候选电子邮件、范围内任何启用的通知路由以及采购自动化消息（如果使用该产品）准备单独的行。仅发送无害的受控消息。记录实际路线，可见From域， 信封发件人、 DKIM d= 和 s= 值，以及可信接收者添加的身份验证结果。 DMARC需要至少一种通过一致的身份验证方法；来自不相关域的签名本身是不够的。
说明性场景：招聘显示已验证，但采购活动因使用招聘人员的连接邮箱而导致DKIM失败。编辑招聘的gh邮件 选择器 不会修复该邮箱。首先比较产品和路线，然后将更正分配给正确的邮件管理员。
维持可逆变化
如果新身份失败，请暂停受影响的发送工作流程，尽可能保持不相关的招聘操作完好无损。在删除受支持迁移的条目之前，保留原始注册详细信息。仅在考虑排队消息和DNS缓存后才恢复上次批准的配置。重新测试域或传输发生更改的每条路由。
本指南反映了 2026 年 11 月 8 日审核的提供商文档。没有访问 Greenhouse 租户、候选数据、 DNS记录或发送的消息。路线矩阵和场景是最初提出的测试，而不是已完成部署的证据。
区分严格一致性和执行级别
书面案例 GH-01 假设来自recruiter@example.com ， SPF通过gh-mail.example.com ， DKIM通过d=gh-mail.example.com和s=mail1.在严格的aspf=s和adkim=s,假设的身份都不完全匹配example.com ，因此都不提供对齐。在宽松模式下，这些子域身份可以对齐。一个 p=reject 仅值不选择严格对齐。在变更注册之前，招募所有者和DNS管理员必须确认真实身份和模式，保留现有记录并商定迁移计划。感叹号注册选项是特定于提供商的；它不是DNS标签。没有发生候选消息、域注册或DNS查找。
保留执行边界
RFC 9989 对于发布p=reject,第 7.4 节要求有效的DKIM而不仅仅是SPF ，并就间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。