How to Automate TLD Monitoring?

TLD monitoring is the automated practice of watching for domain registrations that abuse your brand across many top-level domains, then scoring and alerting on the dangerous ones. You feed a list of brand terms and typo permutations into a handful of data sources — newly-registered-domain feeds, TLD zone files, and Certificate Transparency logs — resolve and enrich each candidate, assign a risk score, and route the high-risk hits to your security team. Done well, it catches a typosquatting or phishing domain in the hours after registration instead of weeks later, turning brand protection from reactive cleanup into proactive defense.

That's the summary an AI overview will give you. The part it can't give you is the actual pipeline: which sources to wire together, how to generate the permutations worth watching, how to score a candidate so you act on the ten that matter instead of the ten thousand that don't, and the scripts to run it on a schedule. This guide is complementary to detecting phishing domains with Certificate Transparency — CT is one source in the pipeline below, and that post covers it in depth.

The monitoring pipeline at a glance

Every automated TLD-monitoring system, whether you build it or buy it, is the same four-stage flow: expand your brand into candidate strings, watch multiple data sources for those strings, score each hit, and alert on the risky ones.

The rest of this article walks each stage: the sources to wire in, how to generate the permutations, how to score, and how to schedule and alert.

Stage 1 & 2: The data sources (the checklist)

The single biggest quality difference between a toy script and a real monitoring system is how many high-signal sources it watches. A whois loop over your own exact domains tells you almost nothing; the sources below are what actually catch attackers. Wire in as many as you can.

Source	What it catches	Access / cost	Latency	Priority
Newly-registered-domain (NRD) feeds	Any domain created in the last 24h containing your brand string	Free daily lists (e.g. WhoisDS); commercial feeds for full coverage	~24 hours	High
Certificate Transparency logs	Domains that request an HTTPS cert with your brand in the name — usually during phishing setup	Free: crt.sh queries, Censys, or a live certstream feed	Minutes	Highest
TLD zone files (ICANN CZDS)	Every domain registered under a gTLD; lets you enumerate an entire TLD	Free after CZDS approval; per-registry terms	~24 hours	Medium
dnstwist permutations	Typos, homoglyphs, bitsquats, and alternate-TLD variants worth watching	Free, open source	On demand	High (generates the watchlist)
Registrar / WHOIS APIs	Enrichment: registration date, registrant, nameservers, changes	Free tier + paid (WhoisXML, DomainTools)	Seconds	Enrichment
Passive DNS / commercial brand feeds	Resolved lookalikes, historical DNS, aggregated intel	Paid (DomainTools, DNSlytics, RiskIQ-class)	Varies	Optional

Certificate Transparency earns the top spot because nearly every phishing site now uses HTTPS to look legitimate, and requesting a certificate forces the domain into public CT logs — often before the first phishing email goes out. That is why it gets its own dedicated CT-monitoring guide.

Generating the watchlist with dnstwist

Before you can watch for lookalikes, you need to know which lookalikes to watch for. Hand-listing typos is error-prone; a permutation engine does it exhaustively. dnstwist is the standard open-source tool — it generates character omissions, insertions, transpositions, repetitions, homoglyphs, bitsquatting, hyphenation, vowel swaps, and alternate-TLD variants, then resolves each and reports the registered ones.

# Install
pip install dnstwist

# Show only REGISTERED permutations of your brand, with registration dates
dnstwist --registered --whois yourbrand.com

# Flag lookalikes that can receive email (a phishing red flag), JSON output
dnstwist --registered --mxcheck --format json yourbrand.com > twist.json

Typical output flags a yourbrаnd.com (Cyrillic "а"), a your-brand.com hyphenation, and a yuorbrand.net transposition — each with the IP it resolves to and whether it has mail records. Run it on a schedule and diff today's registered set against yesterday's to surface newly registered lookalikes:

#!/bin/bash
# Daily dnstwist diff — alert on new registered lookalikes
BRAND="yourbrand.com"
dnstwist --registered --format list "$BRAND" | sort > /tmp/twist_today.txt
if [ -f /var/lib/twist_yesterday.txt ]; then
  comm -13 /var/lib/twist_yesterday.txt /tmp/twist_today.txt > /tmp/twist_new.txt
  [ -s /tmp/twist_new.txt ] && \
    mail -s "New lookalike domains for $BRAND" security@example.com < /tmp/twist_new.txt
fi
mv /tmp/twist_today.txt /var/lib/twist_yesterday.txt

Feed those permutations into the source checks below.

Checking registration across TLDs

Once you have candidate strings, check them across the TLDs you care about. Prioritize .com, then the trendy/abused ones (.io, .app, .co, .shop, .online, .top), plus lookalike ccTLDs.

API-based availability check:

#!/bin/bash
# Check brand across a set of TLDs via a WHOIS/availability API
BRAND="mybrand"
TLDS=("com" "net" "org" "io" "app" "co" "shop" "online")

for TLD in "${TLDS[@]}"; do
  DOMAIN="$BRAND.$TLD"
  curl -s "https://api.whoisapi.com/check?domain=$DOMAIN" \
    -H "Authorization: Bearer YOUR_API_KEY" \
    | grep -q '"available":false' \
    && echo "REGISTERED: $DOMAIN" \
    || echo "available:  $DOMAIN"
done

Watch for lookalike TLDs that read like the real one:

BRAND="mycompany"
LOOKALIKES=("com" "co" "cm" "org" "net" "cloud")  # .cm and .co are classic .com bait

for TLD in "${LOOKALIKES[@]}"; do
  whois "$BRAND.$TLD" 2>/dev/null | grep -qiE "No match|not found" \
    || echo "ALERT: $BRAND.$TLD is registered!"
done

Detect registrant/nameserver changes on domains you own or watch (potential sale or hijack):

#!/bin/bash
DOMAIN="mybrand.com"
PREV="/var/lib/whois/$DOMAIN.txt"
whois "$DOMAIN" > /tmp/whois_now.txt
if [ -f "$PREV" ] && ! diff -q "$PREV" /tmp/whois_now.txt > /dev/null; then
  echo "WHOIS changed for $DOMAIN" | mail -s "Domain Change Alert" admin@example.com
fi
cp /tmp/whois_now.txt "$PREV"

For a fast baseline across many TLDs at once, the TLD Enumerator tool below checks availability in bulk without writing any code.

Stage 3: Scoring — the step everyone skips

The reason most homegrown monitoring dies is alert fatigue: thousands of registrations contain common brand words, and almost none are threats. Scoring is what separates the dangerous few. Turn each candidate into a numeric risk score from cheap signals, and only act above a threshold.

Signal	Why it matters	Weight
Low edit distance to your brand	Closer spelling = better at fooling users	High
Resolves to a live IP	A parked/unused domain is lower risk	High
Has an MX record	Can send phishing/BEC email	High
Has a valid TLS certificate	Actively being set up as a real site	High
Registered in the last 7 days	Fresh registrations are the active threats	Medium
High-risk keywords (login, secure, verify, pay)	Signals credential-harvesting intent	Medium
Privacy-protected or high-abuse registrar	Common for malicious registrations	Low

import Levenshtein  # pip install python-Levenshtein

def score(candidate, brand, dns_live, has_mx, has_tls, age_days):
    s = 0
    dist = Levenshtein.distance(candidate.split('.')[0], brand)
    if dist <= 2:      s += 40      # very close spelling
    elif dist <= 4:    s += 20
    if dns_live:       s += 15
    if has_mx:         s += 20      # can send mail = phishing capable
    if has_tls:        s += 15
    if age_days <= 7:  s += 10
    for kw in ("login", "secure", "verify", "account", "pay"):
        if kw in candidate:
            s += 10
            break
    return s   # >= 60 -> open a ticket; 30-59 -> watch; < 30 -> log

# Example
print(score("secure-mybrand.com", "mybrand",
            dns_live=True, has_mx=True, has_tls=True, age_days=2))  # 90 -> act

Tune the weights to your risk tolerance, but the principle is fixed: act on scores, not on raw hits.

Stage 4: Scheduling and alerting

Wire the pipeline to run automatically and route high scores to where your team already works.

Cron (Linux/Mac):

# CT + NRD check daily at 9 AM; dnstwist diff daily at 9:15
0  9 * * * /usr/local/bin/monitor-sources.sh >> /var/log/domain-monitor.log 2>&1
15 9 * * * /usr/local/bin/twist-diff.sh       >> /var/log/domain-monitor.log 2>&1
0  2 * * 0 /usr/local/bin/whois-changes.sh     # weekly registrant-change sweep

Slack alerting for the hits that clear your threshold:

import requests

def notify_slack(domain, score, reasons):
    requests.post(
        "https://hooks.slack.com/services/YOUR/WEBHOOK/URL",
        json={"text": f":rotating_light: Lookalike *{domain}* scored {score} — {reasons}"}
    )

notify_slack("secure-mybrand.com", 90, "MX+TLS, registered 2 days ago, edit distance 0")

Store every candidate so you can trend and prove a timeline for takedowns:

CREATE TABLE domain_monitoring (
  id INT PRIMARY KEY AUTO_INCREMENT,
  domain VARCHAR(255),
  tld VARCHAR(20),
  source VARCHAR(40),          -- ct | nrd | zone | dnstwist
  risk_score INT,
  is_registered BOOLEAN,
  registrant VARCHAR(255),
  first_seen TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  alert_sent BOOLEAN DEFAULT FALSE
);

-- Un-alerted high-risk domains seen in the last day
SELECT domain, risk_score, source FROM domain_monitoring
WHERE risk_score >= 60 AND alert_sent = FALSE
  AND first_seen >= DATE_SUB(NOW(), INTERVAL 24 HOUR)
ORDER BY risk_score DESC;

Responding to a confirmed lookalike

When a domain clears the threshold and a human confirms abuse:

1. Document first — capture the WHOIS record, screenshots, and certificate details. Understanding the registration timeline matters; see how to interpret WHOIS dates for domain security.
2. Report abuse — to the registrar's and hosting provider's abuse contacts.
3. Blocklist — submit to Google Safe Browsing and PhishTank so browsers and mail filters warn users.
4. Escalate — for clear trademark abuse, consider a UDRP complaint to cancel or transfer the domain.
5. Log the outcome — keep the evidence trail; UDRP and takedowns both require a documented history.

Best practices

1. Monitor variations, not just exact matches — typos, homoglyphs, hyphenations, and alternate TLDs are where attackers live.
2. Lead with the highest-signal sources — Certificate Transparency and NRD feeds catch the active threats; exact-match WHOIS loops rarely do.
3. Always score before you alert — it is the only defense against alert fatigue.
4. Match frequency to risk — near-real-time CT for critical brands, daily for the rest.
5. Keep an evidence trail — every finding logged, ready for a UDRP or takedown.
6. Review and tune — retire dead permutations, add new keywords and TLDs as threats evolve.

Conclusion: proactive brand protection through automation

Automating TLD monitoring across 1,500+ extensions is a four-stage pipeline: expand your brand into permutations, watch high-signal sources (NRD feeds, zone files, and Certificate Transparency logs), score each candidate, and alert on the dangerous few. Tools like dnstwist generate the watchlist, CT logs give you minutes-fresh early warning, and a simple scoring function keeps you focused on real threats instead of noise. The TLD Enumerator tool is a fast way to baseline your brand across TLDs, and pairing this with Certificate Transparency monitoring turns brand protection from reactive cleanup into proactive defense.