When valid DKIM signatures support phishing attacks
A valid DKIM signature can create a false sense of security. It proves that an authorised system signed an email and that the signed content has not been altered in transit. It does not prove that the sender is trustworthy, that the account owner approved the message, or that the service itself has not been compromised.
Cybercriminals exploit this distinction by abusing legitimate third-party platforms such as marketing systems, help-desk tools, cloud applications and transactional email providers. If attackers gain access to a customer account, they may send convincing messages through infrastructure that already has a strong domain reputation.
This risk is relevant to Australian organisations of every size, from a Brisbane retailer using a cloud CRM to a Sydney accounting firm handling payroll information. Email authentication remains essential, but its signals must be interpreted together rather than treated as a simple pass-or-fail security control.
What a DKIM pass actually proves
DomainKeys Identified Mail attaches a cryptographic signature to selected email headers and the message body. The receiving mail server retrieves a public key from DNS and checks whether the signature matches. If it does, the message passed DKIM verification for the signing domain.
That result confirms message integrity and authorisation at the signing service level. It does not assess the sender’s motives. A compromised newsletter account can produce a perfectly valid signature, as can an abused support mailbox or stolen API credential. The email may therefore pass DKIM while carrying a malicious link, fraudulent invoice or credential-harvesting request.
How attackers abuse trusted services
An attacker may compromise a user account in a SaaS platform, steal an SMTP password, exploit an exposed API token or take control of a service administrator’s login. They can then create a campaign that is delivered through the provider’s approved infrastructure. The provider signs each message using its normal DKIM key, giving the email a technically legitimate appearance.
The attack becomes more effective when the service has a recognised sending domain or when the compromised customer’s domain is configured correctly. Recipients may see familiar branding, realistic message formatting and a DMARC pass. Security teams that rely heavily on authentication results can miss the behavioural warning signs.
Why DMARC alignment still matters
DMARC evaluates whether the visible From domain aligns with a domain that passed SPF or DKIM. A message can pass DKIM for a third-party platform but fail alignment if the signature belongs to an unrelated provider domain. Properly configured custom DKIM signing and aligned domains make detection more useful, although alignment cannot identify a legitimate account that has been hijacked.
Organisations should review authentication results, sending sources, message volume, recipient patterns and domain reputation together. The anti-spoofing guidance can help teams assess whether their DMARC policy and reporting process are working as intended.
| Signal | What it confirms | What it cannot confirm |
|---|---|---|
| DKIM pass | The signature matches the published key | The sender’s intent or account safety |
| SPF pass | The sending server is authorised by the envelope domain | That the message is free from phishing content |
| DMARC pass | SPF or DKIM aligns with the visible From domain | That the aligned account was not compromised |
| Reputation check | Historical trust and sending behaviour | Whether a new compromise has already occurred |
| User report | Suspicious content noticed by a recipient | The full scale of the campaign |
Compromised keys create a separate risk
Attackers may also target the signing key itself. If a private DKIM key is exposed, they can potentially sign messages outside the expected sending workflow, depending on how the organisation has configured its mail systems. Weak access controls, old integrations and unmanaged third-party vendors increase the exposure.
Regular rotation limits the usefulness of a stolen key. Organisations should maintain an inventory of selectors, remove obsolete DNS records and use separate keys for different systems where practical. Guidance on DKIM key rotation explains why changing keys is part of ongoing email security rather than a one-time setup task.
What Australian organisations should monitor
Australian businesses commonly use Microsoft 365, Google Workspace and specialist platforms for invoices, bookings, customer service and marketing. A compromise in one connected service can affect customers in Melbourne, Perth or regional communities without appearing to originate from the organisation’s main mail server. Monitoring new sending sources and unexpected changes in volume can reveal abuse earlier.
Legal and regulatory obligations also raise the stakes. The Spam Act 2003 governs commercial electronic messages, while the Privacy Act 1988 and the Notifiable Data Breaches scheme may become relevant when a breach exposes personal information. Organisations operating in health, finance or government supply chains may also face contractual security requirements that make sender monitoring and incident records important.
Turning authentication into a layered defence
DMARC should be deployed with reporting, clear ownership and a staged policy approach. Start by identifying legitimate senders, validating SPF and DKIM configuration, and reviewing aggregate reports. Once unknown sources are understood, move towards a restrictive policy such as quarantine or reject, while watching for legitimate services that need alignment.
Human verification remains valuable because a valid signature cannot evaluate business context. Staff should be taught to inspect unusual payment requests, unexpected attachments, urgent login prompts and changes to supplier bank details. Practical staff authentication training can help non-technical teams understand why a DKIM pass is useful evidence, but never a complete guarantee.
A sender and domain trust check can add another layer by highlighting reputation changes, authentication gaps and suspicious infrastructure. Combined with multifactor authentication, least-privilege access, vendor reviews and rapid credential revocation, these controls reduce the chance that a compromised third-party service becomes a trusted delivery channel for fraud.