Cybersecurity, Identity & Fraud
Domain Security Monitoring API
Most external security incidents start with something that was visible from the outside and nobody was looking at — an expired certificate, a dangling DNS record, a database port that got opened for a migration and never closed.
- Managed security providers
- Hosting and registrar platforms
- IT service desks
- Compliance tooling vendors
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
External posture decays quietly. A team spins up a staging host, points a subdomain at a cloud bucket, finishes the project and deletes the bucket without removing the record. Six months later someone else claims that bucket name and now owns a subdomain of your domain. Nobody did anything wrong at any single step; the configuration simply drifted and no process watched it.
Certificates are the same story with a clock attached. Expiry is entirely predictable and still causes outages constantly, because the certificate that matters is usually the one on the service nobody remembers owning — a load balancer, an API host, a mail gateway. Email authentication records have a similar profile: SPF and DMARC get configured once, then a new sending platform is added and the policy silently stops covering reality.
What makes this a sellable API rather than an internal script is scale and authorisation. A managed provider watching four hundred client domains needs this as a service with per-tenant scoping, change detection and alerting. And it has to be built on passive observation plus explicitly authorised checks, because the difference between monitoring a domain and probing a domain is a legal distinction, not a technical nicety.
Who buys this
Managed security providers, Hosting and registrar platforms, IT service desks, Compliance tooling vendors
What the API returns
What comes back
- DNS record inventory with change detection across A, AAAA, MX, TXT, NS, CNAME and CAA
- Dangling-record detection where a CNAME or alias points at unclaimed infrastructure
- Certificate inventory with expiry dates, issuer, chain validity and hostname coverage
- Email authentication assessment: SPF resolution, DKIM selector presence, DMARC policy and alignment
- Externally visible service inventory from authorised port and banner checks
- Subdomain inventory assembled from certificate transparency and passive DNS
- Misconfiguration findings with severity, evidence and what the remediation actually is
- Change events, so the alert fires when posture degrades rather than on every scan
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/domains | Register a domain for monitoring with its authorisation record |
| GET | /v1/domains/{domain}/posture | Current findings and configuration snapshot |
| GET | /v1/domains/{domain}/certificates | Certificate inventory with expiry timeline |
| GET | /v1/domains/{domain}/dns | DNS inventory with recent change history |
| POST | /v1/domains/{domain}/scan | Trigger an authorised active check outside the schedule |
| WS | /v1/stream | Push findings and change events across your monitored estate |
Request and response
illustrativeRequest
{
"domain": "clientco.com",
"authorisation": {
"method": "dns_txt_token",
"token": "mlp-verify-9f21c4",
"authorised_by": "security@clientco.com",
"active_checks_permitted": true
},
"schedule": "daily",
"checks": ["dns", "certificates", "email_auth", "exposed_services", "subdomains"]
}Response
{
"domain": "clientco.com",
"assessed_at": "2026-10-21T04:00:00Z",
"authorisation": { "verified": true, "verified_at": "2026-09-14T11:02:00Z",
"active_checks_permitted": true },
"findings": [
{
"id": "f_8821",
"severity": "high",
"type": "dangling_dns_record",
"asset": "legacy-reports.clientco.com",
"evidence": "CNAME to storage endpoint returning NoSuchBucket since 2026-10-04",
"remediation": "Remove the CNAME or reclaim the storage bucket name",
"first_seen": "2026-10-05"
},
{
"id": "f_8847",
"severity": "medium",
"type": "certificate_expiring",
"asset": "api.clientco.com",
"evidence": "Certificate expires 2026-11-03 (13 days)",
"remediation": "Renew; host is not covered by the automated renewal group"
},
{
"id": "f_8863",
"severity": "medium",
"type": "dmarc_policy_none",
"asset": "clientco.com",
"evidence": "p=none with no rua reporting address configured",
"remediation": "Add aggregate reporting, then move to quarantine"
}
],
"exposed_services": [
{ "host": "build.clientco.com", "port": 5432, "banner": "PostgreSQL",
"observed": "2026-10-21T04:11:00Z", "note": "Authorised check; reachable from public internet" }
],
"subdomains_known": 142,
"change_events_7d": 6
}Where the data comes from
| Public DNS resolution | Direct queries for the domain's own records — ordinary resolution, the same thing any mail server does |
| Certificate transparency logs | Public issuance logs, which also reveal subdomains the client had forgotten existed |
| Passive DNS history | Licensed historical resolution data, used to spot records that changed or were abandoned |
| Authorised active checks | Port and banner checks run only against domains with a verified authorisation record from the owner |
| Cloud provider endpoint patterns | Published patterns for storage and service endpoints, which is how dangling records are identified |
| Registry and registrar data | Expiry, lock status and nameserver delegation, within what registry policy permits to be shown |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Authorisation gating in the data model, not the UI: no active check runs against an asset without a verified owner token, and the verification is re-checked before each scan window
- Passive-only mode for any domain where authorisation has not been granted, with the response stating plainly which checks were skipped and why
- Dangling-record detection by resolving the target and matching provider-specific unclaimed-resource responses, rather than guessing from a name pattern
- Change detection on a normalised configuration snapshot, so cosmetic differences such as record ordering do not generate noise
- Severity scoring that accounts for exploitability and asset context — an expiring certificate on a marketing microsite is not the same finding as one on an authentication endpoint
- Finding deduplication and suppression with per-tenant rules, because an unactioned finding repeated daily trains people to ignore alerts
- Rate-limited, politely-identified scanning with per-target concurrency caps and published source ranges, so the traffic is recognisable and attributable
- Monitoring of the monitor: resolution failures and scan errors are reported as degraded coverage rather than silently returning a clean result
What it changes for the business
Predictable failures caught early
Certificate expiry and delegation errors have a clock on them and are the cheapest incidents to prevent.
Forgotten assets surfaced
Certificate logs routinely reveal subdomains the asset owner had no record of.
Scalable managed service
Per-tenant scoping lets one deployment cover hundreds of client domains with separate reporting.
Evidence for remediation
Findings carry the observation that produced them, which is what gets a ticket accepted rather than argued about.
How it fits into your product
How it embeds
- Per-tenant domain registration with an authorisation workflow your onboarding can drive
- Findings pushed into your existing ticketing system with severity and evidence attached
- WebSocket or webhook delivery for change events across a whole monitored estate
- White-label reporting output for client-facing posture summaries
- Deployment inside your infrastructure where scanning must originate from your own address space
- Scheduled and on-demand scans with per-tenant rate limits you control
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can we monitor a domain we do not own?
Only passively, and only what is already public. DNS resolution, certificate transparency and registry data are open — looking at them is no different from any mail server resolving a record. Anything active, meaning port checks, banner grabs or service probing, requires a verified authorisation record from the domain owner. We build that gate into the data model so it cannot be bypassed by a configuration mistake, and the API tells you which checks were skipped for lack of authorisation.
Is this a vulnerability scanner?
No. It inventories what is externally visible and flags configuration that is wrong or decaying. It does not test for exploitable vulnerabilities, send crafted payloads, or attempt to authenticate. If you need authenticated or intrusive assessment, that is a different engagement with a different authorisation document, and it is not what this is.
How often do findings turn out to be wrong?
Most false positives come from intentional configuration that looks like a mistake — a deliberately permissive SPF record during a migration, a port open to a restricted network that our vantage point cannot see is restricted. External observation cannot distinguish “open to the internet” from “open to a range we are not in” with certainty. Suppression rules and asset annotations exist for exactly this, and we would expect to tune them in the first few weeks.
Does a clean report mean the domain is secure?
It does not. This sees the external surface only. An externally tidy domain can have unpatched internal systems, weak authentication, compromised credentials or a hostile insider, and none of that is visible from outside. External posture correlates with internal practice loosely at best, and we would not let a client-facing report imply otherwise.
What about the load our scanning puts on client infrastructure?
Active checks are rate-limited per target, concurrency-capped, scheduled off peak where you specify one, and sent from published source ranges with an identifying user agent. The intent is that a client's own security team can recognise the traffic as yours within seconds rather than opening an incident.
Related blueprints
Third-Party Vendor Risk API
Externally observable security posture, incident history and exposure signals for the vendors in a company's supply chain.
Vulnerability Prioritisation API
Ranks known vulnerabilities by what they actually mean for a specific estate, combining exploitability, exposure and asset importance.
IP Reputation Intelligence API
Proxy, hosting, bot and abuse indicators for any IP address, served as a lookup your product can call on every request.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.