確認 Optivo 名稱在此帳戶中的含義
標示為 Optivo Marketing 的庫存條目不足以選擇目前的DNS指令。 Optimizely 的收購公告確立了 Optivo 和 Episerver 之間的歷史關係。目前的 Optimizely Campaign 整合文件也會在特定 Shopware 工作流程中保留 optivo Broadmail 標籤。這些來源支援產品沿襲並解釋了為什麼舊名稱仍可能出現，但它們並不能證明描述為 Optivo Marketing 的每個帳戶都使用相同的當前租戶、介面或網域配置。 Optivo收購公告 行銷活動事務電子郵件集成
從租用戶 URL、合約服務、帳戶擁有者、用戶端識別碼和實際發送路徑開始。取得目前支援確認，將舊帳戶連結到適用的 Campaign 文件。如果無法建立該關係，請在發布新的提供者記錄之前停止。此時有用的工作是路線清單和證據請求，而不是發明的 Optivo 設定。
因此，本指南描述了身份確認後的有條件行銷活動實施。它不會默默地用後續產品取代未經驗證的遺留服務。本文沒有存取舊租用戶，且特定於帳戶的對應仍然是明確範圍保留。在變更單和任何實施估算中保持該限制可見。
映射可見的寄件者和技術返迴路徑
對於已確認的行銷活動路線，請將可見的「寄件者」網域與技術領域分開 回程路徑 領域。目前的身份驗證指南位置 SPF 在技術返迴路徑域上並描述 DKIM CNAME 與技術域和可見發送域相關的記錄。從租戶支援的設定中捕獲實際的網域和完整的所有者名稱，而不是根據指南的範例建立它們。 活動電子郵件身份驗證
可見的寄件者是收件者看到的內容。 SMTP信封標識用於退回郵件處理和SPF評估。 DKIM使用網域進行簽名，並且 選擇器 記錄在訊息中。這些身分可以相關但不相同。追蹤連結、登陸頁面或圖像主機名稱是另一個單獨的網域角色，並不證明郵件已通過身份驗證。
盤點每個活動客戶、品牌和發送工作流程。即使時事通訊、選擇加入訊息和事務整合流量共享基礎設施，也可能需要單獨的測試行。記錄哪個系統建置內容、哪個系統發起傳送、哪個服務執行最終交付。整合接受的 API 請求並不等於透過一致的身份驗證收到的訊息。
在發布前獲取當前域設置
向支援人員或授權帳戶管理員詢問與該用戶端關聯的目前網域配置。記錄集應標識技術返迴路徑、可見的寄件者域、選擇器、確切的記錄類型和值、任何委託區域邊界以及提供者端驗證或啟動步驟。詢問誰控制每個DNS區域以及哪些變更是先決條件而不是可選的品牌功能。
目前的行銷活動指南發布了一般SPF和DKIM範例，但單獨的CNAME目標並不能為未知的舊帳戶建立所需的擁有者或選擇器。本文有意省略可複製的DNS值。請勿從其他客戶的郵件推斷記錄所有者、重複使用歷史螢幕截圖或合併來自 Campaign 和 Optimizely DXP 的記錄。每條指令必須對應已確認的發送路徑。
如果計劃涉及授權，請準確確定授權的內容。移動 名稱伺服器 子網域可以轉移對多個電子郵件身份驗證記錄的控制。擷取該邊界內的現有網站、驗證和郵件相依性。在未檢查這些依賴關係並獲得其服務所有者的批准的情況下，請勿重新調整活動子網域的用途。記錄級CNAME和名稱伺服器委託具有不同的操作範圍。
在更改期間保留SPF和DKIM所有權
在每個評估的SPF所有者處，檢查現有策略和其他授權寄件者。僅合併已確認路線所需的授權，保留一項候選策略和其他來源的核准處理。根據SPF的查找限制評估包含和重定向。一個 SPF記錄 在公司頂點不會自動套用於單獨評估的技術返迴路徑域。 SPF RFC 7208
對於DKIM ，請在發出的指令中保留確切的選擇器和簽章域關係。在發布 CNAME 之前解析每個所有者的現有記錄。如果另一個發送者擁有衝突的選擇器，請協調受支援的替代方案或轉換，而不是刪除舊密鑰。透過簽章服務保留私人簽署資料； DNS僅包含公共驗證資料或委託。 DKIM RFC 6376
保存完整的之前狀態並在權威DNS處驗證之後狀態。檢查預期的完全合格所有者，而不是管理螢幕截圖中顯示的標籤。記錄控制未來變更的管理介面： DNS提供者、委託區域或 Campaign 服務。如果這些職責不清楚，請將啟動掛起，而不是聲明傳播是唯一剩下的步驟。
評估實際DMARC政策下的一致性
活動的 DMARC 指南描述了預設值 標識符對齊 並建議檢查收到的訊息。將其視為記錄的產品設計，而不是特定舊帳戶、自訂寄件者網域或新變更的工作流程目前一致的證據。通過的認證結果必須與域實際對齊設定下可見的From域進行比較。 DMARC實作活動
DMARC可以透過至少一條傳遞對齊的SPF或DKIM路徑獲得成功。它不需要兩條路徑同時通過。嚴格對齊需要匹配域標識；不應假設相關子域滿足它。使用目前的DMARC規範來解釋策略發現和對齊，尤其是在提供程序概述簡化了這些規則的情況下。 DMARC RFC 9989
提供者建議執行策略，但該建議並未授權立即進行網域範圍內的策略替換。清查合法寄件人，檢查現有策略並與網域所有者就受控部署達成協議。保留核准的報告收件者和帳戶以供第三方報告處理。報告隨著時間的推移提供額外的觀察結果；它們的缺失並不能證明不存在身份驗證失敗。
測試實際的活動或整合工作流程
身份確認、 DNS驗證和提供者啟動後，透過將在生產中使用的工作流程發送受控訊息。記錄客戶、活動或交易範本、觸發器、寄件者身分和時間戳記。使用少量授權測試受眾來合成內容。預覽渲染或整合 API 成功回應不能取代獨立的接收訊息證據。
對於使用舊 optivo Broadmail 標籤的 Shopware 集成，當前文件描述了將事務變數傳遞到 Campaign，在此處組裝和發送訊息。這是測試最終行銷活動交付的原因，而不是證明商店自己的郵件伺服器是出站簽名者。在應用此描述之前，請確認實際整合和版本是否相符。 行銷活動事務電子郵件集成
保留原始接收訊息和可信任接收系統的身份驗證結果。記錄 From、信封、每個DKIM d= 和 s= 對、單獨結果和DMARC對齊。分別測試不同的品牌和交易路線。也要驗證預期的退回郵件和回覆行為，而不將成功回覆視為SPF或DKIM通過的證據。
可重複使用的舊 Optivo 路線工作表
使用此工作表將經過驗證的實施與僅僅合理的後繼產品映射區分開來。
- 舊服務標籤、租用戶 URL、客戶識別碼和帳戶擁有者：______。
- 由支援人員確認的當前產品標識，以及日期和參考編號：______。
- 適用的文件版本和不支援的舊功能：______。
- 工作流程類型、整合版本、觸發器和發送客戶端：______。
- 從域、技術返迴路徑和預期DKIM身分可見：______。
- DNS主機、委派邊界和相關服務：______。
- 每個所需記錄的核發所有者、類型和值：______。
- 現有SPF和DMARC政策以及核准的變更：______。
- 提供者驗證或啟動證據：______。
- 權威DNS擷取與獨立訊息參考：______。
- 可信賴認證結果、對齊模式和結果：______。
- 恢復所有者、視覺演練和人工批准：待定。
對傳統標籤和嚴格政策的虛構診斷
這個場景是虛構的。零售商的整合仍然顯示 optivo Broadmail，但其合約和支援回應將活動發送用戶端標識為 Campaign。其訊息通過技術子域的SPF和相關域的DKIM 。新實施的嚴格對齊設定會導致零售商預期的寄件者身分無法透過DMARC對齊。
所提出的診斷將可信任接收器結果中的確切域與策略的對齊模式進行比較。它並不假設共享 組織域 在嚴格的設定下就足夠了。管理員向 Campaign 支援請求預期寄件者網域支援的身份配置，而安全性擁有者則檢查嚴格策略是否是有意為之。下一步是在批准更改後發送受控訊息，而不是複製不同產品的DNS配方。這說明瞭如何推理失敗；尚未進行實際的客戶測試。
恢復而不丟失其他行銷活動依賴項
如果新配置失敗，請在可行時僅暫停受影響的發送，並保留提供者回應、 DNS應答和收到的訊息。當回滾合理時，恢復先前批准的狹窄狀態。不要刪除所有遺留選擇器或委託記錄，因為它們的名稱看起來已經過時；另一個活動的用戶端或排隊的訊息可能仍然依賴它們。與帳戶和DNS所有者確認停用。
文件證據確立了當前的 Campaign 概念和歷史上的 Optivo 聯繫。它沒有建立確切的遺留租戶的適用性、發布的記錄集或成功的操作。產品映射、租戶演練、即時DNS 、真實收到的訊息證據、視覺審查和 SME 人工批准仍有待完成。本文是一份完整的範圍內的準備和驗證指南，而不是聲稱對帶有 Optivo 名稱的每項服務都完成了身份驗證。
將記錄的入職與訊息評估分開
Campaign 的入職指南要求SPF和DKIM配置。該產品要求與評估至少一種傳遞機制是否與特定訊息一致的DMARC相容。不要將記錄的預設身分設計與未經檢查的舊客戶端遵循它的證據混淆。
將訊息接受與策略推出分開
透過對齊的SPF結果可以滿足郵件評估的要求，但並不能單獨證明將整個網域移至拒絕。 RFC 9989 第 7.4 節要求有效的DKIM進行域發布 p=reject 並警告間接郵件互通性。在策略擁有者批准執行之前，清點所有合法寄件者和間接路由。本文未執行任何DNS變更、租用戶操作或接收訊息測試。