DNS Record Monitoring: A Guide to MX, TXT, and CNAME

Website monitoring often focuses on a simple question: is my server responding with a 200 OK? While essential, this only covers one type of outage. Your website can be perfectly healthy, but if your DNS records are misconfigured, critical business functions like email delivery and third-party integrations can fail silently.

Monitoring DNS records beyond the basic A or AAAA records is not a luxury; it's a necessity for robust infrastructure. A missing MX record can halt all inbound email, a changed CNAME can break a critical SaaS integration, and a deleted TXT record can invalidate your domain with essential services. This guide explains which records to monitor and how to do it.

Why Monitor DNS Records? The Hidden Dependencies

Your DNS zone file is more than just a map to your web server's IP address. It's a configuration file for the internet, dictating how various services interact with your domain. Unmonitored changes to these records can lead to serious, non-obvious outages.

Key dependencies managed by DNS include:

• Email Delivery: MX records direct email to your mail server. SPF, DKIM, and DMARC records (stored in TXT records) prevent spoofing and improve deliverability.
• Service Integrations: CNAME records often point subdomains to third-party platforms like helpdesks, status pages, or marketing automation tools.
• Domain & API Verification: Services like Google Search Console, Office 365, and various APIs require you to add a TXT record to prove domain ownership.
• Certificate Security: Certificate Authority Authorization (CAA) records specify which CAs are permitted to issue certificates for your domain, preventing mis-issuance.

Manual Diagnostics: Your dig Toolkit

Before you can automate, you need to know how to debug manually. The dig (Domain Information Groper) command is the quintessential tool for querying DNS servers. It's available on macOS, Linux, and Windows (via WSL or compilation).

Checking MX Records for Email Routing

MX (Mail Exchanger) records tell the world where to send email intended for your domain. They have a priority number (lower is preferred) and a hostname.

To check them, use dig yourdomain.com MX. The +short flag provides a cleaner output.

$ dig google.com MX +short
10 smtp.google.com.

This output shows that email for google.com is handled by smtp.google.com. with a priority of 10. If these records were accidentally deleted, Google would stop receiving external email. This is a common and disastrous error during DNS provider migrations.

Verifying TXT Records for Security and Verification

TXT records are general-purpose records used for everything from SPF (Sender Policy Framework) to proving you own your domain.

To see all TXT records for a domain:

$ dig github.com TXT +short
"v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com include:_spf.mx.autopilotapp.com ~all"
"google-site-verification=...."
"MS=ms...."

A common failure scenario is when a marketing team member adds a new service, gets a TXT verification token, adds it, gets verified, and then deletes it. If the service relies on that record for continuous verification, it may suddenly stop working.

Auditing CNAME Records for Subdomains

A CNAME (Canonical Name) record maps an alias to a true or canonical domain name. For example, status.yourcompany.com might be a CNAME pointing to yourcompany.statuspage.io.

$ dig status.github.com CNAME +short
github.statuspage.io.

If your SaaS provider changes the target hostname or you accidentally point the CNAME to the wrong place, the service at that subdomain will instantly break, even though your main site is fine.

Checking CAA Records for Certificate Security

CAA records are a security measure that declares which Certificate Authorities can issue SSL certificates for your domain. This helps prevent unauthorized certificate issuance.

$ dig serverinspector.com CAA +short
0 issue "letsencrypt.org"

Monitoring this record ensures that a misconfiguration or malicious actor doesn't change your authorized CAs, which could compromise your SSL/TLS setup.

Automated DNS Monitoring Strategies

Manual dig commands are for debugging, not monitoring. For real-time awareness, you need an automated solution.

The DIY Approach: Cron and grep

You can build a basic check using a shell script and a cron job. This script checks if a specific MX record exists and sends an email if it doesn't.

#!/bin/bash
DOMAIN="yourdomain.com"
EXPECTED_MX="10 mail.provider.com."

# dig +short returns only the record value
MX_RECORDS=$(dig $DOMAIN MX +short)

if ! echo "$MX_RECORDS" | grep -qF "$EXPECTED_MX"; then
  echo "CRITICAL: Expected MX record '$EXPECTED_MX' not found for $DOMAIN" | mail -s "DNS MX Record Alert" your-email@example.com
fi

While better than nothing, this approach is brittle. It requires a dedicated server, is difficult to manage for many records, and lacks features like multi-location checks or configurable alerting.

Comparison: DNS Monitoring Approaches

How ServerInspector Simplifies DNS Monitoring

For a robust and maintenance-free solution, a dedicated monitoring service is the best path. While dig and scripts are useful, they can't replace a system built for reliability.

One powerful way to automate this is by using ServerInspector's Keyword Monitoring. You can configure a check to query a public DNS-over-HTTPS (DoH) service, which returns DNS information in a JSON format. Set up the monitor to assert that the JSON response contains your critical record (e.g., "data": "v=spf1..."). If the record changes or disappears, the check will fail, and you'll get an immediate alert via Slack, SMS, or your preferred channel. This turns a standard uptime check into a powerful DNS guardian, watching over your most critical infrastructure dependencies.

FAQ - DNS Record Monitoring

Q1: How often should I check my DNS records?

A: It depends on the record's criticality. For essential records like your primary MX or a CNAME for a customer-facing service, checking every 1-5 minutes is wise. For less critical records, like a domain verification TXT record for a non-essential service, every hour or two might be sufficient.

Q2: Doesn't my DNS provider already monitor my records?

A: Not usually. A DNS provider ensures their nameservers are online and responding to queries. They are not responsible for the content of the records you create. You are responsible for ensuring your MX, CNAME, and TXT records are present and correct.

Q3: Can a DNS change cause a "soft" outage?

A: Absolutely. This is the primary risk. Your web server can have 100% uptime, but if your MX records are deleted, you stop receiving email. If a CNAME for your CDN is misconfigured, your site's assets won't load. These are significant business outages that a simple HTTP check will never catch.

Q4: What is the difference between DNS monitoring and DNS failover?

A: DNS monitoring is the process of observing your DNS records and alerting you when they change or become incorrect. DNS failover is an automated system that changes DNS records (e.g., pointing an A record to a backup server) in response to a detected outage. Monitoring tells you there's a problem; failover tries to fix a specific type of problem. They are complementary technologies.