Domains
371.9Mlive domains
Domains that resolve. Names that no longer exist are left out. Measured daily.
Threat intelligence · Alerts
Threat intelligence, delivered as alerts.
Datazag watches domains, certificates, DNS and routing for infrastructure aimed at your platforms, brands and suppliers. Each candidate is checked against our full domain corpus, its DNS history, certificates and networks, and arrives with the evidence.
Each alert is delivered with reason codes, infrastructure context and a recommended action path so teams can block, investigate, watchlist, escalate or de-escalate with evidence.
Alert workflow
From signal to action
Observe internet changes, filter known-good infrastructure, attach reasons and deliver alerts into the workflow that can act.
Alert ingredients
Domains
DNS
Certificates
Infrastructure
Brands
Platforms
Keywords
Evidence
What every alert is checked against
The same corpus behind all our intelligence.
An alert is only as good as what it is checked against. Candidates are checked against these layers before they reach you.
DNS history
Snapshots of each domain's records over time, with first-seen and last-seen dates.
Certificate transparency
14.2Mdomains no zone file lists
Certificates show us names that the usual domain lists miss.
BGP routing
3.1BIPv4 addresses in announced space
Who announces each address block, counted once however many routes cover it.
Network and provider attribution
79knetworks profiled
Each IP placed in the network that announces it, and each domain tied to the provider that runs its mail.
Relationships
Shared IPs, certificates, name servers and providers link one domain to the rest.
Each figure is measured and dated. See how in the Observatory →
Operational value
Clear evidence. Clear actions.
Alerts are only useful when the receiving team knows what changed, why it matters and what action is appropriate.
Follow infrastructure as it changes
Monitor domains, DNS, certificates and hosting, and follow a candidate as it develops.
Separate the response
Platform abuse, brand impersonation and attacker infrastructure need different operational actions.
Check matches against known-good
Candidate alerts are checked against known-good infrastructure, brand baselines, platform patterns and cloud footprints.
Deliver into workflows
Send reasoned alerts to SOC queues, partner portals, Microsoft Sentinel or data shares.
Alert classes
Different infrastructure patterns need different responses.
A platform lure, an owned-brand impersonation and a suspicious subdomain on a parked apex domain should not be routed in the same way.
Platform impersonation
Response
Block, enrich detections, watch related infrastructure and de-escalate known-good findings.
Attackers often borrow trust from cloud, identity, email, payment, storage and collaboration platforms. The practical response is usually blocking and detection rather than takedown unless the customer owns the affected brand.
Platform termsLogin luresKnown-good comparisonCloud allowlistsRelated infrastructure
Brand impersonation
Response
Prepare evidence, capture website state, identify abuse contacts and support takedown workflows.
When the alert targets a brand the customer owns or represents, the workflow can move beyond blocking into evidence capture, abuse reporting and remediation tracking.
Owned brandsAliasesSuspicious wordingWebsite evidenceAbuse contacts
Infrastructure alerts
Response
Escalate suspicious domains and IPs found around bad actor infrastructure.
When a candidate is linked to risky infrastructure, Datazag checks related IPs, prefixes, ASNs, DNS relationships and hosted domains to find other connected assets.
Related domainsRelated IPsShared hostingPrefix changesBGP/MOAS signals
Customer watchlists
Response
Monitor customer-specific brands, suppliers, platforms, domains and high-risk terms with tailored thresholds.
Customer context changes how alerts are interpreted. A term that is harmless for one organization may be important for another.
Customer brandsSuppliersTermsDomainsApproved baselines
Signal pipeline
From internet change to operational alert.
The alert is the output of collection, matching, filtering, explanation and delivery. Each stage is designed to make the signal more usable.
1→
Observe
New domains, subdomains, certificates, DNS and infrastructure changes are captured.
2→
Match
Candidates are matched against platforms, brands, keywords, watchlists and suspicious naming patterns.
3→
Filter
Known-good DNS, platform baselines, cloud allowlists and approved customer footprints are filtered out before an alert is raised.
4→
Explain
Reason codes, infrastructure evidence and a suggested action are attached to the alert.
5
Deliver
Alerts are sent to the operational route that fits the team: Microsoft Sentinel, portal, report or data share.
Annotated example
What a reasoned alert looks like.
A useful alert is not just a domain and a severity. It shows the action path, the matched lure, the infrastructure context, the reason codes and how quickly the signal moved through the pipeline.
PLATFORM | RED
Platform Risk Escalated | exchange-signin.example
Incident ID
INC-1782384515-13ec9b
Classification
RED → ISSUE_BLOCK_NOTICE
Match
Platform — exchange
Customer
Generic
ASN Risk Score
1.00 · critical
ASN
AS14618 Amazon AES
Registration
—
Detected Hosting Infrastructure
203.0.113.42 (fronted by AWS)
Confidence
92/100
Reason codes
- • Platform impersonation targeting 'exchange' (Category: Microsoft 365)
- • Not seen in the Datazag domain corpus before this alert
- • infra: ELEVATED_NETWORK_TYPE
- • infra: CERTSTREAM_ANOMALY
- • infra: MALICIOUS_IP_DENSITY
- • infra: PREFIX:BGP_MOAS_SPECIFIC_NEW_ORIGIN
- • infra: ASN:critical
- • infra: CDN_FRONTED:aws
End-to-end latency: 4.4s, from first observation to alert
Illustrative alert. The domain and IP address are reserved example values.
Classification
RED → ISSUE_BLOCK_NOTICE tells the receiving workflow this is a block-notice candidate rather than a general observation.
Match
The alert identifies the platform lure and category, here an Exchange/Microsoft 365-themed platform signal.
Infrastructure risk
ASN score, hosting IP, CDN/fronting context and BGP/MOAS signals explain why the infrastructure is higher risk.
Reason codes
Analysts and automations can see the individual signals that caused escalation instead of treating the alert as a black box.
Latency
End-to-end latency shows how long the alert took from first observation to delivery.
Evidence
Every alert should explain itself.
The goal is not to send more alerts. The goal is to give teams enough context to make a decision quickly and consistently.
Reason codes
Why the candidate escalated: brand term, platform term, suspicious keyword, DNS activity, certificate event or infrastructure risk.
Infrastructure context
Hosting provider, ASN, DNS, certificate, related domains, related IPs, novelty and relationship signals.
Known-good checks
Comparison against approved customer infrastructure, brand DNS, platform baselines and cloud footprints.
Recommended action
Block, investigate, watchlist, prepare evidence, route for review, de-escalate or monitor for content.
Feedback path
Customer or analyst feedback can de-escalate accepted findings and improve future routing.
False positives
Filtering happens before the alert reaches the team.
Brand and platform terms collide with legitimate infrastructure every day. We filter known-good infrastructure out, attach the evidence, and give you a way to push back.
Approved baselines
Customer domains, brand DNS, known cloud footprints and recognized platform infrastructure are filtered out before an alert is raised.
Context before severity
A naming match alone is not enough. DNS, certificates, hosting, novelty and relationship signals change routing and severity.
De-escalation feedback
Accepted findings and known-good infrastructure can be de-escalated so the same finding does not come back.
We have not published our false-positive numbers yet. We are measuring them, and we will publish them with the method. Until then, every alert shows its evidence, so you can judge it yourself — and tell us when we are wrong.
Use cases
One alert layer, multiple operational motions.
The same infrastructure signal can support internal SOC work, managed services, brand protection, ESP abuse workflows and data-driven security operations.
SOC and threat hunting
Look into new infrastructure as it appears, with its context attached.
MSSP and MDR delivery
Package alerting, evidence and customer reporting into managed services.
Brand protection
Separate blocking workflows from evidence-pack and takedown workflows for owned brands.
ESP abuse workflows
Check suspicious links, domains and infrastructure flowing through email platforms.
Data-driven security teams
Join alerts with lakehouse, SIEM, ticketing and case-management workflows.
Delivery
Use the route that fits the workflow.
Alerts can be consumed as live operational events, enrichment calls, evidence packs or analytical datasets depending on the team using them.
Microsoft Sentinel feed
Alert events arrive in Microsoft Sentinel over TAXII 2.1, ready for your analytics rules, playbooks and SOAR.
Microsoft Sentinel
Sentinel pulls Datazag indicators over TAXII 2.1 into its threat-intelligence table. The Datazag solution in the Content Hub adds a matching rule and a hunting query.
Reports and evidence packs
Package findings for executives, customers, takedown workflows and account reviews.
Cloud data shares
Use Iceberg or Delta datasets for analytics, hunting, enrichment and historical review.
How an alert is built
Every alert shows its evidence.
A suspicious domain does not become an alert because one signal fired. It has to pass four checks, each looking at different evidence.
- 01
DNS profile match
Does its DNS configuration match how the impersonated platform actually resolves — or how attackers stage it?
- 02
Infrastructure risk
Where does it live? Hosting network, IP abuse history, certificate patterns — checked against 371.9M domains of prior observation.
- 03
Website check
What's actually being served? Content and behavior, checked against the platform it claims to be.
- 04
Final review
A last pass over all the evidence from the first three checks before an alert is raised. The same review runs on every alert.
Every alert lists what each check found. You set the threshold, and you decide what to block and what to review.
We have not published our false-positive numbers yet. We are measuring them, and we will publish them with the method. Until then, every alert shows its evidence, so you can judge it yourself — and tell us when we are wrong.
Missed threats are the failure you never see — so we don’t hunt domain by domain. One confirmed signal pivots to the whole hosting cluster, surfacing domains that a per-domain check would not flag on their own. We found 150 that way from a single certificate →
Next step
Start with the alert classes that match your workflow.
Begin with platform abuse, brand impersonation, attacker infrastructure or customer-specific watchlists, then route the alerts into the workflow that can act on them.