Subdomain Monitoring

Subdomain Monitoring is a passive subdomain monitoring tool for domains you own. Each run it finds new subdomains in public certificate transparency logs, checks DNS records, tracks SSL certificate expiry, records the HTTP status and page title of each live host, and flags dangling CNAME records that could allow a subdomain takeover. It compares the result with the last run and reports only what changed, as dataset rows and an email-ready HTML digest. Use it for lightweight attack surface monitoring without running scanners yourself.

What does Subdomain Monitoring do?

It answers one question on a schedule: "what changed on my domain since last time?" You give it the apex domains you own. It proves ownership through a DNS TXT record on every run, discovers hosts from certificate transparency (crt.sh and Cert Spotter), resolves A, AAAA, CNAME, MX, NS and TXT records, reads each certificate's expiry date with one TLS handshake, and makes one HTTP GET per live host. The first run stores a baseline. Later runs output only new subdomains, DNS changes, certificate changes, SSL expiry alerts, HTTP status or title changes, and subdomain takeover candidates.

Who is this subdomain monitoring tool for?

• Small IT teams and solo admins who want SSL expiry notifications and DNS change tracking without a platform contract.
• MSPs and agencies that need one weekly digest across many client domains.
• Security people who want to automate subdomain monitoring of their own external attack surface with a passive, low-noise feed.

How to verify that you own the domain

Scanning is refused unless this record exists. It is checked again on every run, so removing it stops monitoring.

1. Pick a random token, 16 to 64 letters, digits, - or _. Example: your-random-token-here.
2. Add a TXT record:
   • Name: _shipsatnight-verify.example.com
   • Value: domain-change-digest-verify=your-random-token-here
3. Put the same token in the verificationToken input. The saved Tasks ship with a placeholder token; the run refuses it until you replace it.

If the record is missing, wrong, or the lookup fails, the domain is not scanned and not charged. When at least one other domain in the run verifies, a verification_failed row explains what to fix. Your token is never printed in rows, the digest, or logs. If no domain passes, the run ends with a status message, nothing is charged, and no dataset rows are written.

What it checks (and what it never does)

Check	How	Limit
New subdomains	certificate transparency logs: crt.sh and Cert Spotter public APIs	500 hosts per domain
DNS change monitoring	A, AAAA, CNAME, MX, NS, TXT via public resolvers	per host
SSL certificate expiry monitoring and validity	one TLS handshake on port 443, fully validated against the host name (trusted chain, not expired, name match)	live hosts only
HTTP status and title	one GET to https://host/ with the same certificate validation, one GET to http://host/ only if HTTPS cannot connect at all, redirects not followed. No HTTPS page check when the certificate is invalid	64 KB read
Subdomain takeover monitoring	CNAME target returns NXDOMAIN, or the response matches a known "unclaimed" page for that CNAME's service	passive only

It never does port scans, IP or CIDR range scans, vulnerability templates, exploit attempts, or login attempts. Only hosts under a verified apex are touched. Requests identify themselves with the user agent domain-change-digest/0.1 (+https://apify.com/shipsatnight).

Limits:

• At most 500 hosts per domain per run.
• At most one scan per domain per UTC day, tracked in the domain-change-digest-state store in your own Apify account. Extra runs are skipped and not charged. A best-effort lock stops two runs from scanning the same domain at the same moment.
• The daily limit can be reset: deleting the domain-change-digest-state store, or running from another Apify account, starts fresh. The lock is best effort, not a guarantee.
• Charges are per domain, not per run: each domain that delivers changes is one domain-digest event.
• Run timeout: at least 60 seconds plus 90 seconds per domain. A shorter timeout stops the run at the start, with nothing scanned or charged. The default of 3,600 seconds covers at most 39 domains. For 40 to 50 domains, raise it to at least 60 + 90 x (number of domains) seconds, for example 4,560 seconds for 50: in Apify Console open the Actor or Task, go to Run options (Settings on a Task), and set Timeout; through the API, pass timeout in seconds when you start the run. The saved MSP Multi-Domain Digest Task already uses 4,560 seconds.

Hosts that resolve only to private, loopback, link-local or cloud metadata addresses are never contacted; only their DNS records are tracked. Every TLS and HTTP connection goes to the IP address that was already resolved, so a DNS change between lookup and connection cannot redirect it.

Input example

{
  "domains": ["example.com"],
  "verificationToken": "your-random-token-here",
  "expiryWarningDays": 30,
  "maxHostsPerDomain": 500,
  "checkHttp": true
}

Output example

For each domain that has changes, the dataset gets one domain_digest row (the paid row, which holds every change in changes) plus one row per change for easy filtering:

{
  "domain": "example.com",
  "host": "old.example.com",
  "changeType": "takeover_candidate",
  "severity": "high",
  "field": "CNAME",
  "before": null,
  "after": "gone-app.herokuapp.com",
  "message": "Possible subdomain takeover on old.example.com: CNAME points to gone-app.herokuapp.com, which does not resolve (NXDOMAIN). Remove the DNS record or reclaim the resource.",
  "detectedAt": "2026-11-04T21:00:00.000Z"
}

Change types: baseline_created, subdomain_new, host_removed, host_not_public, host_started_resolving, host_stopped_resolving, dns_changed, cert_changed, cert_invalid, cert_expiring, cert_expired, http_status_changed, http_title_changed, takeover_candidate, takeover_cleared, verification_failed, skipped_daily_limit, run_locked, host_cap_reached, source_error.

Certificate problems (expired, self-signed, untrusted chain, or a certificate for another name) are reported as a high-severity cert_invalid row, never as healthy.

The key-value store also gets OUTPUT_HTML (an email-ready digest you can send with an Apify integration) and SUMMARY. State lives in a named key-value store domain-change-digest-state in your own Apify account, so the diff survives between runs.

Pricing

Pay per event. Price at launch:

What	Price at launch
One domain scanned, with at least one change delivered (event domain-digest)	$0.50
Domain scanned, nothing changed since the last run	$0
Domain that fails ownership verification	$0
Domain skipped by the one-run-per-day limit or because another run holds it	$0

Example arithmetic only: if 10 domains each had changes on 4 weekly runs in a month, that would be 40 x $0.50 = $20. Quiet weeks cost nothing.

Charging and delivery happen in one step: the domain's domain_digest row is saved together with its domain-digest charge, so you never pay without getting the digest. If your maximum spend per run is reached, that domain's changes are not delivered and not charged; they are kept and reported on the next run, and remaining domains are skipped.

How to automate subdomain monitoring

1. Add the TXT record and run once to store the baseline.
2. Create a schedule (Apify Console, Schedules) weekly or daily.
3. Add an email or Slack integration that sends OUTPUT_HTML, or read the dataset by API. See Apify schedules and integrations.

Ready-made saved inputs: Weekly Subdomain Monitor, SSL Certificate Expiry Alerts, Subdomain Takeover Check, MSP Multi-Domain Digest.

How does this compare with other approaches?

Approach	Setup	Ongoing work	Covers forgotten subdomains	Active scanning
This actor	TXT record and a schedule	none	yes, from certificate logs	no
Calendar reminders for certificate renewals	minutes	manual, per certificate	no	no
Self-hosted open source recon tools on a server	hours	patching, storage, diffing, alerting	yes	often yes
Single-certificate uptime checks	minutes	add each host by hand	no	no
Full external attack surface management platforms	sales process	low	yes	usually yes, priced per asset

FAQ

What is subdomain takeover?

A subdomain takeover happens when a DNS record (usually a CNAME) still points to a third-party service you stopped using, such as a deleted app or bucket. Anyone who claims that resource on the service can then serve content on your subdomain. This actor flags CNAMEs whose target no longer exists and CNAMEs that land on a known "not claimed" page, so you can delete the record.

How do I monitor SSL certificate expiration for all my subdomains?

Run this actor on a schedule with your apex domain. It finds hosts through certificate transparency, reads each live certificate's expiry date, and alerts when one is within your warning window (30 days by default) and again if it expires.

What are certificate transparency logs?

Public, append-only logs that record every publicly trusted TLS certificate. Because almost every HTTPS subdomain gets a certificate, the logs reveal subdomains you may have forgotten. See certificate.transparency.dev.

What is DNS monitoring?

Watching your DNS records for unexpected changes. A changed NS or MX record can mean a hijacked registrar account or a misconfiguration. This actor diffs A, AAAA, CNAME, MX, NS and TXT records per host between runs.

How often do SSL certificates expire?

Public certificates now last at most 398 days, and the CA/Browser Forum approved a schedule that reduces this in steps to 47 days by 2029 (Ballot SC-081). Many free certificates last 90 days. Shorter lifetimes mean more renewals that can silently fail.

What does attack surface monitoring mean?

Keeping an up-to-date list of what you expose to the internet and noticing when it changes. This actor covers the passive part: hostnames, DNS, certificates and basic HTTP responses. It does not scan ports.

Can I monitor a domain I do not own?

No. The TXT verification record is required on every run, and IP addresses and ranges are refused.

Is it safe to run against production?

It is designed to be light. Per live host it makes one TLS handshake and one GET request (a second plain-HTTP GET only if HTTPS cannot connect), with a clear user agent, and it never contacts non-public addresses. A GET can still trigger application logic or show up in your logs and alerts, so turn off checkHttp if any host should not receive requests, and review the first run.

Libraries and sources

• Apify SDK for JavaScript
• Node.js dns and tls modules
• crt.sh and Cert Spotter API for certificate transparency data
• Apify docs: pay-per-event pricing, key-value stores, schedules

Related actors in Apify Store

• Real Subdomain Finder for one-off subdomain discovery
• SSL Certificate Checker for one-off certificate checks

More from shipsatnight

Like Subdomain Monitoring? See Bulk WHOIS, DNS, SSL & Tech Stack Lookup API for one-shot lookups on any list of domains.

Also by shipsatnight:

• Username Availability Checker: GitHub, npm, X
• Security Jobs Monitor: Greenhouse, Lever, Ashby
• Google Trends Scraper: Interest, Regions, Trending

Disclaimer

Findings are hints from public data, not proof of compromise. A takeover candidate means "check this record", not "this is exploitable". Use only on domains you own or administer.