從通知而不是品牌名稱開始
當使用不同的寄件者設定或傳送路線時，員工提醒和候選人電子郵件可能看起來來自同一組織。從企業需要傳遞的通知開始。記錄其 SuccessFactors 模組、公司 ID、資料中心、配置的寄件者地址和任何客戶中繼。每當這些邊界之一發生變化時，請新增一個單獨的庫存行。本指南涉及 SAP 公共支援文件中所述的 SuccessFactors HCM 通知路徑，而不是每個帶有 SAP 名稱的產品。
目標是收到的訊息，保留預期的可見身份並具有一致的身份驗證通行證。出版 一個記錄 是一個中間步驟。如果組織的網關對 SAP 流量有特殊例外，則成功的內部交付也可能會產生誤導。將內部驗收測試和外部認證測試分開。
一起準備支援請求和DNS更改
在 SAP KBA 2688533，“如何請求/啟用DKIM或SPF實施？”, SAP 指導 DKIM 請求使用公司 ID、資料中心和完整的網域清單來元件 LOD-SF-PLT-NOT。它的註釋使配置僅限於資料中心範圍，並且在添加金鑰後允許最多 48 小時。同樣的 KBA 列出了 A， SPF SAP 服務的MX先決條件。將這些視為提供者要求，而不是DKIM的通用定義。
如果這些職責是分開的，則將一個人指派給 SAP 案例，將另一人指派給權威DNS區域。移交應包含確切的網域、請求的簽章身分、 DNS擁有者、記錄類型、公共值、TTL 和商定的啟動期望。將私鑰和憑證保留在工作表之外。不要推斷 選擇器 來自另一個 SAP 實施或舊螢幕截圖。
在編輯DNS之前，匯出目前記錄並確定誰擁有建議的DKIM名稱的任何現有記錄。選擇器衝突是停止條件，而不是允許覆蓋活動服務。請SAP解決。如果DNS表單自動新增網域後綴，請以產生所需完全限定名稱的格式輸入擁有者，然後驗證發佈的結果。
選擇目前資料中心SPF條目
使用 SAP KBA 2087468、“ SPF ”和“SuccessFactors DC SPF條目”，而不是從其他帳戶複製的通用清單。 SAP 針對大型全資料中心應用程式發出警告。它的表還標識了遷移資料中心的替換條目，因此歷史上正確的包含不足以建立當今的配置。在選擇條目之前，請與租用戶擁有者確認實際託管位置。
將配置的可見寄件者保留在清單中。同一 KBA 討論了單一發送方和特定於模組的位址，但向使用者顯示的位址不會告訴您接收伺服器評估哪個網域的SPF 。 RFC 7208 ，第 2.3 節 指定 郵件來自 身份。在決定SPF通行證證明什麼之前，從受控接收的訊息或相關傳遞證據中獲取它。
僅將所需的授權合併到適當所有者的現有策略中。保留其他合法寄件者。請勿建立第二個SPF策略、未經審查就替換組織目前的結束限定符，或複製省略現有服務的範例。 RFC 7208的第 4.5 和 4.6.4 節涵蓋了記錄選擇以及 DNS 查詢機制和修飾符的十個術語限制。計算嵌套查找的數量，而不僅僅是頂級字串中可見包含的數量。
有用的變更記錄是政策前後及其評估審查。它應該解釋為什麼每個新的 SAP 授權都是必要的，以及什麼事件會觸發其刪除。資料中心遷移值得重新檢查，而不是不斷增長的新舊條目清單。
將客戶中繼視為不同的路線
如果您的租用戶使用客戶中繼，請要求郵件擁有者繪製完整路徑，包括任何最終出站閘道。 SAP KBA 的「透過客戶的郵件伺服器中繼郵件」部分描述了另一種安排。其目前的限制並不是隨便引入繼電器的理由。在提出路由變更建議之前，請先與 SAP 和接收郵件團隊確認支援的設定和投遞責任。
中繼可以更改發送 IP、信封身分、 DKIM簽名集以及內容修改點。透過 SAP 預設路由傳送的測試無法驗證中繼的生產路徑。同樣，在路由早期建立的簽章可能無法在以後的變更中保留下來。記錄預計哪個服務提供最終一致的身份驗證結果。
請勿將中繼憑證放入票證附件或公用DNS記錄中。當授權單獨的中繼設定時，使用組織核准的憑證流程和 SAP 指定的安全通道。本指南不會配置憑證、更改路由或斷言通用自訂 Return-Path 控制存在。
發布並驗證已發布的公開記錄
將即時權威答案與為請求提供的記錄進行比較。確認所有者不重複、存在完整的公鑰且記錄類型正確。當快取的答案不一致時，檢查多個解析器的結果，並保留觀察時間。顯示「已儲存」的DNS控制台並不是接收者使用的證據。
要求 SAP 確認列出的網域和資料中心的啟動。記錄案例參考和激活時間，不以 48 小時的過去作為證據。如果新測試缺少預期的簽名，請先檢查它是否是在啟動後產生的並且來自預期的路由。重複的金鑰重新產生可能會產生額外的不確定性，而原始路由問題仍未解決。
RFC 6376 ，第 3.5 節 定義用於尋找驗證金鑰的簽章網域和選擇器欄位。捕獲最終訊息中的每個DKIM d= 和 s= 對。提供者網域簽章在技術上可能有效，但無法與您選擇的寄件者網域保持一致。
測試每個有意義的通知路徑
使用無害的內容並控制收件人。避免真實的候選人詳細資料、員工記錄、申請附件或整個生產範圍的公告。如果業務需要多種通知類型，請選擇代表性的訊息，而不是假設一次成功即可涵蓋所有類型。保留訊息標識符和 UTC 發送時間，以便可以透過 SAP 和接收系統追蹤相同傳遞。
對於每封郵件，記錄可見的寄件者域、接收者報告的信封身分、所有DKIM身分、 SPF結果、 DKIM結果和 DMARC 結果。使用最終接收者的信任 Authentication-Results，而不是訊息中攜帶的任意類似命名的標頭。記錄政策並 結盟 接收器評估的模式。
RFC 9989 ，第 4.4 節，“標識符對齊解釋” 需要DMARC的一致性通過SPF或DKIM結果。工作表應確定提供該通行證的機制。 「已交付」、「已使用TLS 」和「SAP 出現在我們的許可名單上」是不同的觀察結果，不應佔用DMARC證據欄位。
If SPF passes under an unrelated envelope domain, adding more SPF authorizations to the visible From domain will not make that particular pass aligned. Investigate the intended DKIM identity and supported route instead. If DKIM fails, distinguish missing key, mismatched selector, malformed public record and post-signing modification before changing policy.
使用路線驗收工作表
Create a separate review record for the SuccessFactors domain-and-datacenter worksheet using the fields below. Complete one copy per meaningful sending route. It includes the SAP case, issued DNS record, datacenter authorization, activation confirmation, receiver identities, alignment decision and recovery owner. Leave unobserved fields blank and mark the next action rather than substituting a sample value.
接受記錄應回答三個問題：SAP 是否啟動了預期身分、公共DNS是否支援它以及接收者是否驗證了來自該確切路由的訊息？三者皆需。記錄外部測試和組織內部網關的單獨結果，以便旁路不會隱藏差異。
虛構的例子：錯誤的資料中心假設
Fictional written case only: SF-01 assumes intended From hiring@careers.example, but the first notification uses a provider From whose exact address is unknown. DKIM, selector and envelope/SPF results are unknown. An old datacenter request is not evidence for the current tenant. The HR systems owner must confirm the current datacenter and notification sender, obtain activation for that route, then inspect a new harmless external message. No DMARC verdict is inferred and no tenant, DNS or message was tested.
在不擴大故障範圍的情況下恢復
當關鍵業務測試失敗時，暫停受影響的通知更改，並使用先前批准的傳遞路徑（如果存在）。與 SAP 和郵件所有者協調任何逆轉。當新發送或排隊的訊息可能仍需要公鑰時，請勿刪除公鑰，並且不要僅僅為了使一條路由看起來成功而削弱整個組織的DMARC策略。
Retest after datacenter migration, sender-domain changes, relay changes and notification-routing changes. This remains an unpublished implementation draft: live tenant review, account-issued records, DNS observations, received-message identity evidence, visual review and human SME approval are pending. Preserve those as acceptance gates rather than silently treating the documentary research as a completed deployment.
來源可用性和實施確認
這兩個 SAP 知識庫頁面在保留的 2026 年 11 月 8 日來源快照中以公開文字擷取。在此審核期間，最初的開啟再次確定了公共解決方案內容，但稍後的部分開啟返回了需要登入的預覽。因此，上述詳細說明依賴於保存的主要來源副本，而不是聲稱整頁仍然可供公眾閱讀。在進行變更之前，請先與 SAP 確認目前的資料中心條目、服務先決條件和啟動工作流程。未嘗試登入或繞過存取。
將傳遞的訊息與執行準備分開
RFC 9989 第 7.4 節要求有效的DKIM才能進行網域發布 p=reject 並對間接郵件互通性提出警告。單一對齊的SPF結果本身並不能證明拒絕策略的推出是合理的。與此提供者設定分開審查所有合法路由和策略所有權。