Why SPF can pass while DKIM fails
An email domain that passes SPF but fails DKIM may still belong to a genuine sender. These two authentication methods examine different parts of the delivery process, so one successful result does not automatically validate every technical detail of the message.
SPF checks whether the sending mail server is authorised to send for a domain listed in the envelope sender. DKIM verifies a cryptographic signature attached to the message. A legitimate email can therefore pass SPF while its signature is missing, broken, altered in transit, or associated with a different domain.
This distinction matters for Australian businesses, schools, charities and online retailers sending messages through Microsoft 365, Google Workspace, customer relationship platforms or marketing providers. A failed DKIM result deserves investigation, but it should be assessed with DMARC alignment, sender reputation and message context rather than treated as automatic proof of phishing.
What SPF and DKIM actually prove
SPF compares the connecting mail server’s IP address with the domain’s published SPF record. If the server is listed, SPF can pass. This is useful for stopping unauthorised infrastructure from sending mail, although SPF follows the envelope sender, which recipients may not see in the visible From field.
DKIM adds a digital signature to selected headers and the message body. The receiving system retrieves a public key from DNS and checks whether the content still matches the signature. It also checks the signing domain, shown through the d= value, which may differ from the address displayed to the recipient.
Why a DKIM failure does not prove fraud
A sender may use a trusted third-party platform that correctly appears in SPF but has not been configured to sign with the organisation’s own domain. The message can be authentic while the DKIM signature is absent, uses an expired key, or fails alignment with the visible From domain.
Forwarding is another common cause. Mailing lists, ticketing systems and security gateways can change a subject line, footer or body content after the original signature was created. Even a legitimate forwarding service can therefore invalidate DKIM while SPF passes for the forwarding server.
How legitimate mail can lose its signature
DNS mistakes are also responsible for many failures. A selector record may be missing, a public key may have been published under the wrong hostname, or a provider may still be using an old selector after a key rotation. Large organisations often have several systems sending mail, each with its own authentication settings.
Message rewriting can happen inside corporate gateways, archiving tools and email security products. A system that adds a legal disclaimer or scans and reconstructs attachments may alter signed content. The result is a technical failure rather than evidence that the original sender was impersonated.
| Authentication result | What it usually indicates | Sensible interpretation |
|---|---|---|
| SPF pass, DKIM pass | Authorised server and valid signature | Stronger authentication signal |
| SPF pass, DKIM fail | Authorised path, broken or absent signature | Potentially legitimate, but needs context |
| SPF fail, DKIM pass | Valid signature from a signing domain, unauthorised envelope path | Check DMARC alignment and forwarding |
| Both fail | Neither mechanism verified successfully | Higher risk, especially with suspicious content |
| DMARC pass through SPF | Visible From domain aligns with the SPF-authenticated domain | Message may pass policy without aligned DKIM |
Reading the full authentication result
The next question is whether DMARC passes. DMARC can pass when either SPF or DKIM succeeds and aligns with the visible From domain. Consequently, a message with a failed DKIM check may still satisfy the sender’s DMARC policy through aligned SPF.
Alignment is important because a criminal can sometimes pass SPF for a lookalike or unrelated domain while displaying another address in the From field. Reviewing the Return-Path, From domain, DKIM d= domain, DMARC result and receiving server details provides a more reliable assessment. A sender trust checker can help identify domain reputation and authentication issues alongside those headers.
Australian sending environments to consider
Australian organisations commonly combine Microsoft 365 or Google Workspace with local accounting, booking and marketing services. A Melbourne retailer, a Brisbane trades business or a Sydney professional firm may have invoices sent from one platform, newsletters from another and support replies through a third-party helpdesk. SPF can cover all their servers while DKIM remains configured in only one system.
The Spam Act 2003 and guidance from the Australian Communications and Media Authority make sender identification and consent important for commercial electronic messages. Authentication does not replace those obligations, and a compliant business can still have an imperfect DKIM setup. Privacy considerations under the Privacy Act 1988 also make careful handling of customer email data and authentication reports important.
Practical checks for domain owners
Start by identifying every service that sends mail using the domain. Check the SPF record for duplicate records, excessive DNS lookups and unauthorised providers. Then confirm that each platform signs messages with DKIM, publishes the correct selector, and uses a signing domain aligned with the address recipients see.
Send test messages to several providers and inspect the complete headers rather than relying on a mailbox banner. DMARC aggregate reports can reveal which systems pass SPF, which fail DKIM and where unexpected sources are appearing. For engineering teams, these developer verification tools can support repeatable checks across multiple domains.
When the pattern deserves escalation
A DKIM failure is more concerning when the message asks for an urgent payment, requests a password, uses a newly registered lookalike domain or contains links that do not match the claimed organisation. It also deserves attention when SPF passes for an unfamiliar infrastructure provider, DMARC fails, or the visible From domain does not align with either authentication result.
Recipients should verify sensitive requests through a known phone number or established website, rather than replying to the suspicious message. Domain owners should investigate repeated failures, especially across invoices, payroll notices and customer account alerts. SPF success is useful evidence about the sending route, but the complete authentication and behavioural context determines whether an email is trustworthy.