確定哪些地點和通知需要測試
遺失的預訂電子郵件可能源自於日記設定、不正確的寄件者地址或收件人決定。將這些視為不同的調查。在更改身分驗證記錄之前，記錄受影響預訂的地點、區域、通知類型、預期寄件者地址以及受影響的預訂時間。對於餐廳集團，為每個場所維護單獨的證據，而不是假設中心域為每個日記提供相同的配置。
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變更、租用戶操作或接收訊息測試。