確定Openprovider是否服務於活動區域
本指南涉及在 Openprovider DNS中發布身份驗證記錄。它不是Openprovider單獨郵箱或轉送產品的設定指南。當Microsoft 365 、活動服務或其他提供者傳送其郵件時，您的網域可以在 Openprovider 中註冊。發送者提供其認證指令；權威DNS運營商公佈批准的記錄。分配工作時將這些角色分開。
Openprovider支援自己的 名稱伺服器 和外部名稱伺服器。其名稱伺服器指南解釋說，外部託管區域必須在外部DNS供應商處配置，而 Openprovider 託管區域則透過DNS管理和DNS區域概述進行管理。從實際的公共代表團和正在改變的確切區域開始。註冊的網域和帳戶中可見的區域不足以建立權限。 Openprovider 名稱伺服器指南
不要僅僅為了創建一個名稱伺服器而更改名稱伺服器 SPF 可用編輯器。這是一個單獨的遷移，可能會影響網站、入站郵件、驗證令牌和 DNSSEC。如果外部提供者俱有權威性，請將核准的記錄變更交給該提供者的管理員。如果 Openprovider 具有權威性，請確認您正在編輯即時區域而不是供將來使用的範本。
收集來自發送服務的記錄更改
請求目前寄件者核發的SPF授權， DKIM 所有者和值、任何自訂信封說明以及每個應用程式的精確域。避免使用稱為 Openprovider SPF設定的通用記錄：僅透過託管區域， DNS主機不會成為授權郵件寄件者。同樣的差異也適用於DKIM 。 Openprovider 的DKIM文章稱，發送郵件伺服器確定記錄內容，並由供應商或系統工程師提供。 Openprovider DKIM出版物
匯出或以其他方式保留完整的受影響記錄集，包括擁有者名稱、類型、TTL 和值。保持不相關的TXT令牌完整。將每個提議的操作記錄為新增、替換或停用，並附上其服務所有者和原因。一個 選擇器 看起來舊的可能仍會驗證排隊的郵件或支援其他應用程式。新服務的指令並不授權刪除舊服務的金鑰。
將完全合格的預期所有者與編輯器輸入分開。對於DKIM來說，選擇器和_domainkey標籤是必不可少的；它們不能與域頂點互換。為了 DMARC，識別適用的_dmarc所有者。對於SPF ，確定實際的SMTP信封域。檢索到的DNS記錄指南未建立目前通用的頂點條目約定。儲存前確認根所有者和附加後綴的目前介面處理；不要假設每個輸入模式都接受空白欄位或@。 Openprovider DNS記錄約定
將SPF發佈為具有經過驗證的TXT格式的策略
Openprovider 的SPF指南使用 TXT記錄 並特別指示使用者將內容用直引號括起來。遵循目前編輯器記錄的輸入約定，然後檢查已發布的TXT答案以驗證格式是否正確解釋。從文字處理程式複製的大引號並不等效。當解析器已顯示引號的字串時，請勿重複新增引號層。 Openprovider SPF出版物
協議語義是接受標準。被評估的所有者應該有一項候選SPF政策。一條TXT記錄可能包含多個字串，這些字串連接起來進行SPF處理，因此顯示拆分不一定是多個策略。相反，以SPF版本標記開頭的兩個單獨的記錄並不是容納兩個寄件者的有效方法。在重構值中保留所需的空間和完整的機構序列。 SPF RFC 7208
該提供者的一般SPF文章包含有關TXT長度的簡化語言，而其DNS記錄指南明確描述了將大TXT值拆分為一筆記錄中較小的字串。字串限制不得視為總記錄限制。確認目前編輯的處理並驗證重構的答案。 Openprovider TXT記錄指導 如果長值被拒絕，請取得提供者指示；不要縮短公鑰或將SPF策略拆分為獨立記錄。
在儲存合併策略之前評估SPF的遞歸查找限制。視覺上較短的保單仍然可以透過包含的保單來超越限制。不要用當今 IP 位址的快照取代提供者維護的機制，除非該維護模型得到了刻意批准和支援。靜態扁平化改變了必須追蹤未來基礎設施變化的人。
維持DKIM記錄類型和選擇器所有權不變
一些發送服務提供TXT公鑰；其他人提供 CNAME 別名。在提供的選擇器擁有者處發布提供的類型。請勿將CNAME目標放入TXT欄位或在頂點發布金鑰。接收者從訊息的簽名網域和選擇器中匯出查找，這就是為什麼不同所有者的看似合理的記錄沒有幫助。 DKIM RFC 6376
當CNAME與其他普通記錄資料共用其所有者時，Openprovider 會記錄錯誤。如果編輯者報告重複或CNAME衝突，請檢查該確切所有者的完整記錄集。在確定擁有衝突的TXT記錄的寄件者之前，請勿刪除該記錄。向新寄件者詢問受支援的非衝突選擇器或計畫受控輪替。衝突是信任所有權問題，而不僅僅是輸入驗證問題。 Openprovider CNAME衝突指導
公鑰或委託記錄不會導致發送服務開始簽署。單獨完成任何發送方啟動並驗證真實訊息上的簽名。切勿在區域或工作表中發布私鑰、API 憑證或SMTP密碼。
區分手動DMARC和託管委派
Openprovider 的 EasyDMARC 整合描述了兩種管理路徑：透過CNAME別名實現的託管策略和手動維護的TXT策略。它警告範例中顯示的委託目標不是要使用的值；控制面板提供實際目標。它還描述了使用 Openprovider 名稱伺服器在合格購買或啟動流程中自動建立CNAME 。因此，在手動新增任何內容之前，請檢查現有的_dmarc所有者。 Openprovider EasyDMARC 管理
選擇一種經認可的管理模式。對於託管委派，託管服務中的操作策略可能會發生變化，而無需在 Openprovider 區域中進行相應的編輯。為該服務指派所有者並保留其核准的策略設定。對於手動TXT ，更改必須反映在發布的值中。避免將TXT策略和CNAME保留在同一所有者處，並且不要僅僅為了遵循整合精靈而取代現有的報告目標。
DMARC根據傳遞的對齊SPF或DKIM身分來評估可見的寄件者域。出版是這過程的一部分；它並不能證明域的寄件者是一致的。使接收者行為與請求的策略不同，並在加強執行之前保留網域範圍內的發送者清單。 DMARC RFC 9989
可重複使用的 Openprovider 發布工作表
為每個變更的擁有者建立一行，並保留網域的共用變更記錄。
- 網域名稱、權威網域名稱伺服器和活動區域識別碼：______。
- DNS管理員、寄件者管理員和變更審核者：______。
- 發送服務及其目前配置證據：______。
- 預期的完全合格所有者和單獨編輯主持人輸入：______。
- 記錄類型、完整核准值和 TTL：______。
- 先前的記錄集和必須保留的依賴項：______。
- SPF評估了信封所有者和遞歸策略檢查：______。
- DKIM選擇器所有權、衝突審查和寄件者啟動：______。
- DMARC手動TXT或託管CNAME選擇和政策所有者：______。
- 權威的修改後答案和遞歸比較：______。
- 收到的訊息參考、寄件者、信封、簽名和可信結果：______。
- 回滾步驟、重新測試所有者、目視檢查和人工驗收：待定。
選擇器碰撞的虛構診斷
這個例子是虛構的。經銷商會在其DNS由 Openprovider 託管的網域中新增新的行銷服務。新服務在已持有發票寄件者TXT金鑰的選擇器處請求CNAME 。 Openprovider 將變更視為衝突而拒絕。經銷商建議刪除TXT ，因為新的設定指南說需要選擇器。
安全調查會識別發票發送者並確認它仍然使用該選擇器簽署傳出訊息。建議的恢復是向行銷服務請求不同的受支援選擇器，或與兩個所有者協調經過驗證的金鑰轉換。並不是盲目地刪除發票密鑰。變更獲得批准後，將測試單獨的發票和行銷資訊。此場景不代表任何實際區域、寄件者或成功的測試。
關閉DNS和訊息證據
儲存並保留回應後，在權威名稱伺服器上查詢確切的擁有者。分別比較遞歸答案，辨識快取。然後讓每個受影響的寄件人為獨立郵箱產生受控訊息並記錄受信任的收件者結果。僅 DNS 驗證器無法確認傳送者實際使用哪個選擇器或其傳遞的身份是否一致。
如果需要恢復，則僅恢復受影響的先前記錄集並重複相關的工作流程測試。保留託管策略設定和DNS值的證據，因為前者可以獨立更改。本指南的當前帳戶存取權、介面螢幕截圖、權威的前後捕獲、收到的訊息證據和人類 SME 批准仍有待確定。未執行任何DNS編輯或即時測試。
將公共記錄與加密操作分開
發佈公鑰不會加密電子郵件正文、建立簽名或確定整個郵件是安全的。使用DKIM標準來簽署語義，而不是提供者文章的簡化加密解釋。發送方操作員完成啟動後，驗證實際簽名內容和接收方結果。
將訊息接受與策略推出分開
透過對齊的SPF結果可以滿足郵件評估的要求，但並不能單獨證明將整個網域移至拒絕。 RFC 9989 第 7.4 節要求有效的DKIM進行域發布 p=reject 並警告間接郵件互通性。在策略擁有者批准執行之前，清點所有合法寄件者和間接路由。本文未執行任何DNS變更、租用戶操作或接收訊息測試。