An unexplained DNS change can come from an authorised deployment, an automation error or account compromise. Preserve the evidence and identify the responsible control plane before making broad changes that could erase the audit trail.
IN THIS ARTICLE
Information to have ready
Record the affected names, types, observed values and time. Capture the current authoritative answers and retain a previous known-good inventory. Determine whether the registrar delegation changed or only records inside the existing authoritative provider changed.
01 Review unexplained DNS changes and recover control of the authorised account
- Sign in through the known provider address using a trusted device. Review administrator access, active sessions, API credentials and available DNS audit or activity logs.
- Compare the change with approved staff work, scheduled integrations and provider notifications. An automation token can make legitimate-looking changes even when no person used the dashboard.
- If access is compromised, secure the recovery mailbox and provider account, revoke affected sessions or credentials and enable supported stronger authentication. Coordinate team access so recovery does not lock out the legitimate owner.
- Restore the exact authorised records and delegation in a controlled order. Check MX, verification records, nameservers, DS and certificate-validation delegations as well as the visible website A record.
- Review dependent services for misuse and replace affected credentials where needed. Keep exported logs and record the corrective changes and validation times.
Verify the authoritative DNS result
Query the actual parent delegation and every authoritative server, then test website, email and important integrations. Confirm the corrected account no longer exposes the compromised access path.
Troubleshoot unexpected results
An empty activity log is not proof that no change occurred; retention and logging coverage differ. Escalate with record values, timestamps, provider account identifiers and redacted evidence. Do not post API secrets in a support ticket.
A common question
Should I restore the whole old zone immediately after spotting one suspicious record?
First understand the incident and recent legitimate changes. A full restore may remove valid mail, verification or application updates. Restore a trusted complete state when required, or reverse the exact unauthorised changes when that is sufficient, while securing the account that allowed them.