At 3:12 a.m. on a Thursday, a finance manager at a mid-size logistics firm approved a wire transfer to a "new banking partner." The email looked perfect: correct logo, correct signature, correct reply-to address. It sailed past every spam filter because, eleven days earlier, someone had quietly rewritten the company's SPF record from -all to +all, effectively announcing to every mail server on the planet that any host was authorized to send messages as that domain. Nobody noticed. The DNS zone had not been edited in months, so nobody was watching it. The first sign of trouble arrived with the bank's fraud confirmation, by which point the money was gone.
DNS is the control plane for everything your brand does online. Email authentication records (SPF, DKIM, DMARC) decide whether a message claiming to come from your domain is trusted. MX records decide where your mail is delivered. NS records decide who controls the entire zone. These values are plain text, they change rarely, and they are public to anyone in the world who runs a lookup. That combination is exactly why a single unexpected edit is one of the highest-signal events in security: when a record that has been stable for a year suddenly flips, something or someone changed it, and you want to know within minutes, not after the wire clears.
The problem is that DNS records do not live on a web page you naturally visit. They sit in a zone file, queried by resolvers, invisible until you go looking. This guide explains which records to watch, what a malicious change looks like for each one, and how to set up continuous DNS and email-authentication drift monitoring with PageCrawl so a weakened SPF, a rogue MX, or an altered nameserver triggers an alert the moment it happens.
What does DNS and email-authentication drift monitoring actually watch?
DNS drift monitoring continuously re-queries your domain's records and alerts you when any value changes from its last known state. It tracks the email-authentication trio (SPF, DKIM, DMARC) plus the structural records that define your domain: MX (mail routing), NS (delegation), A and AAAA (host addresses), and CNAME (aliases). A change in any of these is the signal.
Unlike registrar-level monitoring, which watches ownership and expiry, DNS drift watches the live operational records that route mail and traffic. The two are complementary. Pairing DNS drift with WHOIS and registrar change monitoring gives you both the lock (who owns the domain) and the wiring (where it points). It also sits alongside certificate transparency log monitoring, which catches unauthorized TLS certificates issued for your name, and broader domain monitoring that watches the whole footprint at once.
The records worth watching, and what each one governs:
- SPF (
v=spf1TXT record): which mail servers may send as your domain. - DKIM (TXT at
selector._domainkey): the public key that signs your outbound mail. - DMARC (TXT at
_dmarc): the enforcement policy and reporting addresses for failures. - MX: the mail servers that receive inbound mail, ordered by priority.
- NS: the authoritative nameservers that control the entire zone.
- A / AAAA / CNAME: where hostnames and subdomains resolve.
Why is a weakened SPF record like +all such a dangerous signal?
A weakened SPF record is one of the clearest indicators of either a misconfiguration or an active attack, because it directly tells the world's mail servers to trust spoofed mail. The most dangerous change is the all qualifier flipping from -all or ~all to +all, which authorizes any server on the internet to send mail as your domain.
What SPF changes should trigger an alert?
SPF lives in a TXT record that begins with v=spf1. The mechanics that matter for monitoring are the qualifier on the final all and the list of authorized senders. Watch for these specific shifts:
-allor~allchanging to+allor?all: the domain now passes spoofed mail. Highest-severity alert.- A new
include:orip4:/ip6:entry you do not recognize: an attacker quietly adding their own sending infrastructure to your authorized list. - The record disappearing entirely: no SPF means weaker spoofing protection across the board.
- SPF exceeding the 10 DNS-lookup limit: the record silently fails to evaluate, so legitimate mail starts failing authentication.
Because these are precise text values, keyword and text tracking is ideal. You set PageCrawl to watch the SPF string and raise a priority alert the moment the substring +all appears or a new include: token shows up.
How do DKIM and DMARC changes expose your domain to spoofing?
DKIM and DMARC changes break the chain that lets receiving servers verify and enforce your identity. DKIM publishes the public key that signs your mail; if that key is swapped or deleted, an attacker can sign forgeries or your legitimate mail starts failing. DMARC sets the enforcement policy, and downgrading it from reject to none quietly disables protection.
What is the DMARC downgrade attack?
DMARC lives in a TXT record at _dmarc.yourdomain.com and looks like v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; pct=100. The p= tag is the policy: reject blocks failing mail, quarantine sends it to spam, and p=none only monitors and enforces nothing. A common stealth move is to flip p=reject to p=none, or to drop pct=100 to pct=10, so only a sliver of mail is enforced. The record still exists, so a casual glance looks fine, but spoofed mail now flows freely.
Two other DMARC edits deserve alerts. First, a changed rua or ruf reporting address: an attacker redirecting your aggregate failure reports to their own inbox to study your mail flow. Second, a relaxed aspf or adkim alignment tag moving from strict (s) to relaxed (r). Because the policy and percentage are discrete values, you can use number tracking on pct (alert when it drops below 100) and keyword tracking on p=none.
What DKIM changes matter?
DKIM keys rotate legitimately, so the goal is to distinguish a planned rotation from a hostile swap. Monitor the public key value (p= in the DKIM TXT record) at each selector you publish. A key that changes outside your rotation schedule, a new selector you did not create, or a removed key that breaks signing are all events worth a same-minute notification. Fullpage content tracking on a DKIM lookup keeps a full history of every key value so you can prove exactly when it changed.
What do MX and NS record changes tell you about a possible hijack?
MX and NS changes are among the most serious DNS events because they can reroute your entire mail flow or hand control of your whole zone to an attacker. A new MX record can silently redirect mail through a server that reads or copies messages, and a changed NS record repoints your domain's authority to nameservers you do not control.
Why MX changes are a mail-interception risk
MX records list the mail servers that receive your inbound email, each with a priority number (lower wins). An attacker who adds a high-priority MX pointing to their own server can intercept mail destined for your domain, a classic man-in-the-middle setup for business-email-compromise. Alert on any MX value that is added, removed, or reprioritized. Because the change is rare and the value is exact, even a slow check frequency catches it, but for high-value domains, a 5 to 15 minute cadence minimizes exposure.
Why NS changes can mean a full zone takeover
NS records delegate authority for your domain to specific nameservers. If those records change to nameservers run by an attacker, every other record (SPF, MX, A, everything) can be rewritten at will, because the attacker now answers all queries for your domain. An unexpected NS change is close to a worst-case event and warrants your highest-priority channel. This is where DNS drift monitoring overlaps with broader brand and domain fraud protection: a hijacked zone is often the first step in standing up convincing phishing infrastructure under your real name.
What is a dangling CNAME and why does it lead to subdomain takeover?
A dangling CNAME is a record that points a subdomain to an external service that no longer exists or has been deprovisioned, leaving the alias resolving to nothing. An attacker who registers that abandoned resource can then serve content from your subdomain, a subdomain takeover. The signal you monitor for is a CNAME whose target stops resolving or changes unexpectedly.
These happen quietly. A marketing team spins up promo.yourdomain.com pointing via CNAME to a SaaS landing-page host, the campaign ends, the SaaS account is closed, but the CNAME stays. The external host frees the resource, an attacker claims it, and now promo.yourdomain.com (a real, trusted subdomain) serves their content. Monitoring the resolved value of each CNAME and alerting when the target changes or starts returning an error catches the window before takeover. The same approach catches A and AAAA records that suddenly point to an unfamiliar IP block, a sign of a hijacked host or defacement.
How do you monitor DNS records when they are not on a normal web page?
You monitor DNS records by pointing PageCrawl at a source that renders the record as readable text or structured data. Three approaches work: a DNS-over-HTTPS (DoH) JSON endpoint, a public DNS-lookup tool page that displays records as rendered HTML, or your login-gated DNS-provider dashboard. Each exposes the exact record values, which PageCrawl then tracks for changes.
Option 1: a DoH JSON endpoint with JSON field tracking
A DoH resolver returns DNS answers as clean JSON. Querying a public resolve endpoint such as dns.google/resolve?name=yourdomain.com&type=TXT returns a structure like:
{"Status":0,"Answer":[{"name":"yourdomain.com.","type":16,"data":"\"v=spf1 include:_spf.google.com -all\""}]}This is the most precise option. PageCrawl's JSON field tracking lets you extract just the data value with a JSONPath expression like $.Answer[*].data, so the alert fires on the record content and ignores noise such as TTL countdowns. If you already use JSONPath filters elsewhere, this is the same mechanism described in monitoring JSON and API fields with JSONPath. Set one monitor per record type (TXT for SPF and DMARC, type 15 for MX, type 2 for NS) by changing the type parameter in the query URL.
Option 2: a DNS-lookup tool page with text or fullpage tracking
If you prefer a human-readable source, point a monitor at a public DNS-lookup tool that displays the record for your domain as rendered HTML. PageCrawl renders the page fully and reliably, then fullpage content tracking or keyword tracking watches the displayed record value. This option is handy when you want a visual record alongside the text, since screenshots are captured by default.
Option 3: login-gated registrar or DNS-provider dashboards
For the authoritative source, the zone editor inside your registrar or DNS-provider dashboard is the ground truth. Login-gated monitoring lets PageCrawl sign in and track the rendered zone records behind the dashboard, catching changes at the source even before they fully propagate to public resolvers. Note: combine this with a public DoH or lookup monitor so you also see what the rest of the internet sees, since propagation and provider-side state can briefly differ.
How do you set up DNS and email-authentication monitoring with PageCrawl?
Setting up DNS drift monitoring takes a few minutes per record. The goal is one focused monitor per record type per domain, each with a tracking mode matched to the data and an alert rule tuned to the malicious patterns that signal an attack. Here is the full sequence.
Step 1: Choose the source and tracking mode. For precision, use a DoH JSON endpoint (for example, a resolve URL returning TXT, MX, or NS answers) paired with JSON/API field tracking and a JSONPath like $.Answer[*].data. For a human-readable trail, use a DNS-lookup tool page with fullpage content tracking or keyword/text tracking. For the authoritative version, use login-gated monitoring on your DNS provider's zone editor.
Step 2: Set the check frequency. Match cadence to value. For your primary sending domain and any domain that handles money or customer data, check every 5 to 15 minutes so an interception window is measured in minutes. For secondary or parked domains, hourly is sufficient. DNS changes are rare, so frequent checks cost little and shorten your detection time dramatically.
Step 3: Pick a notification channel. Route alerts where your security team already lives. PageCrawl delivers to Slack, Telegram, Discord, email, browser push, or a webhook that feeds your SIEM or incident tooling. A webhook is ideal here, because a DNS-record change can auto-open a ticket, page on-call, and attach the before-and-after values in one motion.
Step 4: Keep screenshots on. New monitors capture screenshots by default, and you should leave that on. For a lookup-tool source, the screenshot is a timestamped visual record of the exact record value at each check, which is valuable evidence if you later need to prove when a record changed and what it changed to.
Step 5: Set thresholds and conditional rules. This is where you encode the attack patterns. Use keyword/text rules to alert on +all, ?all, p=none, a missing v=spf1, or any unrecognized include: token. Use number tracking with a threshold and direction to alert when DMARC pct drops below 100 or a TTL is slashed before a planned change. Use availability tracking to fire when a record stops resolving entirely (a deleted DMARC or a dangling CNAME). Conditional rules keep the noise out: you only hear about the edits that matter.
Step 6: Duplicate per record and per domain, then organize with tags. Create one monitor for SPF, one for DMARC, one for DKIM (per selector), one for MX, and one for NS, then repeat the set for every domain you own, including parked and brand-defensive registrations. Tag them by domain and by record type so the whole estate is filterable. If you run many domains, bulk URL monitoring lets you stand up dozens of monitors from a single list instead of one at a time.
Who needs DNS drift monitoring and how does it fit compliance?
DNS and email-authentication drift monitoring matters most for security, IT, and brand-protection teams at any organization that sends email or runs customer-facing domains. It is also increasingly a compliance expectation: frameworks that require continuous monitoring of critical infrastructure and timely incident detection treat unauthorized DNS changes as exactly the kind of event you must catch and document.
For regulated operators, the audit trail is as valuable as the alert. Every check stores the record value and a screenshot, so you can show an auditor the precise moment SPF was weakened or an MX was added, and how quickly you responded. This dovetails with operational-resilience and network-security regimes such as the EU's DORA and the NIS2 directive, both of which expect organizations to detect and evidence changes to critical systems rather than discover them after an incident.
Even outside formal compliance, the economics favor monitoring. A weakened SPF or a rogue MX can underwrite a six-figure business-email-compromise fraud, yet the change itself is a single line of text that flips once and sits there. The cost of watching that line continuously is negligible against what it prevents.
Choosing your PageCrawl plan
PageCrawl's Free plan lets you monitor 6 pages with 220 checks per month, which is enough to validate the approach on your most critical pages. Most teams graduate to a paid plan once they see the value.
| Plan | Price | Pages | Checks / month | Frequency |
|---|---|---|---|---|
| Free | $0 | 6 | 220 | every 60 min |
| Standard | $8/mo or $80/yr | 100 | 15,000 | every 15 min |
| Enterprise | $30/mo or $300/yr | 500 | 100,000 | every 5 min |
| Ultimate | $99/mo or $999/yr | 1,000 | 100,000 | every 2 min |
Annual billing saves two months across every paid tier. Enterprise and Ultimate scale up to 100x if you need thousands of pages or multi-team access.
How do you start DNS monitoring today?
Start by picking your single most important sending domain and standing up two monitors right now: one on its SPF record and one on its DMARC policy, each with a keyword rule for +all and p=none. Point the alerts at your team's Slack or a webhook, leave screenshots on, and set a 15-minute cadence.
The whole setup takes about ten minutes. From then on, the next time someone quietly rewrites a record that has not moved in a year, you find out in minutes, not after the wire clears. Start free, watch the records that protect your name, and turn DNS drift from an invisible risk into a solved problem.
