A DMARC change request should allow another person to determine exactly what will change, which services could be affected and how success will be demonstrated. A screenshot showing a desired policy is not enough. Preserve the baseline and proposed RRset, then connect them to approved business flows and a recovery decision.
Capture the baseline precisely
Record the DNS provider account or tenant, zone, owner name, record type, complete value and TTL. Include the time and source of the observation. Capture current DMARC policy discovery for affected author domains, plus the approved senders and any unresolved exceptions. Preserve authentication identifiers rather than reducing a test to a dashboard colour.
DMARC can pass through an aligned successful SPF or DKIM result. A message's visible From domain and its authenticated identifiers therefore matter more than a generic statement that SPF passes. RFC 9989. For domains publishing p=reject, RFC 9989 sections 7.4 and 8 separately require valid DKIM signatures and forbid reliance solely on SPF; message-level success does not waive that deployment duty. An authentication pass does not certify the business request or ensure inbox placement.
Describe the intended difference
State the exact before-and-after RRsets and affected names. Explain why the change is needed now, which services were tested and which evidence remains incomplete. Keep unrelated DNS edits outside the request so an approver does not accidentally approve a broader operation. Identify the technical implementer, business approver and escalation contact.
If reporting destinations or delegated services change, assess the information flow and dependency separately. Preserve the report intake configuration necessary for the intended monitoring. Aggregate reports are receiver observations with coverage limitations, so they cannot be the only acceptance signal for a time-critical legitimate flow. RFC 9990.
Write observable acceptance criteria
Use criteria that can fail: the authoritative RRset equals the approved value; representative critical messages use the intended identities and authenticate as expected; the business recipient confirms the expected outcome; and report intake continues. Record observation times and distinguish immediately available tests from later report review. A report that has not arrived yet is not a passed test.
Define recovery triggers before implementation. If a critical flow fails and diagnosis links it to the approved change, invoke the approved recovery plan. Preserve the old state and explain its limitations. Restoring a policy does not instantly reverse cached DNS or recall messages already rejected. Plan observation beyond the nominal maintenance window.
Test whether a request can actually close
Suppose a hypothetical request changes only the policy for a payroll From domain from p=none to p=quarantine while retaining its reporting destination and TTL. The review must still bind the complete baseline and proposed RRset, target account and domain, approved payroll scope and recovery plan. No real payload, approval or DNS change is supplied here.
Assume an authorized post-change observation matches the approved DNS state and a representative payroll message authenticates as expected, but the business recipient has not confirmed receipt and the next aggregate report is not yet available. Record configuration and authentication checks separately from those pending outcomes. Assign receipt follow-up to the payroll owner and delayed intake review to the reporting owner; do not close all acceptance criteria on the strength of a matching record. These are hypothetical findings, not executed checks.
The change workflow above is an operational recommendation, not a protocol requirement. NIST SP 800-53 Rev. 5 controls CM-3 and CM-5 provide a general basis for reviewing, approving and restricting changes; the exact payload binding, roles and handoff fields here are the proposed implementation. NIST control catalogue.