1. Identify the original changeset and confirm which record changes caused the problem.
2. Read the current zone and compare it with the before-and-after evidence for that changeset.
3. Check for later legitimate edits, provider drift, ownership changes or a migration that could make an automatic reversal conflict with the current service.
4. Keep a current export or backup so the recovery attempt itself has a clear starting point.
5. Submit the revert request with the required idempotency key only when the reviewed recovery action is appropriate.
6. Follow the returned task and inspect provider readback, authoritative answers and affected website or mail behaviour.

The target may have changed since the original action, a provider may no longer support the same operation, or the record may now be protected by an ownership or lifecycle condition. A conflict is useful evidence that the saved inverse is not automatically safe to apply.

When only one value needs correction, a fresh explicit changeset based on the current zone may be clearer than reverting a broad earlier change. Review both approaches and choose the smallest accurate recovery for the actual incident.

No. Even after authoritative DNS is restored, recursive resolvers may retain a previously cached value until its applicable TTL expires. Verify the authoritative result first, then distinguish remaining caching from an unresolved provider error.

If the revert request times out, inspect its existing task before sending another mutation. Keep the original and recovery references together so support can reconstruct what was intended and which changes actually reached the provider.

• Build and validate a reviewable DNS changeset
• Approve a current backup restore preview before changing DNS
• Investigate DNS drift and request a fresh provider reconciliation
• Prepare a reversible DNS change with an exact before-and-after record list