What Is DNS Monitoring and How It Works

DNS (Domain Name System) records control critical aspects of your domain's functionality—from where your website points to how your email is delivered. Unexpected DNS changes can cause website downtime, email delivery failures, or even indicate security issues like DNS hijacking. Domainyze's DNS Monitoring helps you detect and respond to unauthorized or unexpected DNS changes immediately.

How It Works

DNS monitoring is a paid capability for domains within your Portfolio monitoring type (Pro and Business plans).

1. Initial DNS Snapshot: When you add a domain to your Portfolio, Domainyze performs a comprehensive lookup to capture your current records: the apex set (A, AAAA, MX, NS, TXT, CAA, SOA), your email-authentication records (SPF, DKIM at each discovered selector, DMARC at _dmarc), and well-known names like www and _acme-challenge.
2. Tiered Checks: Our system re-queries your records on a schedule that depends on your plan (Business checks more often than Pro), and your nameservers get their own faster lane (see below).
3. Change Detection: Each new check is compared against your stored zone by record identity, so a value edit (for example an IP changing) shows up as a single changed record with its before and after, not as an unrelated removal and addition.
4. Confirmation Before Alerting: A detected change is re-checked against a second, independent resolver. If they disagree, nothing is stored and no alert is sent, which filters out resolver glitches and cache poisoning that would otherwise fire a false alarm.
5. Immediate Alerts: Once a change is confirmed, Domainyze notifies you with exactly what changed, grouped by what it affects (mail, delegation, website, and so on).

How selectors are found

DKIM is the one email-authentication record that cannot simply be looked up. SPF lives at your domain and DMARC at _dmarc, both at names everybody knows. A DKIM key lives at <selector>._domainkey.<yourdomain>, where the selector is an arbitrary label chosen by whoever set up your mail — and DNS offers no query that lists the selectors in use. There is no way to ask "which DKIM keys does this domain have". You can only ask about a selector you already suspect.

So Domainyze finds them three ways, and queries the union.

1. Inferred from your MX records. Your mail provider is visible in your MX records, and each provider uses predictable selectors. If your mail goes to Google Workspace we look for google; Microsoft 365 uses selector1 and selector2; and we carry the same mapping for Postmark, SendGrid, Mailgun, Amazon SES, Zoho, Fastmail, Mailchimp, Mandrill and Proofpoint. Matching is on the hostname suffix, so alt1.aspmx.l.google.com resolves to Google correctly.

2. A sweep of common selectors. Independently of your MX records, we periodically probe a list of selectors that are common across hosted mail: google, selector1, selector2, k1, s1, s2, mail, dkim, default, smtpapi, pm and zmail. Once a selector has been found on your domain it is re-queried on every check; the full sweep runs only occasionally, so steady-state cost stays at one query per key you actually have rather than one per guess.

3. Selectors you declare. If you sign your own mail with a bespoke selector, no amount of probing will find it. Add it in the domain's DNS preferences and we query it on every check from then on, immediately rather than waiting for the next sweep. This is the only way a self-hosted selector gets monitored.

Every check records which selectors it queried. That is what makes "no DKIM found" different from "we did not look": the domain's DNS view lists the selectors that were checked, so an absent DKIM grade is a statement you can verify rather than one you have to trust. If your selector is not on that list, declare it.

Once a key is found, it is monitored like any other record: rotating a key is reported as a change, and a key disappearing is reported as a removal.

Security Use Case: Detecting "Shadow IT"

A major risk for large organizations is Shadow IT—when individual employees or developers create subdomains or point CNAME records to external services (like Trello, Slack, or AWS buckets) without the IT department's knowledge.

• Unintended Exposure: These subdomains often lack proper security controls and can become entry points for attackers.
• Dangling CNAMEs: If an external service is discontinued but the CNAME remains, an attacker can claim that service and take control of your subdomain.
• Domainyze's Role: By maintaining a DNS History, Domainyze allows you to audit every new record added to your zone, ensuring that every subdomain is authorized and secure.

Preventing Silent Email Interception

Most attackers who hijack a domain don't take the website down immediately. Instead, they perform a Silent Hijack by modifying MX (Mail Exchange) or TXT (SPF/DKIM) records.

• The Goal: To redirect incoming emails to their own servers to reset passwords or steal sensitive data.
• The Risk: Because the website stays up, these changes can go unnoticed for weeks.
• Domainyze's Solution: We monitor MX alongside all three email authentication records: SPF, DKIM and DMARC. If an unauthorized mail server is added, an SPF policy is weakened, or a DMARC policy is relaxed so the interception is no longer rejected downstream, the change is confirmed and alerted with its old and new values, and it arrives as a dedicated email-authentication change alert, separate from ordinary record churn. We also grade your overall email-auth posture (strong, adequate, weak or absent) so you can see a weakness before an attacker does. See SPF, DKIM & DMARC monitoring.

The Nameserver Fast Lane

Changing your nameservers (the "keys to the kingdom") is the single most dangerous DNS event, because it hands the whole zone to whoever controls the new servers. Domainyze gives delegation its own faster check lane: your NS and SOA records are queried directly against your domain's own authoritative servers (not a cache), as often as hourly on the Business plan. We also compare your live nameservers against the ones your registrar has on record and flag any mismatch, a strong early hijack signal. A nameserver change raises its own delegation change alert.

Why Is DNS Monitoring Important?

• Detect Security Threats: Identify potential DNS hijacking attempts or unauthorized nameserver changes.
• Prevent Email Delivery Issues: Get alerted when MX records change unexpectedly, which could disrupt your email service.
• Avoid Website Downtime: Know immediately if A/AAAA records are modified, potentially causing your website to become unreachable.
• Audit Trail: Maintain a complete history of all DNS changes for compliance and troubleshooting purposes.

Supported DNS Record Types

Domainyze monitors A, AAAA, MX, NS, SOA, TXT, CAA at your apex, your email-authentication records (SPF, DKIM, DMARC) each at their own name, and named records such as www (including its CNAME) and other well-known names. By integrating DNS monitoring, you add a critical layer of infrastructure security that most registrars don't provide.

Note: we do not monitor apex CNAME or apex SRV records, because an apex CNAME is invalid alongside an SOA record and an apex SRV is meaningless. Those record types are still available in the public DNS Lookup tool at any name you choose.

Turning it on

DNS monitoring needs three things, and then it needs no configuration at all:

• The domain is in your Portfolio, not your Watchlist. DNS monitoring is for domains you own.
• Your plan is Pro or Business.
• The domain has publicly resolvable DNS.

Add the domain with Portfolio as its monitoring type and DNS monitoring is enabled automatically. The first check captures the baseline snapshot, which takes a moment, and everything after that runs on the schedule above. You can toggle it off per domain from the domain's settings if a particular name does not warrant it.

Reading your zone in the app

Open the domain from your Portfolio and scroll to the DNS section. Records are grouped into plain-language purpose cards — Delegation for nameservers, Mail for MX plus SPF, DKIM and DMARC, Website for A, AAAA and CNAME, Security for CAA, and so on. Each card carries a health state and a one-line summary. Show records expands the full table with name, type, value, TTL and when the record last changed, and the raw all-records view gives you the flat list.

Three indicators are worth knowing:

• The card health state: healthy, needs attention, critical, or not configured.
• Added / removed / changed markers on individual records. A value edit appears as one changed row with its before and after, not as an unrelated removal plus addition.
• The email-authentication grade on the Mail card: strong, adequate, weak or absent, with the specific findings behind it, such as "DMARC is monitor-only".

Next steps

• Understanding DNS change alerts — what a change alert contains and how severity is decided.
• Viewing DNS check history — the audit trail and how long it is kept.
• Alert delivery channels — where these alerts go.