將帳戶參與與其他Salesforce電子郵件產品分開
Salesforce Account Engagement 有自己的網域管理工作流程。首先確認訊息是透過 Account Engagement（以前稱為 Pardot）發送的，而不是核心Salesforce電子郵件或 Marketing Cloud Engagement。另一個Salesforce產品的DNS配方可以使用不同的控件，並且不應僅僅因為組織使用相同的供應商而導入。本指南涵蓋帳戶參與發送網域驗證、 DKIM 以及可選的支援輔助自訂返迴路徑。
列出帳戶使用的每個業務部門、品牌和預期寄件者網域。包括由活動和自動化設定選擇的實際寄件者。不會為每個帳戶參與路由自動設定使用者信箱位址中顯示的網域。指定行銷擁有者和DNS管理員在更改共享網域的記錄之前一起檢查清單。
接受目標是具有一致的通過身份驗證機制的受控接收訊息。網域名稱所有權驗證、 DNS發布和綠色管理狀態是有用的中間證據。沒有一個單獨的證據可以證明特定活動使用了預期的身份或接收伺服器接受了其身份驗證。
在編輯根DNS之前了解預設SPF路徑
Salesforce's 帳戶參與DNS指導 表示帳戶參與郵件透過 SPF 透過其受控的發送基礎設施，並且不需要客戶針對預設設定更改SPF 。不要僅僅因為產品名稱出現在組織的根域中就添加通用Salesforce SPF包含 DMARC 報告。首先確認實際路線並評估身份。
SPF驗證SMTP 郵件來自 身份，單獨處理 HELO， 在下面 RFC 7208。其結果不同於 結盟 與可見的From。成功的提供者域SPF檢查可以與未對齊的SPF共存。變更不同網域的政策不會變更郵件使用的信封網域。
保留組織其他服務所需的SPF策略。如果單獨授權的自訂設定需要變更政策，請查看該擁有者的完整策略，包括巢狀的 DNS 查詢術語和協定查找限制。不要創建第二個 SPF記錄 或刪除不相關的寄件者以便為未經驗證的要求騰出空間。
將所有權和DKIM驗證為單獨的記錄
使用網域管理來識別預期的電子郵件傳送網域及其預期的DNS項目。這 DNS指導 區分網域的驗證金鑰和網域金鑰。驗證值建立發送的所有權； DKIM值支援訊息簽章。在工作表中保留這兩個目的，而不是處理任何 TXT記錄 包含Salesforce值作為可互換的證據。
從實際帳戶複製值。在進行DNS變更之前，請儲存完整的記錄擁有者、類型、值和說明日期。檢查另一個帳戶參與帳戶或不同的服務是否已依賴相同所有者。不要覆蓋衝突的記錄、重複使用其他客戶的值或更改 選擇器 一個發明的名字。當帳戶安排發生衝突時，請求支援人員提供支援的解決方案。
保持電子郵件傳送網域與追蹤器網域不同。 Salesforce明確警告不要對這兩個功能使用相同的網域。品牌追蹤主機名稱與寄件者域不同，即使兩者共享父域也是如此。單獨追蹤庫存依賴性，以便身份驗證工作不會無意中更改資產 URL 或活動連結。
透過記錄的工作流程發布 DomainKey
Salesforce's DKIM實施說明 需要帳號參與管理員角色。在 Lightning 應用程式中，開啟帳戶參與設置，然後開啟網域管理。在備用帳戶參與介面中，記錄的起點是管理員。在電子郵件傳送網域下，開啟所選網域的預期DNS條目並複製 DomainKey 值以作為TXT發布。
使用該帳戶和網域顯示的擁有者和值。目前的文章說添加記錄後最多允許 24 小時簽名生效。將其視為提供者計時指南，而不是保證每個DNS快取或接收器都會在同一時刻更新。記錄發佈時間並等待預期狀態，然後再判斷新的測試。
確認公共DNS答案，包括確切的完全合格所有者。 DNS編輯器有時會將區域名稱附加到主機字段，從而在輸入全名時建立重複的後綴。檢查結果答案而不是相信輸入表單。保存任何網域管理錯誤及其詳細信息，以便支援人員可以調查實際的故障而不是解釋的狀態。
決定是否需要自訂返迴路徑
Salesforce's DMARC支援文章 將對齊的DKIM描述為正常DMARC路徑，並解釋預設情況 回程路徑 域與可見的 From 不一致。它還記錄了支援輔助的自訂返迴路徑請求。所述限制是每個業務單位一個固定的自訂返迴路徑域，而不是為每個訊息選擇的可變域。
在請求此選項之前，請確定業務需求。需要對齊SPF和DKIM組織應在支持下評估實際的域排列和對齊模式。發送不相關品牌的業務部門不應假設一個固定的返迴路徑可以與每個「寄件者」網域保持一致。保持該設計問題處於開放狀態，直到觀察到的身份和支援的配置解決它。
從支援案例中取得準確的DNS記錄，並讓DNS所有者檢查衝突和依賴性。本文不提供通用的自訂返迴路徑目標或啟動開關。發布猜測的記錄或複製其他產品的跳出域配置可能會破壞工作路由而不滿足要求。
透過實際的訊息流測試所選的發送者
透過每個實質上不同的發送域和業務單元路由發送無害的受控訊息。使用與計劃的活動或自動化相同的寄件者選擇。記錄活動參考、訊息 ID、UTC 時間和外部測試收件者。如果預覽或測試功能使用與生產不同的路徑，請在將其視為代表性證據之前解決該差異。
在受信任的接收系統中，捕獲寄件者、 Return-Path以及所有DKIM簽章域和選擇器。 RFC 6376 定義用於尋找公用驗證金鑰的 d= 和 s= 值。將觀察到的簽章域與配置的傳送域進行比較。 DNS記錄可能是正確的，但郵件仍然使用意外的寄件者或其他路由。
申請 RFC 9989 以實際結果為準。 DMARC可以透過傳遞對齊 DKIM簽名 或透過對齊的SPF 。記錄提供結果的機制以及應用的對齊模式。將SPF身份驗證、 SPF對齊、 DKIM身份驗證和DKIM對齊保留在單獨的欄位中。這可以防止單一綠色狀態隱藏未經測試的需求。
對失敗的邊界進行故障排除，而不是更改每個控件
如果發送網域未經驗證，請將其驗證金鑰和確切的DNS所有者與預期DNS條目進行比較。如果在預期啟動期間後DKIM遺失，請確認所選的「寄件者」網域和帳戶，然後檢查「網域管理」錯誤。如果簽章失敗，請驗證選擇器和公用值，並檢查簽章後變更訊息的任何下游系統。
如果DMARC在SPF通過時失敗，請調查對齊以及是否為該寄件者配置了對齊的DKIM 。不要將預設SPF成功視為DMARC成功的承諾。如果涉及自訂返迴路徑，請將觀察到的信封標識與固定業務部門設定和支援提供的說明進行比較。保留有代表性的失敗訊息以供診斷。
將組織的DMARC政策和報告目標保留在其現有所有權之下。 Salesforce文章描述了需要外部DMARC監控，而不是收集這些資訊的 Account Engagement 故障報告。 DNS驗證工作不應默默取代報告目的地或降低不相關寄件者之間的執行力道。與郵件和安全所有者單獨審查任何建議的策略變更。
帳戶參與網域工作表
- 帳戶、業務部門、品牌和發送工作流程：____。
- 選擇的寄件者地址和配置的電子郵件發送網域：____。
- 單獨的追蹤器域及其現有相依性：____。
- 來自預期DNS條目的驗證金鑰和DKIM記錄引用：____。
- 公共DNS答案、發佈時間及管理狀況：____。
- 預設或支援輔助的自訂返迴路徑設計：____。
- 自訂返迴路徑限制和相關支援確認：____。
- 測試訊息 ID、UTC 時間、寄件者、 Return-Path和DKIM身分：____。
- 可信的身份驗證結果和一致的DMARC機制：____。
- 例外情況、監控所有者和批准的恢復：____。
無需對齊即可實現SPF成功的虛構範例
僅虛構的書面案例：AE-01 假設業務部門 North 發送為news@example.org ，業務部門 South 發送為news@example.net 。 bounce.example.org下提議的固定自訂返迴路徑可能與寬鬆SPF對齊下的第一個路徑對齊，但不能假定與不相關的第二個路徑對齊。 DKIM簽章和SPF結果仍然未知，因此這兩個路由都沒有斷言的DMARC判決。行銷和郵件所有者應將業務部門設定分開，並在請求任何根SPF編輯之前驗證每個選定寄件者網域的一致DKIM 。所有的身分和安排都是發明的；沒有支援案例、 DNS查詢或訊息被執行。
將完成情況與現場證據聯繫起來
記錄的工作流程不會驗證真實租用戶的權限、產生的值或自訂回傳路徑功能。這些帳戶檢查、即時DNS和標頭驗證、目視審查和 SME 人工批准仍然懸而未決。本指南尚未發布，不得作為組織的活動在生產中經過驗證的證據。
將傳遞的訊息與執行準備分開
RFC 9989第 7.4 節要求發布p=reject域具有有效的DKIM ，並警告間接郵件互通性。單一對齊的SPF結果本身並不能證明拒絕策略的推出是合理的。與此提供者設定分開審查所有合法路由和策略所有權。