Why Malicious Domains Change SPF Records Before a Phishing Campaign
Phishing remains the number one cyber crime reported to the Australian Cyber Security Centre, with thousands of incidents logged every year across Sydney, Melbourne and Brisbane offices. Threat actors often spend weeks preparing infrastructure before a single lure lands in an inbox, and one of the clearest pre-launch signals is a sudden change to a domain's Sender Policy Framework record. Understanding why this happens helps local security teams spot trouble before customers are hit with fake ATO or MyGov notifications.
SPF tells receiving mail servers which IP addresses are permitted to send on behalf of a domain. When a crook stands up a lookalike domain for a fake Australia Post delivery notice, they usually start with a permissive or broken SPF entry that lets them route mail through bulletproof hosts. As the campaign window approaches, that record gets tightened to specific sending infrastructure so spoofed messages reach the target's Outlook or Gmail without being filtered out.
The technical purpose of an SPF record
An SPF record lives as a DNS TXT entry and is checked by every mail server that receives a message claiming to come from your domain. It works alongside DKIM and DMARC to form the modern email authentication stack. A correctly configured entry either passes, softfails or hardfails the message based on the sending IP, and the result influences whether the email lands in the inbox, junk folder, or gets blocked entirely. For a legitimate Australian retailer, getting this right means fewer missed order confirmations; for an attacker, getting it right means fewer caught phishing emails.
Tactical reasons for tweaking SPF before going live
Pre-launch SPF manipulation serves several operational goals. Attackers need their spoofed infrastructure to align with the domain they are impersonating, otherwise most inbound gateways will reject the message at SMTP time. They also want to swap out free or low-reputation hosts for dedicated servers once the campaign is ready, which requires updating the authorised senders list. Finally, they test how different records behave against major providers like Gmail, Office 365 and the inboxes used by NAB and Westpac customers, fine-tuning until they achieve a high delivery rate.
Patterns observed in Australian threat data
Reports from Scamwatch and the ACSC frequently highlight campaigns that mimic the Big Four banks, the ATO, MyGov and Australia Post. Analysis of takedown timelines shows that many malicious domains sit dormant for days or weeks, then rapidly iterate their DNS records in the 24 to 48 hours before a wave of emails goes out. This burst of DNS activity, including SPF edits, name server swaps and MX record changes, is often the only external indicator that a campaign is being staged. Security teams in Adelaide and Perth have reported spotting these patterns after correlating passive DNS feeds with helpdesk tickets.
Spotting unauthorised SPF changes early
Monitoring your own SPF record is straightforward, but catching lookalike domains requires broader visibility. Teams that run a routine to analyse DMARC failure reports often pick up unauthorised sending sources tied to spoofed subdomains. Pairing this with a workflow to monitor your domain trust score provides a longer view of how the public perceives your sending infrastructure, and alerts you when something drifts.
| Indicator | Legitimate domain | Malicious pre-launch domain |
|---|---|---|
| SPF include count | Stable, audited | Rapid additions, often daily |
| Permissive mechanisms | None, defaults to -all | Frequently uses +all or ?all |
| TTL behaviour | Predictable, 1–24 hours | Short TTLs to allow fast swaps |
| Aligned sending IPs | Documented ESP ranges | Unknown VPS or bulletproof hosts |
| DKIM and DMARC posture | Strict reject policy | Missing or misconfigured |
Building a response workflow around SPF anomalies
A useful first step is setting a strict DMARC policy of reject once you have stable SPF and DKIM alignment. From there, automate alerts on any unexpected DNS change to your apex domain, including TTL shifts or new include statements. Australian organisations operating under the Notifiable Data Breaches scheme should also map SPF anomalies to incident response playbooks, since a spoofed email that tricks an employee into clicking can quickly escalate into a reportable event. Keep forensic samples of malicious messages and their full email headers, as these often reveal the exact SPF evaluation string used.
Long-term hygiene and trust scoring
Treat SPF as a living record rather than a set-and-forget configuration. Re-audit it whenever you onboard a new email service provider, migrate to Microsoft 365, or change marketing automation vendors. Combine that audit with external reputation data so you can tell whether a sudden drop in delivery is caused by your infrastructure or by attackers abusing your brand. Over time, consistent authentication practices raise your trust score, making it harder for criminals to ride your reputation into Aussie inboxes.