How to respond to a DNS change alert
A DNS change alert means a monitored record changed - it does not, by itself, mean something is wrong. Many changes are legitimate. The job is to confirm quickly whether this one was expected, and to act fast when it was not. Use these steps in order.
Response steps
Note the record and the time
Read which record changed (A/AAAA, MX, NS, or TXT), the new value, and when the change was observed.Check for expected work
Match the change against recent work: a site migration, a new email or marketing provider, or a verification record someone added.Confirm with the person who may have made it
DNS is often shared. Ask the developer, agency, or host whether they made the change before assuming a problem.Escalate to your DNS provider if unexpected
If no one can account for the change, contact the DNS provider to review and restore the correct value.Record the resolution
Note what changed, who authorized it, and the outcome so the next alert is faster to triage.
What each record affects
Knowing what a record does tells you how urgent the change is:
- A / AAAA - where your domain points. A wrong value can send visitors to the wrong place.
- MX - mail routing. A change here can quietly interrupt email delivery.
- NS - name server authority. An unexpected change is significant and worth immediate review.
- TXT - policy and verification (SPF, DKIM, ownership proofs). Removal can affect deliverability or verification.
If the changed record is MX or NS and you cannot tie it to planned work, treat it as time-sensitive: email and routing are the two failures customers notice fastest.
| Record | Common expected change | Review priority |
|---|---|---|
| A / AAAA | Host, CDN, or platform migration | High if website traffic is affected |
| MX | Email provider migration | High because mail delivery may stop silently |
| NS | Registrar or DNS provider migration | High because authority moved |
| TXT | SPF, DKIM, ownership, analytics, or service verification | Medium unless email or verification fails |
Common legitimate reasons for a change
Most alerts you receive will have a perfectly good explanation. Recognizing the usual causes lets you clear an alert with confidence instead of guessing:
- A new email provider - switching to a hosted mailbox updates MX and often TXT records (SPF and DKIM).
- A site migration - moving hosts changes A/AAAA values to point at the new server or platform.
- A new tool or service - analytics, verification, and security tools frequently ask you to add a TXT record.
- A CDN or proxy - putting a content network in front of your site changes where the domain resolves.
In each case the right action is the same: confirm the change matches work someone intended, note who authorized it, and mark it expected. The point of monitoring is not to treat every change as a problem - it is to make sure no change goes unreviewed.
Keep a short change log
After you resolve an alert, write one line: the record, the new value, who authorized it, and the date. Over time this log becomes the fastest way to triage future alerts, because most "unexpected" changes turn out to match something already recorded. It also makes handovers easier when a new person takes over the website or DNS.
Good DNS alert notes are specific enough for a provider support ticket:
example.com MX changed from old mail provider to new mail provider on 2026-05-14; expected migration; approved by owner.www A record changed after hosting migration; developer confirmed; website response checked after change.NS record changed without matching project; escalated to registrar and DNS provider.
Avoid vague notes like "DNS changed" or "fixed." They do not help the next person decide whether a future alert is related.
When to contact your DNS provider
Contact your DNS provider when a record differs from your approved configuration and no one on your side authorized it, when name server authority changed without a migration you planned, or when email routing changed and delivery is affected. The provider can confirm the current record and restore the intended value. Monitoring detects and reports the change; the provider performs the correction.
When you reach out, bring specifics: the exact record, its previous and current values, and the time the change was observed. A provider can act far faster on a precise report than on "our email stopped working." This is another reason the alert and your change log are worth keeping together - they hand you the exact details a support ticket needs.
Keep DNS monitored
ostr.io WebSec detects DNS record changes and is presented as free for users on all plans. With monitoring on, every change is timestamped and routed to someone who can validate it.
Related: DNS monitoring · Domain monitoring · Domain monitoring checklist