Why a third party's SPF in your domain signals phishing risk
Email authentication has become a frontline defence for organisations across Australia, from small Brisbane startups to large Sydney-based enterprises. The Sender Policy Framework (SPF) lets domain owners declare which mail servers are permitted to send on their behalf, helping receiving systems reject forgeries. Yet many administrators overlook a subtle weakness: when a domain's authentication string includes the SPF record of an unrelated third party, it can quietly expose the brand to impersonation. Understanding why this happens is essential for any team responsible for outbound communications or customer trust.
The Australian Cyber Security Centre has repeatedly warned that email remains the most common delivery method for phishing attempts targeting local businesses and households. Scams impersonating the ATO, MyGov, Australia Post and major banks such as Westpac continue to land in inboxes from Perth to Hobart. When authentication chains are poorly configured, these fraudulent messages slip past filters that should have caught them. Looking closely at the structure of SPF records is one of the fastest diagnostic steps any security team can take.
This article explores how a domain comes to include someone else's SPF, what that configuration reveals about its administration, and how it can be weaponised by criminals. We will look at real attack chains, the regulatory exposure under the Notifiable Data Breaches scheme, and practical steps for tightening your own records. Each section points to concrete actions rather than abstract theory.
How SPF inheritance works behind the scenes
The SPF standard, defined in RFC 7208, allows a domain administrator to publish a TXT record listing approved sending hosts. The "include" mechanism pulls in another domain's SPF record during lookup, treating every host listed there as authorised for the parent domain. Each include statement, along with mechanisms like a, mx and ptr, counts against a hard ceiling of ten DNS lookups. Once that threshold is exceeded, the receiving server returns a permanent error and the check effectively fails.
This chaining makes delegation convenient. A business using a marketing platform, for example, may legitimately add the vendor's include so newsletters pass authentication. The same mechanism, however, can quietly tie your domain's reputation to a third party whose infrastructure you do not control, whose records may grow without notice, and whose security posture you have not audited.
Why borrowing another domain's SPF weakens your defences
When your SPF record contains an include pointing to an unrelated organisation, you are publicly stating that the third party speaks for you. If that third party suffers a breach, opens a relay, or simply changes its own record, your domain inherits the consequences. A legitimate vendor will provide documentation of their include target, but inherited references found during routine audits sometimes point to dormant services, acquired companies, or domains long since parked.
In Australia, where the Notifiable Data Breaches scheme under the Privacy Act 1988 can trigger mandatory reporting, the operational risk of an inherited SPF failure extends well beyond a blocked marketing email. A spoofed message that authenticates against a vulnerable include can reach finance teams in Melbourne, payroll staff in Adelaide, or customers across regional Queensland, each interaction potentially exposing personal data covered by Australian privacy principles. Following a structured DMARC implementation guide helps teams move beyond reactive clean-up towards enforceable policy.
Phishing campaigns hitting Australians through inherited SPF
Attackers actively scan the DNS for misconfigured chains, looking for weak links in the SPF record. Once identified, they register lookalike infrastructure, send through the inherited authorisation, and bypass basic filtering. Spoofed invoices pretending to come from Australian suppliers, fake ATO refund notices, and fraudulent courier redelivery alerts have all been observed riding on inherited authentication.
Many of these campaigns impersonate trusted brands that Australians interact with daily. Messages claiming to be from Services Australia about a Centrelink payment, or from a major bank about a suspended account, often reach the inbox with full SPF alignment simply because a vendor's record was left dangling. Recipients in Brisbane postcodes, Sydney CBD offices and rural Western Australia have all reported variants of the same pattern.
Reading an SPF record for hidden red flags
Spotting an inherited third-party SPF begins with retrieving the record and counting the lookups. Anything that references a domain you no longer use, a vendor relationship that has ended, or an organisation outside your supply chain deserves immediate review. The comparison below summarises the most common scenarios you will encounter during an audit.
| Observation | Likely meaning | Recommended action |
|---|---|---|
| Single include to a documented marketing or CRM vendor | Legitimate delegation | Confirm vendor's current SPF, monitor lookup count |
| Multiple chained includes, several unresolved lookups | Configuration drift or unauthorised modification | Reduce chain length, retire unused includes |
| Include pointing to an unfamiliar third-party domain | Possible inheritance from a former owner or a phishing indicator | Investigate ownership history, remove if unverified |
| No SPF record at all on an active sending domain | Mail may still be delivered, but spoofable | Archive before any outbound traffic begins |
| Include referencing a domain that has expired | Lookalike risk, possible attacker registration | Remove immediately and alert security operations |
For Australian teams, this audit should also extend to checking .au variants of corporate names. Run a quick free email trust checker against your primary sending hosts and any inherited domains to confirm current reputation scores. Pairing that with regular review of every include makes the red flag obvious before it can be exploited.
Building stronger authentication beyond SPF
SPF on its own is a sender identity check, not a message integrity guarantee. Pairing it with DKIM signing gives each outbound message a verifiable signature, while a published DMARC record instructs receivers on how to handle messages that fail either check. Aligning all three is what closes the gap that inherited SPF can quietly reopen.
For organisations running custom infrastructure, scripted verification and bulk domain review remove manual toil from the audit cycle. A practical developer tools walkthrough demonstrates how to integrate trust scoring directly into deployment pipelines or SIEM dashboards. Combined with ACSC's Essential Eight maturity guidance and regular review of every include in your SPF, this layered approach makes it far harder for a phishing campaign to authenticate against your brand, no matter where the attack originates.