A recommendation and a DNS write are different events. An analyst may correctly identify an authentication problem and still change the wrong zone, overwrite a newer record or apply a proposal the owner never approved. Put the approval boundary in the execution service, where it can reject an invalid request even if the model asks confidently.
Describe the complete proposed operation
Capture the provider account, tenant, zone, exact owner name, record type, current record set, proposed record set and relevant TTL changes. Include a business explanation and the affected sender. Distinguish adding one record from replacing the complete set at that owner name. A provider API that accepts a request does not necessarily preserve unrelated values automatically.
Represent the proposal in a deterministic form and calculate a digest over the approved fields. Associate it with an authenticated approver, expiry, permitted execution count and a durable change ID. A digest protects equality, not authority: anyone can calculate a hash. The approval record must come from a trusted identity and remain protected from modification.
Recheck immediately before execution
Read current state using the same account and zone the writer will use. Compare it with the approved baseline and verify that approval still covers the proposed diff. Reject wrong-tenant, expired, changed-payload and already-consumed approvals. Where the provider supports conditional updates, use them to reduce the race between checking and writing. Without that support, serialize relevant changes and disclose the residual race rather than claiming atomicity.
OWASP Excessive Agency recommends limited functionality, least privilege and human approval for consequential actions. These particular approval fields are an operational design derived from that principle, not fields mandated by MCP. MCP security guidance also requires scrutiny of authorization and downstream trust.
Test the boundary before granting writes
For written plan MCP-DNS-01, assume provider account A, tenant A, zone example.test, owner _dmarc.example.test, type TXT, TTL 300, baseline v=DMARC1; p=none and proposed v=DMARC1; p=quarantine. This is plan structure, not a recommendation to publish or an approval. Actual approver identity, digest, expiry, execution count and provider preconditions are not supplied.
- Matching target, payload and baseline with all valid protected approval fields: eligible for the supported execution check, not already successful.
- Tenant B substituted, stale baseline, altered desired value, expired approval or consumed single-use approval: deny under the proposed guard.
- Simulated API-success premise but readback differs: mark verification_failed and stop further mutation; the response cannot close the change.
- Timeout after submission: outcome unknown. Reconcile effective state and operation records before deciding whether retrying is safe.
These are written expected states, not an executed guard or MCP deployment. A real integration must test record-set behavior, error responses, conditional updates and retry semantics in an authorized nonproduction zone. Keep write capability disabled until its behavior and approval boundary are verified.
Verify the mail consequence
Check authoritative record state and relevant resolver observations, then exercise authorized test messages through the affected sender. For DMARC, evaluate authentication and alignment with the visible From domain, not just TXT syntax. RFC 9989 defines that relationship. Record what was observed and what remains untested.
If verification fails, stop further writes and escalate against the preapproved recovery plan. Rollback can itself overwrite a legitimate concurrent change, so it needs a fresh state check. Keep approval, request, provider response, readback and mail tests together. The operational end state is verified success, verified recovery or an explicit unresolved incident, never a vague completed label.