Use an API to Flag Overnight SPF Changes

SPF tells recipients which hosts may send for a domain. Attackers can imitate senders while studying visible policies, and an unauthorised change can weaken filtering or authorise infrastructure you do not control. Scheduled comparison turns that hidden DNS change into a security event.

To use Trusted Sender Score's API to automatically flag domains whose SPF records change overnight, retain the last valid SPF value and create an alert when the current value differs. Treat the alert as informational until validated: SPF changes are routine during cloud migrations, supplier changes and sender rotations.

Why SPF records can change overnight

SPF is published as a DNS TXT value at the domain root. A change may be deliberate, but it may also follow a DNS account takeover, hosting-panel misuse or an unauthorised include. Capture policy text and DNS state, including resolver errors and lookup-limit failures.

Many Australian organisations rely on Microsoft 365, Google Workspace or regional hosting providers across Sydney, Melbourne, Brisbane and smaller offices. A provider update can touch many domains simultaneously, so grouping alerts by changed mechanism helps distinguish a shared vendor event from a targeted compromise.

Build a trustworthy baseline

Before monitoring, inventory domains you own or manage, including .com.au and .au names, and obtain the relevant API credential. Run an initial check and store the full SPF policy, UTC check time, DNS status, lookup count, DKIM and DMARC status, and request identifier. If the API returns only a score, query the authoritative TXT record alongside it.

Do not flatten multiple TXT records into one value. Two SPF policies cause an SPF error, while a policy with more than ten DNS-query mechanisms fails. In Trusted Sender Score, teams can verify a known partner manually before trusting its current policy as the reference for later comparisons.

Schedule checks around Australia

Run the domain or bulk-checking API from a managed scheduler. Choose a cadence that fits the provider's quota and detection needs: 30- or 60-minute checks provide a useful window, while daily runs cannot show when a record changed. Persist each successful response, and retry transient failures with exponential backoff so they are not recorded as policy changes.

Define “overnight” in UTC, then show recipients local context. Brisbane remains on Australian Eastern Standard Time, Sydney and Melbourne shift during daylight saving, and Perth is three hours behind Brisbane. This avoids false urgency caused by daylight-saving boundaries and gives an Australian security team one consistent event timeline.

Compare records without noisy alerts

On each run, isolate domains whose previous status was valid and whose SPF value now differs. Treat missing data, timeouts and malformed responses as check failures, not deletions. Emit an event containing the old and new values, timestamps, DNS status, changed mechanisms, API request identifier and a link to the raw evidence.

Normalise safe presentation differences such as TXT chunking without changing SPF semantics. Compare the whole policy, not a hash of one selected value. Test for duplicate SPF records and excessive lookups, because either condition can make receiving servers reject the policy.

Create separate event types for a changed value, a record appearing, a record disappearing and a failed check. A changed authorisation list deserves different urgency from a temporary DNS error, even though both mean the expected state is no longer known.

Add DMARC and DKIM context

An SPF change does not prove spoofing, and passing SPF alone does not prove a message is legitimate. Use the DMARC alignment guide to interpret SPF and DKIM alignment, then compare the API's authentication signals with the exact policy that changed. This prevents an expected vendor update from triggering the same response as an unexplained third-party authorisation.

Before escalating, ask the owner or mail provider whether a migration, outage or security rotation occurred. Check message headers, confirm DKIM keys remain valid, and review DMARC aggregate reports for new sending sources. For remotely managed Australian partners, retain a verified contact channel alongside the DNS evidence.

Route alerts into everyday workflows

Each alert should name the domain, business owner, old and new SPF values, detection time, severity and recommended owner. Send routine changes to a ticketing or chat channel, but page the security lead when an unknown authorisation appears, a trusted provider is removed without explanation, or several unrelated domains change together.

For Australian operations, an after-hours page should reach an on-call engineer in Sydney or Melbourne, or a documented partner in Perth, rather than rely on a desktop-only inbox. Avoid message content in alerts where domain metadata suffices; personal data in logs remains subject to the Privacy Act 1988. SPF monitoring does not satisfy the Spam Act 2003 or replace Australian Signals Directorate guidance.

Keep the detector reliable

Protect API credentials in a secrets manager, use TLS, grant only required scopes and rotate keys on schedule. Respect bulk endpoint pagination and rate limits, retain raw responses in access-controlled storage, and monitor the detector itself for missed runs or a falling success rate. A failed monitor must generate a health alert rather than silently weaken coverage.

Review flagged changes regularly to tune sensitivity. Record whether each alert was approved, malicious or an error, then use those outcomes to set retention periods and escalation rules. Polling can miss a change that appears and disappears between checks; authoritative DNS change notifications close that gap for high-risk domains, while scheduled API checks provide broad coverage.