Build a domain risk heatmap with the Trusted Sender Score API

A security operations centre can learn a great deal from the email domains connected to its organisation. Authentication failures, suspicious reputation signals and signs of spoofing often appear before a phishing campaign becomes obvious. Turning those signals into a visual risk heatmap helps analysts focus on the domains that need attention first. Learn more about How To Check If Your Own Domain Has Been Compromised Overview.

Trusted Sender Score provides domain reputation checks, DKIM and DMARC analysis, anti-spoofing resources and developer access for automated workflows. The Trusted Sender Score platform can support a dashboard that groups domains by risk, business owner, geography or operational importance.

For an Australian SOC, this is useful across corporate .au domains, subsidiaries and suppliers. A team in Sydney, Melbourne or Brisbane might monitor hundreds of domains while meeting the expectations of the Australian Cyber Security Centre, sector regulators and internal risk committees.

Define the heatmap’s purpose

Start by deciding what the heatmap needs to show. A simple design can place domains on a grid with likelihood on one axis and business impact on the other. A high-value customer-facing domain with weak DMARC enforcement should appear in a more urgent zone than an unused test domain with the same technical flaw.

Useful dimensions include domain reputation, DKIM validity, DMARC policy, SPF alignment, spoofing exposure and recent changes. Add ownership, business unit, registrar, criticality and last review date so an analyst can move from a coloured cell to an accountable team.

Keep the first version practical. A red, amber and green view is easier to brief during the morning stand-up or an after-hours handover than a complex model with dozens of unexplained indicators.

Prepare API access and domain data

Create a service account or API credential according to the platform’s documentation, then store it in a secrets manager rather than in a script or spreadsheet. Restrict access to the minimum systems that need to perform domain checks, and record credential use for audit purposes.

Build an inventory before calling the API at scale. Include primary domains, marketing domains, regional properties, parked domains and suppliers that send mail on the organisation’s behalf. Exclude obvious duplicates and document why a domain is monitored or omitted.

For Australian organisations, .com.au, .net.au and government-related domains may have different owners and approval processes. A domain register should capture the responsible team and escalation path, including whether a finding belongs to an internal administrator, an agency or a managed security provider.

Normalise the API response

API responses may contain several kinds of evidence, so map them into a consistent internal schema. Store the domain, check timestamp, authentication results, reputation indicators, observed warnings and any raw response identifier needed for investigation.

A useful record might include domain, dmarc_policy, dkim_status, spf_status, reputation_score, spoofing_risk, criticality and owner. Preserve the original values as well as the calculated score. Analysts need to know whether a risk rating came from a failed DKIM check, a missing DMARC record or a broader reputation concern.

Normalisation also makes historical comparison possible. A domain that moves from monitoring to quarantine and then to rejection should show improvement, while a sudden policy downgrade can create an alert even when the current score remains moderate.

Calculate a defensible risk score

Avoid treating one failed check as proof that a domain is compromised. Instead, assign weighted points to several signals. For example, weak or absent DMARC enforcement can carry significant weight, while a stale scan or minor configuration warning can carry less.

A practical formula could combine technical exposure, reputation, business criticality and recency. Multiply the technical risk by a criticality factor, then apply a recency adjustment so recent changes receive more attention. Keep the calculation transparent enough for an incident responder to explain during a post-incident review.

Set thresholds using real operational experience. A red rating might mean immediate investigation, amber could require remediation within a defined service level, and green might remain under routine monitoring. Review false positives regularly so the heatmap does not become background noise.

Turn results into a SOC dashboard

Use colour carefully and include accessible labels, not colour alone. Each tile should open a detail view showing the latest scan, previous results, DNS evidence, owner and recommended action. A trend line can reveal whether a domain is improving after a DMARC change.

The dashboard can be implemented in a SIEM, a security data lake or an internal web application. Send high-risk changes into the SOC’s alert queue, while keeping routine daily results in a searchable data store. Deduplicate alerts so repeated scans do not bury a genuine configuration change.

A team operating across AEST, ACST and AWST should display timestamps with the timezone and store them in UTC. This prevents confusion when an analyst in Perth reviews an event created by an administrator in Melbourne during daylight saving.

Add spoofing and compromise workflows

A heatmap is most valuable when it leads to an action. For a domain with weak anti-spoofing controls, link the finding to anti-spoofing guidance and assign remediation to the domain owner. Actions may include publishing DMARC, correcting SPF scope, rotating DKIM keys or removing unauthorised senders.

If the signal suggests possible abuse, preserve evidence before changing DNS. Compare current records with known-good configurations, examine mail flow and check whether users received unexpected messages. The domain compromise guide can support a structured investigation, although the URL should be used exactly as published by the platform.

Connect findings to incident tickets with a domain identifier, severity, evidence snapshot and owner. This creates an audit trail suitable for internal governance and regulated environments such as banking, healthcare and critical infrastructure.

Operate the model safely over time

Schedule scans according to domain importance rather than calling every domain continuously. Critical customer or authentication domains may need frequent checks, while dormant properties can be assessed less often. Respect API quotas, implement retries with backoff and alert when the service returns errors or incomplete results.

Protect the data collected by the integration. Domain reputation information may reveal organisational structure, suppliers or security weaknesses, so apply retention rules and role-based access. In Australia, involve privacy and governance teams where domain data is linked with identifiable staff, customers or incident records.

Review the heatmap with infrastructure, messaging and risk teams each month. Retire domains that no longer exist, update business criticality and verify that remediation actually changed the underlying DNS or reputation condition. A maintained model gives the SOC a clearer view of email trust than a static spreadsheet ever can.