确定哪些地点和通知需要测试
丢失的预订电子邮件可能源于日记设置、不正确的发件人地址或收件人决定。将这些视为不同的调查。在更改身份验证记录之前，记录受影响预订的地点、区域、通知类型、预期发件人地址以及受影响的预订时间。对于餐厅集团，为每个场所维护单独的证据，而不是假设中心域为每个日记提供相同的配置。
ResDiary 的 2026 年 1 月 SPF 指南称其电子邮件使用SendGrid并将spf.resdiary.com标识为其已发布的发送授权。这是 ResDiary 支持的指令，而不是创建您自己的SendGrid帐户或从其他SendGrid客户借用DNS值的理由。 ResDiary SPF配置
此处查看的当前公共源并未建立 ResDiary 特定的自定义 DKIM 配置过程或受支持的自定义信封配置。这是源范围保留，并不能证明这两种能力不存在。在描述一个完整的之前 DMARC 实施准备就绪，获取提供商对确切地点的确认并检查收到的消息。不要发明选择器、记录目标或隐藏的身份验证菜单。
确保确实正在生成消息
ResDiary 记录了“设置”>“区域”下的区域级通知控制，并识别了提醒和餐后消息的单独通知设置。其发件人地址说明使用场地联系详细信息下的“设置”>“场地”和“Dish Cult 列表详细信息”。检查预期设置，而不将帐户登录详细信息视为电子邮件发件人身份。 ResDiary 通知故障排除
让场地所有者批准测试安排。预订会影响容量、人员准备和自动跟进，因此请使用指定的测试程序并通过正常操作流程清理预订。使用授权的测试邮箱和无害的详细信息。避免使用真实用餐者的预订作为身份验证实验或触发对客户的意外提醒。
运行正在调查的特定通知。检查是否已启用、预订是否符合条件、目的地地址是否正确。记录发送时间以及任何可用的消息或事件参考。如果未生成消息，请先解决该情况，然后再将DNS编辑解释为修复。如果生成了邮件，则将拒绝、隔离、垃圾邮件文件夹放置和未收到邮件分开，并且没有可用的解释。
选择场地控制的域上的发件人地址以及工作人员实际监控的回复目的地。 ResDiary 建议使用私有域而不是使用个人邮箱提供商地址来发送自动消息。更改为拥有的地址只是开始：它仍然需要适当的身份验证和真实消息检查。 ResDiary 通知故障排除
根据实际路由准备SPF更改
提供商的记录机制include:spf.resdiary.com.其指南解释了将其合并到现有政策中。请勿更换场地完整 SPF记录 以单一提供商为例，因为员工邮件、网站表格和其他合法应用程序可能已经依赖于它。 ResDiary SPF配置
要求DNS管理员捕获当前策略并识别正在评估的信封域。使用DNS主机的当前控制在预期所有者处发布。保留现有的授权发件人并评估生成的查找预算。 SPF不是对显示名称或回复地址的检查；一个所有者拥有多个适用的SPF记录也是一种错误，而不是添加服务的一种方法。 SPF RFC 7208
将建议值和之前的值保存在变更单中。记录权威 名称服务器、发布时间、TTL 和独立查找时间。确认DNS编辑器未两次附加域。请勿将接收邮件记录或不相关的SendGrid品牌记录复制到此更改中。 ResDiary SPF文章并未确立这些操作。
如果接收方显示服务拥有的信封域的SPF通行证，则在可见的发件人域中添加另一个授权可能不会更改该结果。首先确定接收者评估的域。这种区别可以防止重复的DNS编辑导致实际消息身份不变。请 ResDiary 澄清支持的信封行为，而不是仅根据 IP 地址进行猜测。
缩小DKIM和一致性证据差距
将批准的预订确认发送到可以检查完整标题的邮箱。维护接收者的信任 Authentication-Results，可见 From 域、信封域和每个 DKIM签名'sd= 和 s= 值。这些签名字段标识签名域和 选择器。妥善保管原始证据；在例行审查笔记中使用经过编辑的副本。 DKIM RFC 6376
将传递的域与适用的域下的可见域进行比较 结盟 模式。 DMARC需要至少一条通过的对齐路径；不相关域的两个传递结果不提供它。使用 RFC 9989 用于协议评估，而不是从仪表板中的供应商名称推断成功。 DMARC RFC 9989
如果两条路径均不一致，请要求提供商确认该场所的路由是否支持客户域签名。请求准确的DNS记录、激活步骤和预期的签名身份（如果有）。如果不是，请询问哪种受支持的发件人安排可以保留递送并准确代表地点。记录答案，而不将其推广到其他 ResDiary 产品或未来版本。
重复检查场所使用的提醒和餐后消息。确认测试无法关闭未经测试的提醒路线。不承诺身份验证成功后收件箱的放置，也不减少组织的 DMARC执行 只是为了绕过未解决的场地配置。
虚构诊断： SPF记录不是第一个问题
在一个虚构的场所，一位经理报告说确认有效，但提醒从未到达。第一个建议是添加另一个SPF记录。相反，受控审查会发现已测试工作流程禁用了提醒。所有者启用预期行为后，新测试会生成一条消息。然后可以评估其标头以进行身份验证。此场景是虚构的，并非 ResDiary 客户发现的结果。
假设该消息在不相关的提供商域下也有一个传递签名，没有对齐的SPF路径。现在有两个不同的发现：工作流程设置解释了为什么先前的消息不存在，而收到的消息则标识了一个单独的对齐问题。调查人员保留这两项发现，并要求提供受支持的域身份验证说明，而不是声明提醒切换是完整的安全修复。
场地实施工作表
- 操作范围：场地、区域、通知类型、企业主、批准的测试程序。
- 发件人配置：可见地址、回复处理、域所有者和设置检查日期。
- 生成证据：已启用的工作流程、测试预订参考、发送时间、目的地和观察到的结果。
- DNS更改：现有SPF 、建议的合并策略、权威查找、TTL 和回滚值。
- 消息证据：来自域、信封域、所有 DKIM d=/s= pairs, trusted results, and alignment conclusion.
- 提供商说明：自定义 DKIM 和信封支持、帐户特定记录、激活证据和未解决的问题。
- 关闭：确认和提醒重新测试、预订清理、审核者和下一次审核触发。
保留工作表与场地的变更历史记录。当发件人域、组所有权、预订工作流程或提供商说明发生变化时，请重新访问它。仅在检查另一个活动场所不再依赖于过时的授权后才撤回过时的授权。
发布状态
该手稿具有场地控制和SPF指导的第一方证据，但没有完整的自定义域签名程序。租户检查、实时DNS 、接收消息验证、目视审查、SME 人工批准和发布仍在等待中。特定于产品的签名保留必须在最终范围内明确解决或保留。
合并SPF时保留执行决定
检查实际SMTP身份后，在单个适用的TXT策略中使用提供程序机制。示例softfail结束并不是允许削弱现有策略。将DNS所有者的决定和未解决的自定义签名问题与是否启用预订通知分开。
将消息接受与策略推出分开
通过的对齐SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。