Why a domain with valid SPF but no DMARC is still a phishing enabler
SPF can make an email appear authenticated while leaving the address a recipient actually sees unverified. The record is useful, but it governs one part of message delivery and cannot by itself stop convincing impersonation from reaching Australian inboxes.
A domain with a valid SPF include but no DMARC is still a phishing enabler because both conditions can coexist: SPF passes for the envelope sender, while nothing authoritatively compares the visible From address with that result. Without a DMARC policy, receivers have no domain-owner instruction to quarantine or reject that mismatch. Technical validity can therefore create false confidence.
Valid SPF is not a promise about the visible sender
SPF checks whether the sending IP is authorised to use a domain in the envelope MAIL FROM field. An include mechanism points to another domain whose SPF record delegates permission to a mail provider or platform. The chain can be perfectly healthy and still say nothing about the organisation shown in the visible From header.
An attacker can send from an IP authorised for a domain they control, giving that envelope SPF its own pass, then place an Australian bank, charity or supplier in the visible From field. SPF determines whether a server may send for the envelope domain. It does not determine whether the visible domain aligns with that sender. Without DMARC, those remain separate questions.
What an SPF include really authorises
An include grants sending rights only to infrastructure identified by the delegated SPF chain. It does not mean every customer of that provider may impersonate the including domain. Shared platforms can nevertheless suffer account abuse, weak tenant configuration or compromised credentials, allowing traffic to pass the provider’s SPF check while carrying an unrelated identity.
Missing DMARC removes the explicit domain-level backstop for this situation. It does not weaken SPF itself, but it leaves recipients to determine how to handle messages where SPF has passed and the displayed identity has not been aligned. A valid include supports legitimate delegation without ensuring that delegated mail cannot be abused.
DMARC adds identity alignment and enforcement
DMARC asks the receiving server to compare the visible From domain with the domains that passed SPF or DKIM. At least one authenticated domain must align with the visible From domain, and the policy tells the receiver whether to deliver, quarantine or reject the message. A legitimate mailing platform can still send successfully when its SPF or DKIM configuration provides that alignment.
Deploying DMARC does not require an immediate block. A monitoring policy can first collect evidence without affecting delivery, after which an organisation can move to quarantine and rejection as alignment is confirmed. SPF and DKIM failures alone need not cause DMARC failure when the other mechanism passes and aligns. This gives domain owners a controlled path from visibility to enforcement.
Different controls answer different trust questions
Authentication works as a chain of checks rather than a single badge. Each control answers a different question and leaves a distinct gap when it is absent.
| Control | Main question | Remaining gap |
|---|---|---|
| SPF | Is the sending IP authorised for the envelope domain? | It says nothing about the visible From domain |
| DKIM | Has a message been signed with a domain-linked key? | It does not require that signer to match the visible sender |
| DMARC | Does an authenticated domain align with the visible From domain, and how should the result be handled? | Without it, receivers lack an explicit identity-alignment policy |
| SPF and DMARC | Does an aligned identity pass, and what action does the policy prescribe? | Correct DNS, signing and policy configuration remain essential |
SPF establishes envelope-sender authority, DKIM establishes content-signing identity, and DMARC connects the visible identity to an authenticated domain and a handling policy. A valid include can keep ordinary mail flowing while phishing with an unrelated but SPF-valid envelope remains outside any policy declared by the impersonated domain. The free Trusted Sender Score service can surface missing DMARC records alongside SPF and DKIM configuration issues.
Why this gap matters in Australia
Many small organisations in Sydney, Melbourne and Brisbane use Microsoft 365 or Google Workspace while outsourcing domain administration to a local registrar or reseller. The .com.au and .au markets make that separation common, and a business can maintain a secure website while its mail DNS remains under another supplier’s control. As people regularly access mygov, PayID, online banking and customer portals on phones, a familiar logo or display name can carry more weight than envelope details.
The Privacy Act 1988 and Australian Privacy Principles do not prescribe DMARC, but impersonation can expose personal information and create deceptive conduct risks. The Spam Act 2003 governs commercial electronic messages and sender identification rather than complete message authentication, while the Australian Consumer Law can apply to false business representations. Australian Signals Directorate email-security guidance also reinforces the value of SPF, DKIM and DMARC for Australian organisations.
A weekly verification routine reduces exposure
Start with primary sending domains, known lookalikes and high-risk subdomains. A weekly domain lookalike check helps teams identify confusing registrations before criminals activate them. Results should be reviewed for SPF include chains, DKIM signatures, DMARC presence, policy strength and reporting destinations rather than treated as a simple pass or fail.
Automation can support larger portfolios: bulk domain checks suit managed service providers, while an API can bring trust results into ticketing, procurement or release workflows. Routine checks should confirm that new sending services have aligned SPF or DKIM configurations, that DMARC begins in monitoring mode and that reports reach someone able to act. Staff training should reinforce checking full addresses and navigating to services directly rather than trusting logos or display names. Consistent verification then makes email authentication a repeatable security control rather than a misleading configuration check.