具有一項受控郵件服務的 10 個網域所需的工作量比許多獨立應用程式使用的一個網域要少。實施工作遵循依賴性：誰控制DNS 、誰可以更改每個發送者、必須測試哪些工作流程以及所有者批准工作的速度。在承諾時間表之前計算這些依賴關係。
建立目的和所有者登記冊
對於每個網域和相關子網域，記錄合法控制者、 DNS管理員、發送目的、接收目的、服務擁有者和變更權限。將發送和接收決策分開。不再發送行銷郵件的網域可能仍會收到發票或密碼重設回覆。收購可能會引入外部DNS機構、遺留應用程式和無法批准新組織變更的所有者。
映射發送路由而不是假設 IP 標識一個應用程式。記錄可見的From網域、授權服務和可用的身份驗證證據。 RFC 9989 提供協議的 結盟 和政策模型；它不會告訴您您的組織已授權哪些應用程式。
尋找隱藏的工作
向財務部門詢問每月發票的情況，向人力資源部門詢問年度福利通知的情況，向支援人員詢問票務系統的情況，向應用程式團隊詢問恢復訊息的情況。查看可用報告以及服務庫存和受控樣品。 RFC 9990 報告是來自參與接收者的有用證據，而不是完整的發現保證。缺少報告行並不能證明服務從未發送。
將每條路由分類為已驗證、需要服務配置、需要所有權解析或需要退役決策。將遺失的存取記錄為依賴項，而不是高效的工程時間。兩小時的配置任務可能需要等待數週才能獲得供應商的批准；區分付出的努力和經過的時間。
進行明確的說明性估計
假設一個發明的遺產包含 6 條直接路線，每條需要 2 小時，3 條整合路線，每條需要 6 小時，以及 2 條有爭議的所有者路線，每條需要 4 小時的調查。配置和調查總共38小時。新增明確假設的 8 小時用於受控測試和 4 小時用於變更審核：50 小時。這些持續時間都不是基準。將它們替換為飛行員的測量值，並單獨顯示等待時間。
只有當您能夠解釋低估計值、中估計值和高估計值之間的變化時，才使用它們。例如，較高的情況可能需要供應商針對簽章限制進行補救；它不僅僅是中心數字乘以一個無法解釋的百分比。保留每個未解決專案的依賴項擁有者和下一次審核日期。
經過代表性試辦後重新估算
選擇暴露該地產複雜性的路線，包括一項第三方服務和一項不頻繁的人流。記錄實際的動手工作、交接、失敗的嘗試和經過的批准時間。在擴展之前更新估計。退出證據應包括負責任的所有者、觀察到的路由測試以及針對剩餘例外情況的批准計劃，而不僅僅是發布的DNS記錄。
綜合用途和所有者登記冊
這是一件合成的人工製品。未提供實際觀察、批准和商業承諾。
- billing.example .test / 發票：目的和責任角色：發送：發票；接收：客戶回覆。財務負責人； DNS營運。 ；隱藏流程檢查：檢查每月發票作業和回覆路由；未執行；發送/接收決策：測試後修復發送/保留入站回覆。
- events.example .test/活動通知：目的和責任角色：發送：季節性邀請；接收：與會者的回應。活動負責人；機構DNS依賴性。 ；隱藏流程檢查：檢查年度活動安排和舊活動租戶；未執行；發送/接收決策：保留發送決策/保留回應路徑。
- recovery.example /密碼重設：目的和責任角色：發送：帳戶恢復；接收：幫助升級。身份所有者；應用團隊。 ；隱藏流檢查：檢查休眠帳戶恢復和容災租戶；未執行；發送/接收決策：驗證活動和休眠發送/單獨評估幫助路由。
- Legacy.other.test / 取得的應用程式：目的和責任角色：發送目的未解決；接收：可能的供應商發票。收購線索；前DNS業者。隱流查：查詢收購庫存，詢問AP所有者；未執行；發送/接收決定：無退休決定/無接收關閉。
該估計將六條直接路線與金融類型模式聯繫起來，將三條整合路線與身份類型模式聯繫起來，將兩條有爭議的所有者路線與收購領域模式聯繫起來。這些是說明性的類別，而不是計算的遺產。機構批准和舊版DNS訪問在 50 個小時的實際操作時間之外正在等待依賴項。
將時間表與登機口的工作分開
假設兩條有爭議的業主航線在試點期間無法獲得批准。說明性的 50 小時估算仍然是工作估算，而不是進行這些變更的許可或完成日期。僅發佈單獨批准、測試的範圍，並將有爭議的路由保留為命名依賴項。並行人員可以減少一些經過的時間，但不能消除缺少的審核者或安全地劃分單一未解決的所有權決策。
來源範圍
RFC 9989第 4.4、5.3.5 和 5.4 節 區分對齊、訊息評估和接收器處理。 RFC 9990第 3.1、7 和 8 節 描述總結證據和隱私/安全考慮因素。兩者都沒有具體說明工作時間、價格或商業營運承諾。這裡的工作估算、成本範例和評估門是原始的編輯指導，而不是觀察到的客戶結果或標準規定的預算。