Build an email risk scorecard with the API

Email sender checks become more useful when their results feed a consistent decision process. This guide explains how to build a simple email risk scorecard using the Trusted Sender Score API and a spreadsheet, without treating one signal as an automatic verdict.

The goal is a repeatable triage sheet for staff in Sydney, Melbourne, Brisbane and regional operations. It should show why a message was flagged, who owns the next action, and whether the result can be released, reviewed or blocked without relying on instinct.

Australian domains often end in .com.au or .au, and legitimate organisations may trade under a domain different from their registered business name. A sheet that checks only the displayed wording can miss impersonation, while a rigid rule can punish a genuine supplier using an unfamiliar domain.

Treat the score as risk intelligence, not proof of misconduct. Under the Spam Act 2003, commercial email can also trigger consent, sender identification and unsubscribe obligations, none of which a sender reputation score can certify.

Set the scoring policy

Start with fixed columns: checked time, sender address, sending domain, visible brand, API result, SPF, DKIM, DMARC, domain alignment, total risk, band and assigned owner. Normalise addresses to lowercase and retain the raw response so calculations can be audited.

The sender metrics reference defines the platform’s available outputs. Confirm whether each value represents trust or risk before converting it, because high trust and high risk move in opposite directions.

An illustrative policy could assign 35 points to reputation risk, 15 to SPF failure, 20 to DKIM failure, 25 to DMARC failure and 5 to a reply-to or alignment mismatch. Unknown values should trigger review rather than silently becoming zero.

Connect the API to your sheet

Use the developer documentation to identify the live endpoint, accepted identifier, authentication requirements and response fields. Send the sender address or domain exactly as the endpoint expects, then parse the returned record into the spreadsheet; avoid copying an example endpoint that may later change.

A typical workflow sends one API request, places the response in a staging column and only then calculates a band. Retain the HTTP status, API timestamp and request ID where supplied, making a failed check distinguishable from a low-risk result.

For regular monitoring, a small Apps Script, Power Automate flow or scheduled backend job can call the API and append rows to Google Sheets or Microsoft Excel. Store any API key in the workflow’s secret facility, never in a visible worksheet cell.

Turn responses into risk levels

Keep raw inputs separate from policy. If the platform returns a trust score from 0 to 100, convert it to reputation risk with =35*(1-TrustScore/100). Reserve five normalised risk columns for reputation, SPF, DKIM, DMARC and alignment.

A total formula can be =IF(COUNT(D2:H2)<5,"CHECK",MIN(100,SUM(D2:H2))). A second formula can return Low, Medium, High or Critical at 24, 49 and 74 points. Keep thresholds in labelled cells so an authorised administrator can adjust them without rewriting formulas.

A sample from accounts@vendor.example.com.au might score 57 after weak reputation, failed DKIM, failed DMARC and a reply-to mismatch. That warrants human review, not automatic deletion. Also avoid double-counting: if failed alignment already causes the DMARC result, record the stronger signal only.

Add authentication and Australian checks

SPF checks the envelope sender, DKIM checks a signed message, and DMARC ties the visible From address to authenticated infrastructure. Do not classify a legitimate forwarding service as malicious merely because its SPF result differs from the organisation’s main domain.

The DMARC guidance explains alignment, p=none, quarantine and reject policies in practical terms. Penalise a hard DMARC failure, but record a published p=none policy as a configuration weakness rather than a forged message.

For Australian operations, confirm that the sending domain matches the supplier’s .com.au or .au domain and verify its ABN or ACN details. Small businesses often use Microsoft 365 or Google Workspace through an outsourced IT provider, so the envelope domain may be a managed relay while the visible domain remains valid.

Review scores and operational decisions

Operationalise the sheet around clear ownership. A staff member in a Sydney office can review medium-risk messages during Australian business hours, while a Brisbane administrator handles escalations and a Melbourne security owner reviews repeated DKIM or DMARC failures. Record the reason for every override.

Scores support these operating bands:

Band	Score	Interpretation	Default action
Low	0–24	No material weakness detected	Release after routine checks
Medium	25–49	A material warning or several minor weaknesses	Hold for staff review
High	50–74	Multiple failures or a meaningful domain mismatch	Quarantine and contact the sender
Critical	75–100	Strong spoofing indicators or repeated authentication failure	Block and escalate

Review thresholds quarterly and whenever the platform changes its metrics. Sample false positives with senders in finance, payroll and logistics, document exceptions, and version each weighting change so historical scores remain explainable. A trustworthy scorecard is one an auditor can reproduce, not merely a colour on a dashboard.