Building a live feed of suspicious newly registered domains

A newly registered domain can become part of a phishing campaign within hours. Monitoring registration age alongside sender reputation, authentication results and spoofing indicators gives security teams an earlier warning than waiting for a malicious email to reach an inbox.

This guide explains how to use the platform's API to create a live feed of newly registered domains with suspicious reputation. The approach suits Australian businesses, managed service providers and security operations teams that need reliable signals without manually checking every domain.

Define what “new” and “suspicious” mean

Start by separating domain age from domain discovery. A domain may have been registered recently, or it may simply be newly observed by your systems. Registration data can come from RDAP or another domain intelligence source, while the Trusted Sender Score API can provide reputation and email security checks.

Create a clear decision policy before writing code. For example, flag domains registered within the last 30 days when they also have a poor trust score, missing DMARC, invalid DKIM, suspicious hosting or indicators associated with spoofing. This keeps the feed focused instead of producing a noisy list of every new domain.

Prepare API access and request flow

Create the required API credentials in the platform account and store them in a secrets manager rather than inside application code. Your integration should authenticate each request according to the current API documentation, respect rate limits and record response status codes for troubleshooting.

A practical workflow begins with a domain source, such as an RDAP stream, registrar feed or internal email telemetry. For each candidate, send the domain to the reputation endpoint, collect the returned assessment, and enrich it with registration age. If the API supports bulk checking, batch candidates to reduce overhead; otherwise, use a queue with controlled concurrency.

Build the screening logic

The feed should retain the raw response as well as a normalised event. Useful fields include the domain, registration date, first-seen timestamp, trust score, DKIM status, DMARC policy, SPF result, threat indicators and API response time. Keep the original data so an analyst can review why a domain was escalated.

A simple scoring model can combine several signals. Recent registration might add risk points, while a valid DMARC policy could reduce them. Treat high-risk combinations—such as a two-day-old domain, lookalike naming and a failing authentication profile—as urgent. Teams can refine thresholds after reviewing false positives from legitimate campaigns, new suppliers and marketing platforms.

Signal	Example condition	Suggested handling
Registration age	Less than 30 days	Add to monitoring
Reputation	Low trust or adverse result	Escalate for review
DMARC	Missing or policy set to none	Increase risk score
DKIM or SPF	Failure or invalid record	Inspect sender infrastructure
Brand similarity	Resembles a known organisation	Send to analyst queue
API response	Timeout or incomplete result	Retry and preserve status

Stream results into an operational feed

A scheduled worker can poll for new candidates every few minutes, while a message queue prevents a temporary API outage from losing events. Publish normalised results to a SIEM, case management system, Slack-compatible alert channel or dashboard. Include a stable event ID so retries do not create duplicate incidents.

For an Australian organisation, schedule jobs in UTC but display timestamps in AEST or AEDT for the on-call team. A Sydney-based SOC and a Melbourne office may interpret “this morning” differently during daylight-saving changes, so store UTC and a localised value. Keep alert content concise for the team checking incidents during a busy arvo.

Apply a domain trust policy

The API gives your automation signals, but policy determines what happens next. A low score might create an observation, while a low score combined with recent registration and brand similarity could trigger blocking, mailbox searches or a takedown workflow. Document ownership between security, messaging and fraud teams.

A written domain trust policy helps align thresholds with business risk. This matters for Australian organisations working with banks, insurers, councils or NDIS providers, where a convincing lookalike domain can affect customers and partners as well as employees.

Reduce noise with feedback and history

Do not block every newly registered domain automatically. Australian businesses regularly onboard local suppliers using .com.au or .au domains, and legitimate domains may have little reputation history. Add allowlists for verified partners, but give those entries an expiry date and require periodic review.

Track score changes over time instead of evaluating only the first result. A domain that moves from neutral to suspicious after sending a campaign deserves attention, even if its original result looked harmless. The dashboard guidance on tracking reputation changes can help analysts interpret those shifts alongside API events.

Secure and maintain the integration

Protect API keys with least-privilege access, rotation and audit logging. Never place credentials in browser-side JavaScript or expose full provider responses to untrusted users. Log request identifiers, but remove personal data and message contents unless they are essential to the investigation.

Add retries with exponential back-off, schema validation and monitoring for quota usage. Test the pipeline with known benign domains and controlled phishing simulations, then compare alerts with analyst decisions. When a result points to an email campaign, analysts should verify the sender’s domain before following links or contacting the supposed organisation.

With these controls, the feed becomes a measured early-warning service rather than a stream of unverified domain names. It can support mailbox protection, threat hunting and incident response while preserving the context needed for sound decisions.