When One Subdomain Produces a Flood of DKIM Failures

A DMARC report with a high number of DKIM failures from a single subdomain deserves prompt investigation. It may reflect a simple configuration error, such as an expired selector or a new email provider that was not added to the domain’s authentication settings. It can also indicate that someone is attempting to send unauthorised messages using a trusted organisational identity.

The subdomain is an important clue. Mail systems often separate marketing, transactional, support and employee communications into addresses such as news.example.com or mail.example.com. A concentrated DKIM failure pattern therefore helps security teams narrow the investigation instead of treating every authentication event across the entire domain as equally suspicious.

DMARC evaluates whether the visible From address aligns with an authenticated DKIM signature or an SPF-authenticated sending source. A DKIM failure alone does not prove that a message is malicious. Forwarding, mailing lists, message rewriting and third-party platforms can break a signature after a legitimate message leaves the organisation.

For Australian businesses, this matters across a varied email environment: a Sydney retailer may use separate platforms for receipts and campaigns, a Melbourne SaaS company may send from several cloud providers, and government impersonation scams often rely on familiar-looking addresses. Clear interpretation of reports helps distinguish operational faults from spoofing and phishing activity.

What The Failure Pattern Reveals

A sudden rise in DKIM failures from one subdomain usually means that one sending path has changed. Common causes include a provider migration, a missing public key in DNS, an incorrect selector, a signing key that has expired, or a platform sending with a From domain it is not authorised to use. A deployment may also have changed the subdomain while leaving old authentication settings in place.

The volume and timing provide useful context. Failures beginning immediately after a marketing campaign or CRM change are more likely to be configuration-related. Failures spread across unrelated networks, countries and mail providers without any known business event may indicate spoofing or an abused account. DMARC aggregate reports show counts, source IP addresses, disposition and authentication results, allowing these patterns to be compared over time.

Why DKIM Failure Is Not Always An Attack

Email forwarding can invalidate DKIM because an intermediary modifies headers or content. Mailing lists may add footers, unsubscribe links or subject tags, which causes the cryptographic signature to fail. Some security gateways also rewrite URLs or scan attachments in ways that affect signed content. A legitimate message can therefore arrive with a failed DKIM result even when the original sender was authorised.

DMARC can still pass when SPF aligns with the visible From domain, so an isolated DKIM failure may have little impact on delivery. The risk becomes higher when both DKIM and SPF fail, the source is unfamiliar, the message claims to be from finance or government, or the subdomain has no documented business purpose. Analysts should compare the report with known senders before blocking a provider.

Security Risks Behind a Single Subdomain

An attacker may select a subdomain because it has a strong reputation or is overlooked by the organisation’s monitoring. If the subdomain is used for invoices, password resets or customer support, convincing spoofed messages can lead to credential theft, payment redirection or malware delivery. A compromised mailbox or cloud application can also send authentic DKIM-signed messages, making account security as important as DNS configuration.

Look for repeated source IP addresses, unusual geographic origins, unfamiliar user agents and message volumes outside normal Australian business activity. A subdomain sending thousands of messages overnight from infrastructure unrelated to the organisation requires escalation. Review cloud audit logs, application tokens, mailbox forwarding rules and recent DNS changes, while preserving report data for incident response.

How To Investigate And Correct It

Start by identifying every legitimate service allowed to send for the affected subdomain. Check the DKIM selector published in DNS, confirm that the key matches the provider’s current configuration, and verify that the provider signs with the same domain used in the From address. Rotating keys after a suspected compromise should be coordinated carefully so valid services do not lose authentication.

Review alignment mode, SPF limits and the DMARC policy applied to the subdomain. A parent domain policy may apply unless a specific subdomain policy is published. Test real messages from each platform, including forwarded mail, and inspect their headers. Domain owners who need platform access can follow the process to become a domain admin before reviewing trust and authentication data.

Using Reports For Ongoing Protection

Monitoring should separate marketing, transactional and internal traffic so a failing campaign service does not hide a more serious event. Set alerts for unusual source countries, rapid increases in failures and new senders. Bulk domain checking can help security teams review related subdomains, while API-based checks can feed authentication results into ticketing, SIEM or email governance workflows.

Australian organisations handling personal information should also consider the Privacy Act 1988 when investigating message content and report data. DMARC reports may contain source details and forensic samples, so access should be restricted and retention should match internal privacy controls. For teams validating messages that appear to come from public bodies, resources on how to verify agency email can support a safer review process.

A stable DKIM pass rate is useful, but it is not the sole measure of trust. Combine DMARC results with SPF alignment, domain reputation, mailbox protection, phishing reports and changes in sending infrastructure. SaaS operators can also monitor SaaS authentication as part of release and vendor-management procedures, reducing the chance that a single overlooked subdomain becomes a channel for fraud.