← Blog · October 2026

Azure DNS Monitoring: Alert on Record Changes Before They Cause Outages

Azure DNS gives you no change alerts by default. Here's how to fix that.

Azure DNS is a reliable, low-latency hosting service for DNS zones — but it doesn't send you notifications when records change. An unauthorized A record update, an accidental MX record deletion, or a misconfigured CNAME during a deployment can go undetected for hours until users report the outage.

This guide covers the three main approaches for Azure DNS monitoring: Azure Monitor activity log alerts, Event Grid-based automation, and external DNS change detection.

Why Azure DNS has no built-in change alerts

Azure DNS is a data-plane service — it answers DNS queries. Changes to DNS records (A, AAAA, CNAME, MX, TXT, NS, PTR) happen through the Azure Resource Manager control plane. Azure doesn't treat these changes as events that need notification by default.

The practical consequence: if someone in your organization (or an automated deployment pipeline) changes an A record pointing to the wrong IP, you won't hear about it from Azure. You'll hear about it when users can't reach your service.

Method 1: Azure Monitor activity log alerts

Every Azure DNS zone write operation is logged in the Azure Activity Log. You can create an alert rule that fires when any record set in a zone is created, updated, or deleted.

Setting up an activity log alert for DNS changes

Go to Azure Monitor → Alerts → Create alert rule
Under Scope, select your DNS zone resource (e.g. mycompany.com)
Under Condition, select Activity log — Administrative
Filter by:
- Operation name: Microsoft.Network/dnsZones/recordsets/write
- Or add a second condition for Microsoft.Network/dnsZones/recordsets/delete
Under Actions, configure an action group (email, SMS, webhook, Logic App)
Name the rule and create it

This catches any change to any record set in the zone — creation, modification, or deletion — and alerts within 5 minutes.

⚠️ Scope matters: zone vs. subscription If you scope the alert to a subscription, you'll get alerts for all DNS zones in that subscription. Scope it to a specific zone for fine-grained control per domain.

You can also configure this via Azure CLI:

# Create an action group (email notification)
az monitor action-group create \
  --resource-group YOUR_RG \
  --name dns-alert-group \
  --short-name dns-alerts \
  --action email admin admin@yourcompany.com

# Create the activity log alert
az monitor activity-log alert create \
  --resource-group YOUR_RG \
  --name "DNS Record Change Alert" \
  --scope "/subscriptions/SUB_ID/resourceGroups/YOUR_RG/providers/Microsoft.Network/dnszones/yourdomain.com" \
  --condition category=Administrative \
    operationName=Microsoft.Network/dnsZones/recordsets/write \
  --action-group dns-alert-group

Method 2: Event Grid for real-time DNS change automation

Azure Event Grid can route DNS zone events to Azure Functions, Logic Apps, or webhooks in near-real-time (typically under 1 minute). This is useful if you want to:

Log all DNS changes to a database or SIEM
Trigger automated validation (check that the new A record resolves correctly)
Post notifications to Slack or Teams via a webhook
Require approval before DNS changes take effect (using Logic App approval flows)

Setting up Event Grid for DNS zone events

# Subscribe to DNS zone events via Event Grid
az eventgrid event-subscription create \
  --name dns-change-subscription \
  --source-resource-id "/subscriptions/SUB_ID/resourceGroups/YOUR_RG/providers/Microsoft.Network/dnszones/yourdomain.com" \
  --endpoint https://your-function-or-webhook.azurewebsites.net/api/dns-change \
  --included-event-types Microsoft.Network.RecordSetsWritten \
    Microsoft.Network.RecordSetsDeleted

The webhook payload includes the operation type, the record set name, the record type, the initiating identity (which service principal or user made the change), and a timestamp. This gives you a full audit trail of DNS changes with actor attribution.

Method 3: External DNS record monitoring

Azure Monitor activity logs and Event Grid only capture changes made through the Azure control plane — changes initiated via the Azure portal, CLI, ARM templates, or SDK. They don't detect:

DNS propagation anomalies (a record that changed correctly in Azure but is resolving inconsistently across global resolvers)
DNS hijacking (where an attacker redirects your traffic by attacking a registrar or upstream nameserver)
Cases where Azure's DNS service itself experiences an anomaly
Domains hosted on Azure DNS but with delegation problems at the registrar

External DNS monitoring works differently: it periodically queries your DNS records from multiple locations and alerts you if the resolved values change. This is a completely independent check that doesn't require access to your Azure subscription.

Check your current DNS records right now:

🔍 Free DNS Record Checker

Enter any domain to see its current A, AAAA, MX, TXT, CNAME, and NS records — what the rest of the internet sees right now.

Check DNS records → Get DNS change alerts →

Which DNS record types matter most for Azure workloads

Record type	Impact if changed unexpectedly	Priority for monitoring
A / AAAA	Traffic redirected to wrong IP — immediate outage or hijack risk	Critical
CNAME	Service redirected — may cause HTTPS cert errors if CNAME changes	Critical
MX	Email delivery silently fails or routes to wrong server	High
TXT	SPF/DKIM/DMARC validation breaks — email deliverability drops	High
NS	Entire zone delegated to different nameservers — full DNS hijack risk	Critical
PTR	Reverse DNS breaks — affects email reputation checks	Medium

Azure Policy for DNS zone change governance

If you need to prevent unauthorized DNS changes rather than just detect them, Azure Policy and RBAC are the right tools:

RBAC: Use the built-in DNS Zone Contributor role sparingly. Most teams should have read-only access by default; write access should be restricted to specific service principals used in deployment pipelines.
Azure Policy: Create a deny policy for Microsoft.Network/dnsZones/recordsets/write that only permits changes from specific subscription IDs or management group paths.
Resource locks: Apply a ReadOnly lock to critical DNS zones. This blocks all write operations until the lock is explicitly removed — useful for production zones that should rarely change.

Note on resource locks A ReadOnly lock on an Azure DNS zone prevents ALL changes, including legitimate automated deployments. Use selective RBAC restrictions and monitoring alerts rather than blanket locks for most production scenarios.

Combining Azure-internal and external DNS monitoring

A robust Azure DNS monitoring strategy uses both layers:

Activity log alerts — immediate notification when any control-plane change happens, with actor attribution
External DNS polling — independent verification that the actual resolved values are correct, regardless of how or where the change originated

The two approaches catch different failure modes. Activity log alerts tell you someone changed a record. External monitoring tells you what the world currently sees — which is ultimately what matters for your users.

🔍 DNSWatch — automated DNS change alerts for Azure and every domain

DNSWatch monitors your DNS records externally from multiple locations and sends email alerts the moment A, MX, TXT, CNAME, or NS records change. No Azure credentials needed — just add your domains.

Join the DNSWatch waitlist → Free DNS checker →