建立 Eloqua 發送和品牌範圍
將 Eloqua 行銷活動和銷售個人化訊息視為可能不同的寄件者域情況。在要求DNS所有者進行更改之前，先確定 Eloqua 實例、品牌和發送域。 Oracle 描述了在新訂閱帳戶的第一個活動之前轉換為品牌網域的情況。品牌先決條件本身並不是特定活動通過的證據 DMARC。看 Eloqua email authentication and branding.
本文的範圍是基於公共文件的 Eloqua 實施和驗證計劃。精確的按鍵， 選擇器 名稱、信封網域和租用戶啟動步驟必須來自目前的 Eloqua 入門或支援工作流程。不要因為 OCI Email Delivery 或 Responsys 也是 Oracle 產品就從它們複製記錄。
確認 From 和反彈先決條件
在DNS發布或測試發送之前，請確認預期的寄件者域與已配置的 Eloqua 反彈域的子域相符。 Oracle 指出，不符可能會產生驗證錯誤並阻止傳送。其範例將go.example.com的傳送子網域與return@go.example.com或bounce@go.example.com配對。記錄所選品牌實際配置的回彈地址和網域名稱；不要將建議的反彈值視為現有配置。看 Eloqua 電子郵件身份驗證設置、電子郵件退回地址和電子郵件預設值：寄件者和回覆地址。
檢查電子郵件預設值和任何每個電子郵件的覆蓋範圍。 Oracle 指出，當配置了多個網域時，可以變更反彈域。可編輯的「寄件者」欄位並不表示允許使用任意公司網域。如果簽署規則建議不同的寄件者網域，請在啟用路由之前取得受支援的公司寄件者及其配置的退回配對的帳戶特定確認。如果該先決條件無法驗證，請保留該狀態。 DKIM 僅簽署覆蓋範圍並不能消除此發送要求。
協調活動和公司寄件人域
Oracle的身份驗證設定頁面描述 SPF 作為 Eloqua 部署的一部分，並在代表銷售團隊發送公司網域簽章規則時呼叫公司網域上的公鑰發布。這使得實際的來自域庫存很重要，尤其是當行銷活動和個人化銷售訊息使用不同的網域時。看 Eloqua 電子郵件身份驗證設置.
列出允許的寄件者地址、其已確認的配置反彈配對以及產生每個地址的範本或簽名規則。從主要活動路徑和任何公司網域路徑捕獲基線。從行銷子網域發送的測試無法建立銷售人員公司地址的簽章覆蓋範圍。單獨保留 Reply-To，因為回復和身份驗證有不同的目的。
取得並發布特定於帳戶的變更集
請求已識別實例和域的當前 Eloqua 說明。審核資料包應包括確切的公共DNS所有者、記錄類型和值、預期的簽名域、啟動步驟以及現有品牌域的任何先決條件。公共文件建立了工作流程概念，但並未為每個帳戶提供通用的複製貼上記錄集。
在發布之前，請檢查當前區域並確定現有的SPF授權。請勿在同一所有者處新增第二個SPF策略。 SPF標準定義了記錄選擇和 DNS 查詢限制；建議的增加必須透過現有機制進行評估，而不是作為一個孤立的字串進行評估。看 RFC 7208寄件者策略框架。保留不相关的合法发件人和不相关的DKIM选择器。
DNS所有者發布批准的更改後，確認權威回應並要求 Eloqua 所有者完成指定的啟動。獨立記錄每一面。當應用程式仍然使用另一個身分進行簽署時，可以存在公鑰，並且當委派區域配置錯誤時，應用程式狀態可以顯示為就緒。
測試每個真實的活動路徑
只有當寄件者和配置的反彈配對通過 Eloqua 驗證後，才從實際行銷活動配置向受控接收者發送一個小型的、同意的測試。僅在確認其支援的發送配置和反彈配對後才包含個人化公司域路由。如果 Eloqua 在傳輸前封鎖不符合的傳送方，請在診斷接收方驗證之前解決該先決條件。記錄自， Return-Path、 DKIM d= 和s=,以及接收系統的SPF 、 DKIM和DMARC結果。 DKIM簽名 verification and DMARC 結盟 是不同的测试。看 RFC 6376網域金鑰識別郵件 和 RFC 9989基於網域的訊息驗證報告和一致性.
將已發送的訊息與已核准的網域清單進行比較。當寄件者地址動態變化時，測試多個代表值。不要從靜態模板預覽中推斷一般覆蓋範圍。還要驗證回覆是否發送到預期郵箱以及追蹤的連結是否按預期運行，而不將任何測試視為身份驗證證明。
Eloqua 網域接受工作表
Use a separate row for the campaign domain and every corporate-domain signature case:
- Instance and brand: ____; campaign or signature rule: ____.
- Actual From address and domain: ____; permitted domain owner: ____; monitored Reply-To: ____.
- Already configured bounceback address and domain for this brand: ____; evidence that the From matches the configured bounceback subdomain: ____.
- Default versus per-email From override: ____; selected configured domain if multiple domains are enabled: ____.
- 企業簽章規則路由確認與帳號/支援參考：____；傳送前 Eloqua 寄件者驗證結果：____。
- Account instruction or support reference: ____; issued record owner and type: ____.
- 現有SPF相依性與建議合併：____； DKIM選擇器和簽章域：____。
- 權威DNS觀察：____; Eloqua 啟動確認：____。
- Controlled test timestamp and Message-ID: ____; receiver: ____.
- SPF特性與結果：____； DKIM身分與結果：____；協調機制：____。
- Exception owner, recovery route and release decision: ____.
拒絕具有未配置或不匹配的反彈配對、未經確認的公司簽章規則路由、從另一個實例複製的選擇器或具有不同 From 域的成功樣本的行。將遺失的帳戶指令標記為未解決，而不是用第三方配方取代它們。
銷售簽名失敗的虛構診斷
僅虛構範例：Riverbend 已單獨確認帳戶支援的企業寄件者路由，為example.com配置其反彈配對，並透過了來自salesperson@example.com的銷售訊息的 Eloqua 寄件者驗證。來自news.example.com的活動路線也具有有效的配置反彈配對。這些是範例的明確假設，未觀察到客戶設定或選擇任意公司 From 網域的權限。
已傳遞的銷售郵件通過d=news.example.com的DKIM ，但未通過DMARC因為虛構域使用嚴格的DKIM對齊 ( adkim=s),可見的發件人域是example.com ，並且沒有對齊的傳遞SPF結果。因此，成功的行銷活動樣本不能證明該銷售路線的一致性。在寬鬆的DKIM對齊下，那些相關的簽章域和寄件者域可以對齊；此範例不得推廣到該模式。
團隊保留有效的發送和退回配置，請求支援的公司路線的正確的特定於帳戶的簽名範圍，並在啟動後驗證新的銷售訊息。如果「寄件者」和「反彈」先決條件無效，則第一個診斷將是 Eloqua 的驗證或阻止發送情況，而不是接收訊息對齊失敗。沒有檢查 Riverbend 帳戶或訊息。
Close the operational loop
身份驗證工作後，將回饋循環加入作為單獨的操作任務進行處理。 Oracle 描述了在DKIM設定後聯絡支援人員並完成相關確認流程。不要僅僅因為訊息已簽名就聲稱啟用了投訴報告。看 Eloqua 電子郵件身份驗證設置.
為失敗的網域變更保留回溯計劃，保留工作選擇器直到發送所有者確認退出，並在品牌、簽名規則或寄件人域變更後重新測試。身分驗證不保證收件匣的放置或授權聯絡人清單。該紀錄片候選者的帳戶發布記錄、即時DNS 、接收器測試、目視檢查、SME 手動批准和發布仍有待完成。
將訊息接受與策略推出分開
透過對齊的SPF結果可以滿足郵件評估的要求，但並不能單獨證明將整個網域移至拒絕。 RFC 9989 第 7.4 節要求有效的DKIM進行域發布 p=reject 並警告間接郵件互通性。在策略擁有者批准執行之前，清點所有合法寄件者和間接路由。本文未執行任何DNS變更、租用戶操作或接收訊息測試。