公民可以在一次申請期間收到來自中央部門、機構入口網站和簽約提醒服務的郵件。成功的郵箱遷移並不能證明後兩者的情況。在更改身份驗證策略之前映射服務旅程，並在公民依賴訊息的點上擁有所有權。
遵循服務而不是組織結構圖
選擇一項公共服務旅程，例如申請許可證。列出提交收據、更多資訊請求、預約通知和最終決定通知。記錄觸發每個訊息的應用程式、服務提供者、其租戶、可見的From位址、 信封寄件人, DKIM 域和 選擇器，以及負責的企業主。部門地址簿不會透露所有這些系統。
單獨的網域註冊控制、委託DNS控制和應用程式管理。機構可以擁有其申請，而上級部門則發布其記錄；承包商可以配置簽名，但雙方都不能批准對方的更改。指定接受使用者影響的服務擁有者和可以執行變更的技術所有者。請勿將熟悉的看似政府的顯示名稱視為任一權威機構的證據。
建立委託域邊界
對於每個委託機構域，檢查其實際DNS和適用的 DMARC 策略而不是假設中央域設定按預期覆蓋它。記錄它是否發送、接收或僅作為網址存在。記錄承包商授權的發送範圍及其結束日期。自訂DKIM設定和信封身分應針對特定租用戶進行驗證，而不是從其他機構的配置複製。
下面的路線圖特意包含了一個承包商，該承包商假定在提供者的域下具有傳遞簽名，但與代理機構的 From 域並不完全一致。糾正任務是調查批准的對齊路徑，而不是授權該提供者擁有的每個位址。從經過驗證的服務中獲取新的值，進行狹窄的更改並在更廣泛的實施之前測試真實的路線。
在變更期間保護服務連續性
圍繞低頻但重要的流程安排測試，包括拒絕申請或要求遺失文件。每個月的大量新聞通訊並不能充分取代。與服務業者就如何升級失敗的測試、公民如何獨立檢查其應用程式狀態以及誰可以停止推出達成協議。不要將真實的公民記錄發送給測試收件人。
使用帶有日期的變更記錄以及先前的狀態證據、預期身分、審核者、操作員和回溯操作。在確認排隊和重複訊息已移動後，透過協調的離職計畫取消承包商的存取和簽名權限。每當機構被委派新的DNS控制、入口網站變更供應商或中央郵箱遷移開始時，請查看路線圖。任何政府授權或保留義務都需要特定司法管轄區的法律驗證；本指南沒有提出普遍的監管要求。
完成三份書面路線記錄
這些保留的範例域、選擇器、角色和傳遞的DKIM前提都是虛構的。對於這些情況，不提供或執行任何簽署訊息、金鑰、加密驗證、 DNS查找、 SMTP交易或即時服務測試。不需要測試程式碼或外部樣本來檢查以下推理。
- 公民入口網站：從網域portal.civic.example可見； DKIM d=portal.civic.example;選擇器演示1；假設DKIM僅針對此書面案例通過。 SPF 身份和結果未知的郵件；其他簽名未知；實際的政策發現和交付未知。提議的所有者：數位服務所有者。下一步操作：取得該租戶的授權樣本和可信任接收器結果。
- 委託代理機構：來自域名agency.civic.example可見； DKIM d=agency.civic.example;選擇器演示2；假設DKIM僅針對此書面案例通過。 SPF MAIL FROM 身分和結果未知；其他簽名未知；實際的政策發現和交付未知。提議的所有者：代理通訊所有者。下一步操作：確認此單獨的路由及其業務事件，而不是繼承第一個路由的結果。
- 承包商提醒：可從網域notices.civic.example可見； DKIM d=provider.example.net;選擇器示範3；假設DKIM僅針對此書面案例通過。 SPF MAIL FROM 身分和結果未知；其他簽名未知；實際的政策發現和交付未知。擬議業主：合約經理。下一步行動：向經過驗證的供應商詢問該租用戶支援的一致簽章路徑；不要將授權擴大到整個網路。
對於前兩個規定的簽名，d=恰好等於From域，因此標識符滿足嚴格和寬鬆 結盟。鑑於規定的成功DKIM結果，這些假設訊息存在一致的身份驗證路徑。第三個簽名者故意與作者域無關，並且無法提供一致的路徑。不要將第三條訊息稱為DMARC失敗：對齊SPF或其他對齊傳遞 DKIM簽名 仍然可以滿足該機制，並且這些輸入是未知的。不要從任何行推斷真實的部署或收件匣位置。
加密簽章驗證簽章域的責任，而不是每個指令的真實性或授權。覆蓋的規範化位元組的更改可能會使簽名無效；並非每個可見的編輯都必然會更改簽名的輸入。身份驗證和應用程式級接受仍然是分開的。
分配具體的發布決策
對於虛構的許可旅程 P-01，數位服務所有者接受收據覆蓋範圍，機構所有者接受決策通知覆蓋範圍，合約經理獲取提醒租戶配置。 DNS運營商僅實施經過批准的精確差異；僅應用程式存取並不授權該差異。如果承包商無法展示一致的路線，請保持該路線懸而未決，並暫停受影響的政策變更，而不是宣布整個旅程已準備就緒。在承諾連續性之前記錄已批准的替代狀態檢查路徑及其人員配置。這些所有者或文物均未在此處驗證。
應用標準而不聲明合規
RFC 9989第 4.4 節及 5.3.5 節 支援對齊和機制區分。它的第 7.4 節警告了間接郵件互通性：使用網域 p=reject 必須使用有效的DKIM ，而不僅僅是SPF ，且通用郵件清單的使用需要特別小心。路由清單本身並不具有強制拒絕的權限。 RFC 6376第 3.4–3.7 節和 6.1 節 描述簽名的輸入和驗證。 RFC 9990第 3.1 節 提供報告背景，而不是每個收件人的到達證明。 RFC 5321第 4.2.5 節 將伺服器接受責任與後來的交付結果區分開來。這裡的部門工作流程選擇是編輯建議；法律範圍、因素適用性和地方授權需要進行自己負責任的審查。