Playbook
    dns
    medium

    Investigate an unexpected DNS change

    Lemwatch detected your A, NS, MX, or CNAME record changed. Walk through whether it was intentional or an attack.

    15 minutesLast reviewed 2026-06-09

    What is happening

    Lemwatch hashes your DNS records on every check and alerts when the hash changes. Most changes are intentional (you moved hosts, added MX records, rotated nameservers). A small minority are unintentional — registrar account takeover, DNS hijack, or a teammate making changes without telling you.

    Triage in 4 questions

  1. Did anyone on the team make a change in the last 24h? Ask in Slack first. ~90% of alerts resolve here.
  2. Does the new record point somewhere you recognize? Compare the new IP / nameserver against your hosting provider's documented endpoints.
  3. Is your registrar account still secure? Log in, check the audit log, confirm 2FA is enabled, rotate the password if anything looks off.
  4. Is the new record causing outages or email loss? If yes, treat it as a P1 incident regardless of cause.

    5. If it was unauthorised

  5. Lock the registrar account. Enable registrar lock + DNSSEC.
  6. Revert the record to its last-known-good value (Lemwatch keeps the hash history).
  7. Rotate every credential that lived in the affected mailbox or app.
  8. File an abuse report with your registrar — they keep audit trails that may identify the actor.

    9. Common gotchas

  9. Auto-renewal flipped nameservers. Some registrars reset DNS to defaults when a domain auto-renews.
  10. CDN migration changed A records to CNAMEs. Expected if you just turned on Cloudflare orange-cloud.
  11. MX records changed by Google/Microsoft setup wizard. Expected if you added Workspace or M365.

    12. What this doesn't do

    This playbook is for investigating a *single* unexpected change. For ongoing DNS health monitoring (TTL, DNSSEC, propagation), see DNS health basics.

    All playbooks