Why monitor DNS separately?
DNS problems are among the hardest outages to diagnose because they often affect only some users, some record types or some services. A DNS monitor checks the records directly, so you learn about a change even before caching makes it visible everywhere.
Situations DNS monitoring catches:
- Accidental edits. Someone changes an A record during a migration and points the site at an old server.
- Email routing breaks. MX records are removed or replaced when switching mail providers, and mail starts bouncing.
- Lost sender authentication. An SPF or DMARC TXT record is overwritten, and your emails begin landing in spam.
- Delegation changes. Nameserver (NS) records change at the registrar, which can signal a misconfiguration or a hijack.
- Unauthorized changes. A compromised DNS account redirects traffic elsewhere while the old server still looks healthy.
A website monitor will eventually notice some of these, but only once the change has propagated and only for the hostname it checks. DNS monitors watch the records themselves, including ones that no HTTP check would ever touch, such as TXT and MX.
DNS monitors work alongside website monitoring and domain-expiry monitoring to cover the full path from the domain registration to the page.
Supported record types and expected answers
Uptime Tracker resolves the record you choose and, if you set an expected answer, fails the check when the response does not match. Without an expected answer, the check fails only when the lookup itself fails.
| Record | Plan | What to monitor |
|---|---|---|
| A / AAAA | Free | The IPv4 / IPv6 address your site or API should point to |
| CNAME | Free | Aliases pointing to a CDN, platform or SaaS provider |
| MX | Free | Mail servers for your domain |
| TXT | Free | SPF, DMARC and domain verification records |
| NS | Starter | The nameservers your domain is delegated to |
| SRV | Starter | Service records for SIP, XMPP, game servers and others |
| PTR | Starter | Reverse DNS for mail server IPs |
Expected answers are most useful for records that should rarely change: the A record of a server with a fixed IP, the MX hosts of your mail provider, your SPF record. For records that change by design, such as A records behind a CDN that rotates addresses, leave the expected answer empty and just alert on lookup failures.
When a check fails, the normal two-consecutive-failure confirmation applies before an incident opens, which filters out a single slow resolver response.
Protecting email deliverability with DNS checks
Email depends more on DNS than almost anything else, so a handful of DNS monitors is the simplest way to protect deliverability. A missing MX record means inbound mail bounces; a broken SPF or DMARC record means outbound mail is more likely to be rejected or filtered as spam.
A sensible set of monitors for a domain that sends and receives email:
- MX on
example.comwith the expected mail host of your provider. - TXT on
example.comwith an expected answer containing your SPF record, which starts withv=spf1. - TXT on
_dmarc.example.comwith your DMARC policy, which starts withv=DMARC1. - PTR on your mail server's IP on Starter, if you run your own outbound mail server.
On Team you can add SMTP and IMAP checks that verify the mail server banner and TLS without logging in; see port and protocol monitoring. Together these cover routing, authentication and server availability.
These checks are particularly valuable for small businesses, where a single DNS edit by a web designer or hosting provider can quietly stop email for days.
Set up a DNS monitor
A DNS monitor can be added in about a minute on any plan.
- Sign in and create a new monitor with the type DNS.
- Enter the name to resolve, such as
example.comor_dmarc.example.com. - Choose the record type: A, AAAA, CNAME, MX or TXT on any plan, or NS, SRV or PTR on Starter and Team.
- Optionally enter the expected answer. Leave it empty for records that change by design.
- Set the interval and alert channels, and add a tag such as
dnsfor routing.
Record changes you make yourself will trigger the monitor if you pinned the old answer. Update the expected answer as part of the change, or schedule a short maintenance window while the change propagates.
If you manage DNS for many domains, create monitors in bulk with CSV import or the REST API. Tag them by domain or client so routing rules can send DNS alerts to whoever manages that zone. Start with the records that would cause the most damage if changed: MX, SPF and the A record of your main site.
What's included on each plan
DNS monitoring of the five most common record types is free; Starter adds NS, SRV and PTR records.
| Free | Starter | Team | |
|---|---|---|---|
| A, AAAA, CNAME, MX, TXT | Yes | Yes | Yes |
| NS, SRV, PTR | No | Yes | Yes |
| Expected answer matching | Yes | Yes | Yes |
| Domain-expiry monitors | No | Yes | Yes |
| Standard monitors | 2 | 10 | 50 |
| Fastest interval | 5 minutes | 60 seconds | 30 seconds |
The free record types cover the checks most sites need: the address your site points to, aliases to a CDN, mail routing, and SPF or DMARC. Starter is worth it if you want to watch nameserver delegation, which is one of the clearest early signs of a hijacked or misconfigured domain, or if you run services that rely on SRV records or reverse DNS for a mail server. Free's two standard monitors are shared with website checks, so watching several records usually calls for Starter's 10.
Starter also adds domain-expiry monitors, which pair naturally with DNS checks: one watches the records, the other the registration they depend on. See the pricing page for all limits.