Why SPF -all can make phishing domains look trustworthy

Email authentication is designed to help receiving systems distinguish authorised mail from forged messages. SPF, or Sender Policy Framework, publishes a list of servers allowed to send mail for a domain. An -all mechanism tells receivers that mail from any other server should fail SPF checks.

That sounds highly protective, and it is useful against certain types of spoofing. However, an attacker can register or compromise a domain, publish a strict SPF record, and send phishing messages from an approved server. The message may then pass SPF even though the domain itself has no legitimate relationship with the recipient.

This tactic matters in Australia, where criminals frequently imitate banks, myGov, Medicare, the ATO, Australia Post and parcel delivery services. A message that passes an authentication check can appear more credible to automated filters and busy recipients in Sydney, Melbourne, Brisbane or regional communities.

What SPF -all actually proves

An SPF record identifies permitted sending infrastructure for a domain. With -all, the domain owner declares that other servers are unauthorised. If a message comes from an unlisted server, the receiving mail system can treat it as an SPF hard fail.

The record says nothing about whether the domain owner is honest. An attacker-controlled domain can have a carefully configured SPF record that authorises the criminal’s mail server. SPF then confirms that the message came from an approved source for that domain, not that the source is safe.

Why criminals configure strict records

Cybercriminals often prepare phishing domains before launching a campaign. They may register a lookalike domain, create mailboxes, configure SPF, add DKIM signing and publish DMARC. These steps make the domain appear technically maintained rather than hastily assembled.

A strict -all record can also reduce uncertainty for the attacker. Their messages are sent from the approved platform, so authentication results remain consistent. In some cases, this reliability improves delivery into inboxes while the domain imitates a familiar Australian brand or government service.

Passing SPF is not the same as being legitimate

A message can pass SPF while using a deceptive display name, a dangerous link or a misleading domain. For example, billing@secure-australia-example.com may pass SPF perfectly while pretending to represent an energy retailer or financial institution.

Recipients and security tools should examine the visible From address, the Return-Path, DKIM alignment, DMARC results, domain age, reputation and link destination. A pass result is one signal in a wider assessment, not a safety certificate.

How the authentication signals fit together

SPF checks the envelope sender and the server that delivered the mail. DKIM checks whether a cryptographic signature matches the message and a domain. DMARC checks whether SPF or DKIM aligns with the domain shown in the visible From address.

Signal What it confirms What it does not confirm
SPF -all pass The sending server is authorised by that domain The domain is reputable or genuine
DKIM pass The message has a valid signature from a domain The signer is a trustworthy organisation
DMARC pass SPF or DKIM aligns with the visible From domain The content and links are harmless
Reputation check Historical behaviour and risk indicators That every current message is safe

A criminal can therefore achieve several green authentication results on a domain created solely for fraud. Domain reputation, registration details, brand similarity and message context remain essential.

Lookalike domains exploit recognition

Phishing domains often use subtle spelling changes, extra words, hyphens or deceptive subdomains. A fake parcel notification might use a domain containing “auspost”, while a banking scam may add “secure”, “verify” or “support” to a brand-like name.

Australian users may receive convincing messages during tax time, cyclone recovery, major sales events or periods of widespread parcel deliveries. Social media alerts deserve similar caution; a review of social notification checks can help expose authentication and reputation inconsistencies behind familiar-looking alerts.

Reputation adds the missing context

SPF is a policy record, whereas reputation is built from observed behaviour. A newly registered domain with perfect SPF may still have no trustworthy history, mismatched branding, suspicious hosting, disposable contact details or links that redirect through several services.

Security teams can compare the domain’s authentication posture with its age, registration pattern and related infrastructure. Domain owners should also monitor whether their legitimate domains are being impersonated, especially when customers expect invoices, delivery updates or account notices by email.

Practical checks for Australian recipients and teams

Before clicking, inspect the complete sender address rather than relying on the display name. Be cautious when a message urges immediate payment, requests a one-time code or directs you to “confirm” details through an unexpected link. Government and financial organisations generally provide independent ways to access accounts, so opening the official app or typing the known website manually is safer.

Organisations can automate these checks across suppliers, customer domains and reported phishing indicators. The platform workflow supports domain trust checks and authentication review, while bulk checking and API access can help security teams incorporate sender verification into triage and monitoring processes. SPF -all should be treated as useful evidence, but never as proof that a phishing domain is authentic.