代理可以生成合理的身份验证建议，但仍然执行不安全的更改。失败的可能是租错了房客， 一个记录 审核后发生更改，或者 API 响应成功但邮件身份验证失败。围绕这些转变设计批准门，而不是一般性的谨慎指示。
制定可审查的提案
识别客户、租户、区域、完全限定的所有者名称、记录类型、完整的前后值以及目的。解释受影响的发送服务以及支持更改的证据。提议的 DKIM选择器 出版物应命名将与其签署的服务；提议的 SPF 变更应解释由此产生的授权。摘要可以绑定这些字节，但它无法建立批准者的身份或权限。
OWASP 的过度代理指南建议限制功能、权限和自主权。通过将推荐和执行接口分开来应用该原则。这里的字段和决策示例是原始实施建议，而不是 OWASP 定义的批准协议。
执行前立即重新验证
检查经过身份验证的参与者对目标租户的权限、批准到期时间、提案摘要和当前基线。任何不匹配都会返回审核请求。不同客户帐户中的相同可见域名不得继承批准。使用提供商的条件更新设施（如果可用）；否则要认识到先读后写会留下竞争窗口，并相应地设计锁定或协调。
假设租户 A 中的选择器发布批准了提案。在执行时，请求以具有相同域标签的租户 B 为目标。目标不匹配时停止；匹配的有效负载摘要无法扩展审批者的范围。这是假设的拒绝条件，而不是经过测试的身份系统或提供商门。
将许可与完成分开
批准仅允许指定的操作。执行日志分别记录尝试的工作、提供程序结果、结果配置和后置条件证据。超时会产生不确定的结果，而不是允许重复可能完成的突变。在决定是否需要重试之前先读取目标状态。
假设提供商报告成功，但授权后检查发现错误的有效值。记录验证失败，未完成。这个假设的案例说明了地位的区别；这里没有执行写入或后检查。真正的验证应该将权威DNS与批准的记录进行比较，并执行预期的发送路由。 DMARC 需要经过身份验证的对齐标识符； DNS记录的存在并不能证明该结果。看 RFC 9989 在 标识符对齐.
提供停止和恢复路径
定义谁可以停止工作流程以及谁批准恢复。回滚是一项单独的相应变更，除非其确切范围已获得批准。保留失败的结果，通知所有者并避免作为通用修复削弱域范围的策略。将批准和证据保留在访问控制历史记录中，并保留适当的保留期限。此设计是供应商中立的，并且不断言EmailAuth实现了这些门。
主要阅读： OWASP LLM06 2025 过度代理, RFC 9989 DMARC.