建議和DNS寫入是不同的事件。分析師可能會正確識別身份驗證問題，但仍會更改錯誤的區域、覆蓋較新的記錄或應用程式所有者從未批准的建議。將批准邊界放在執行服務中，即使模型自信地提出請求，它也可以拒絕無效請求。
描述完整的建議操作
擷取提供者帳戶、租用戶、區域、確切擁有者名稱、記錄類型、目前記錄集、建議記錄集和相關 TTL 變更。包括業務說明和受影響的寄件者。區分新增一筆記錄與取代該擁有者名稱處的完整記錄集。接受請求的提供者 API 不一定會自動保留不相關的值。
以確定性形式表示提案併計算已核准欄位的摘要。將其與經過身份驗證的批准者、到期時間、允許的執行計數和持久更改 ID 相關聯。摘要保護平等，而不是權威：任何人都可以計算哈希值。批准記錄必須來自受信任的身份並受到保護以防止修改。
執行前立即重新檢查
使用寫入者將使用的相同帳戶和區域讀取目前狀態。將其與批准的基線進行比較，並驗證批准是否仍然涵蓋建議的差異。拒絕錯誤的租戶、過期、更改的有效負載和已使用的批准。如果提供程序支援條件更新，請使用它們來減少檢查和寫入之間的競爭。如果沒有這種支持，請序列化相關變更並公開剩餘競爭，而不是聲明原子性。
OWASP 過度代理 建議限制功能、最小權限以及對後續操作進行人工批准。這些特定的核准欄位是源自該原則的操作設計，而不是 MCP 強制要求的欄位。 MCP 安全指南 還需要對授權和下游信任進行審查。
在授予寫入權限之前測試邊界
對於書面計畫 MCP-DNS-01，假設提供者帳戶 A、租戶 A、區域 example.test、所有者_dmarc.example .test、類型TXT 、TTL 300、基線v=DMARC1; p=none 並提出v=DMARC1; p=quarantine。這是計劃結構，而不是建議發布或批准。不提供實際審批者身分、摘要、過期、執行計數和提供者先決條件。
- 將目標、有效負載和基準與所有有效的受保護批准欄位相符：符合支援的執行檢查條件，但尚未成功。
- 租戶 B 被替換、基線陳舊、期望值改變、批准過期或消耗了一次性批准：在提議的保護下拒絕。
- 模擬API成功前提但回讀不同：標記verification_failed並停止進一步變異；回應無法關閉變更。
- 提交後超時：結果未知。在決定重試是否安全之前，請協調有效狀態和操作記錄。
這些是書面的預期狀態，而不是執行的警衛或 MCP 部署。真正的整合必須在授權的非生產區域中測試記錄集行為、錯誤回應、條件更新和重試語義。保持寫入功能處於停用狀態，直到其行為和批准邊界得到驗證。
驗證郵件結果
檢查權威記錄狀態和相關解析器觀察結果，然後透過受影響的寄件者執行授權測試訊息。為了 DMARC，評估認證和 結盟 具有可見的 From 域，而不僅僅是TXT語法。 RFC 9989 定義了這種關係。記錄觀察到的內容和尚未測試的內容。
如果驗證失敗，請停止進一步寫入並升級到預先核准的復原計畫。回滾本身可以覆蓋合法的並發更改，因此需要重新進行狀態檢查。將批准、請求、提供者回應、回讀和郵件測試放在一起。操作最終狀態是已驗證的成功、已驗證的恢復或明確的未解決事件，而不是模糊的已完成標籤。