New Domain Delegations — Daily Domain Monitoring Feed
The earliest public signal that a domain went live.
Entering the zone is the earliest public signal that a domain went live: it is how a phishing domain gets caught the day it is set up, or a competitor's product name before the announcement. What it is not is a newly registered domains list, and this Actor is named for the event it actually observes rather than for the search term that would sell better.
oswaldocarabano/new-domain-delegations
{
"contains": ["shopify"],
"days": 1,
"maxResults": 200
}- Version
- v0.1.8
- Memory
- 4096 MB
- Browser
- none
- Proxy
- None — the zone data is held, not fetched
Short answer
The New Domain Delegations Actor returns domains that appeared in the registries' zone files since the previous daily snapshot, filtered by keyword or TLD across 1,075 gTLDs. Entering the zone is the earliest public signal that a domain went live, and it is not the same as being registered: published research puts the share of rows that are re-appearances rather than new registrations at roughly 20–30%, cited here as an outside estimate because it has not been measured on this data. What is certain is the zone event itself — the domain was not in yesterday's snapshot and is in today's — which is 100% reliable and is the signal most security and monitoring uses actually want. Pricing is $0.002 per new delegation, and the registries publish once a day, so a domain delegated this morning appears in tomorrow's run.
Key points
- Entering the zone is the earliest public signal that a domain went live, which is what makes it useful for catching a phishing domain the day it is set up.
- Zone entry is not registration: published research puts the share of rows that are re-appearances rather than new registrations at roughly 20–30%, cited as an outside estimate because it has not been measured on this data.
- A domain registered a year ago that sat on hold and has just had its nameservers restored looks identical from the outside to a brand new one, and no WHOIS query is made to resolve the difference.
- The zone event itself is 100% reliable: the domain was not in yesterday's snapshot and is in today's, which is the registry's own record rather than an inference.
- The registries publish once a day, so a domain registered and delegated this morning appears in tomorrow's run and there is no faster path from this source.
- Every run requires either a keyword filter or a TLD filter, and the look-back window is capped at 90 days, because no run is allowed to return a substantial portion of a zone.
What it does
Entering the zone is the earliest public signal that a domain went live: it is how a phishing domain gets caught the day it is set up, or a competitor's product name before the announcement. What it is not is a newly registered domains list, and this Actor is named for the event it actually observes rather than for the search term that would sell better.
{
"domain": "shopify-payouts-verify.shop",
"tld": "shop",
"observed_on": "2026-09-17",
"nameservers": ["ns1.dnsowl.com", "ns2.dnsowl.com"],
"dns_provider": "NameSilo",
"parked_for_sale": false
}Why this one
Named for the event, not for the search term
"Newly registered domains list" is what people search for and it is not what any zone-file feed can deliver. Naming this Actor for zone entry costs search volume and keeps the output honest, and the README says which of the two the reader is getting in its second paragraph rather than in a footnote.
An outside estimate labelled as one
The 20–30% re-appearance share comes from published research rather than from a measurement on this data, and it is cited that way. Quoting it as an in-house figure would have read stronger. The distinction between what has been measured here and what has been read elsewhere is the one the rest of this site's numbers rest on.
A certainty separated from an interpretation
Two claims live in every row and they have different strengths. That the domain entered the zone is certain. What that means about the domain is not. Keeping them apart in the documentation is what lets a security team use the feed for triage without building a process on top of a number that is wrong a quarter of the time.
One snapshot a day, said plainly
There is no faster path: the registries publish once a day and this feed is a difference between two of those publications. Tools that advertise real-time new-domain feeds are either using a different source or describing something else, and the latency here is stated rather than implied by an absence.
Use cases
- Alert daily on new domains containing a brand name, as an early phishing signal.
- Catch a competitor's product name entering the zone before the announcement.
- Monitor newly delegated domains in one small TLD where the daily volume is readable by a person.
- Feed a security triage queue with domains whose names match a watchlist of terms.
- Track how a keyword is being registered across the gTLD namespace over a 90-day window.
Input
Every field has a default, and the defaults are deliberately small so a first run is cheap enough to inspect before you commit to a sweep. This table mirrors the Actor's own input schema field for field.
| Field | Default | What it does |
|---|---|---|
containsstring[] | [] | Keyword filterOnly return new domains whose name contains one of these words. Either this or a TLD filter is required. |
tldstring[] | [] | TLD filterRestrict to these TLDs, without the dot. Empty means all covered TLDs, which is only usable alongside a keyword filter. |
daysinteger | 7 | Days to look backpersonal dataHow many daily snapshots to search. Required and capped at 90 — there is no 'since forever', by design. |
maxResultsinteger | 100 | Max resultspersonal dataHard cap on rows returned, kept low on purpose so a first run cannot burn a free credit. The service never returns more than 50,000 rows in one run. |
Output and fill rates
A field being in the schema is not the same as it having a value. The percentages below were counted on real runs; the sample sizes are in Measurements. Anything not listed here is not promised.
| Field | Filled | Meaning |
|---|---|---|
domainstring | 100% | The domain that entered the zone in the window searched. |
tldstring | 100% | The top-level domain, one of the 1,075 covered gTLDs. |
observed_onstring | 100% | The date of the snapshot where the domain first appeared, which is the certain part of the row. |
nameserversstring[] | 100% | Where the domain delegates, as recorded in the snapshot that first carried it. |
dns_providerstring | 69.1% | Who runs the DNS, inferred from the nameserver. A hosting fact rather than a technology one. |
parked_for_saleboolean | 100% | True when the nameserver belongs to a parking or domain-sale service. Fires on 2.0% of domains and is exact when it does. |
Every key is always present. A field that exists but is empty comes back as explicit null, so a parser never has to guess.
Datasets
Different record types go to different datasets, so the main table never carries columns that are blank on most rows.
defaultOne row per domain that entered the zone in the window, with the date it was first seen and its delegation.billed
Pricing
Pay per delivered result. Charges are applied as each row is produced rather than in a lump at the end, so an aborted run bills only for what it actually gave you.
| Event | Price | Notes |
|---|---|---|
actor-startActor start | $0.00001 | Effectively free. A run that finds nothing costs you nothing, which is what a quiet day should cost. |
new-delegationNew delegation | $0.002 | One domain that appeared in the zone since the previous daily snapshot, with the date it was first seen and its nameservers. Entering the zone is the earliest public signal that a domain went live. |
Measurements
Each figure is shown with the method that produced it. A benchmark without a method is a marketing claim wearing a number's clothes.
Zone coverage
255,631,856 domains across 1,075 gTLDs
Counted from the zone files themselves rather than quoted from a registry summary, and refreshed daily.
Re-appearance share
roughly 20–30%
Published research, cited as an outside estimate. It has not been measured on this data, and quoting it as an in-house figure would have read stronger than the evidence supports.
Zone event reliability
100%
The domain was absent from one daily snapshot and present in the next. That comparison is the registry's own record and is the only claim in the row that carries no interpretation.
Feed latency
one snapshot a day
The registries publish zone files once a day, so the floor on latency is a property of the source rather than of the pipeline.
`dns_provider` fill rate
69.1%
Measured across every domain in the zone. The remaining 30.9% delegate to nameservers that identify no known operator.
What it will not do
Stated plainly so you can judge fit before spending anything.
- Zone entry is not registration, and roughly 20–30% of rows are re-appearances according to published research rather than a measurement on this data.
- One snapshot a day: a domain registered and delegated this morning appears in tomorrow's run, and no faster path exists from this source.
- Either a keyword filter or a TLD filter is required, because no run is allowed to return a substantial portion of a zone.
- The look-back window is capped at 90 days, by design rather than by capacity — there is no 'since forever'.
- Country-code TLDs are not covered, so a new `.io` or `.ai` domain never appears.
- A zone file contains no registrant, no email, no registrar and no registration date, so a new delegation cannot be attributed to anyone.
- The service never returns more than 50,000 rows in one run.
Privacy
- Zone files contain delegation records, not people: there is no registrant, no email address and no registrar in the source.
- The data is obtained through ICANN's Centralized Zone Data Service under agreement with the Registry Operators, and ICANN does not endorse, sponsor or review this Actor.
- No WHOIS or RDAP query is made to resolve whether a delegation is new or a re-appearance, because querying registries at scale is prohibited by the agreement that provides this data.
- Every run is anchored on a keyword or TLD filter the operator supplies, and the window is capped at 90 days.
- Removal requests: privacy@actorstack.dev
See also the data removal process.