Home / Blog / DNS Change Alerts: Which Records Matter

Practical guide

# DNS change alerts: which records matter and what to do when they change

Published 3 July 2026 · By the Bryzora team

A practical guide to monitoring A, AAAA, CNAME, MX, TXT, NS, and CAA records and responding to unexpected DNS changes.

Domain Health · Bryzora field notes

DNS tells visitors where to find your site and tells other services where to deliver mail. A mistaken change can affect only part of a business: the website may load while email stops arriving, or a subdomain may point to an old provider.

Monitoring DNS changes gives your team a history of what changed and a chance to react before a small configuration mistake becomes a prolonged incident.

## Start with the records that support customer journeys

- A and AAAA records point names to IPv4 and IPv6 addresses. Watch the main domain and critical subdomains.

- CNAME records point one name to another. These often matter for hosted apps, status pages, and verification flows.

- MX records route email. An unexpected change can interrupt inbound mail.

- TXT records commonly hold verification and email-related settings. The meaning depends on the record and service using it.

- NS records identify authoritative name servers. Changes can affect the entire domain.

- CAA records indicate which certificate authorities may issue certificates for a domain.

You do not need to alert every team member on every record. Decide which records are critical, which changes are planned, and who can confirm whether a change was authorized.

## Keep a baseline before you need it

Record the expected values for important names, including your production site, mail domain, API, and status page. Also note the owner and provider for each value. This makes an alert actionable: “The API CNAME changed from the expected target” is much easier to investigate than “DNS changed.”

During a planned migration, schedule a review of the old and new values. DNS records can be cached for a period determined in part by their TTL, so different users may observe different answers while a change spreads.

## Triage an unexpected alert

First, check whether a teammate or provider made an approved change. Next, compare the new value with the intended configuration and look for related symptoms: failed website checks, certificate errors, or missing email. If the change was accidental, restore the approved value and continue monitoring until the relevant services recover.

If no one authorized it, treat it as a potential security incident. Check registrar and DNS-provider account access, recent change logs, and authentication settings. Do not assume every unexpected change is an attack, but do not dismiss one without an owner.

## Review the history after the fix

A change history helps establish when the record shifted, what it changed to, and how long the wrong value was present. Use that timeline in the incident review and update your change process if the alert was avoidable.

Bryzora’s DNS monitoring tracks record changes and keeps their history. Pair it with website monitoring so you can see both the configuration change and its effect on availability.

← All guides

All guidesNewer guideDomain and SSL expiry: a renewal checklist for teams managing many sitesOlder guideA practical guide to monitoring cron jobs and background workers