Investigating a DMARC quarantine surge

A sudden spike in failed DMARC quarantine events from one subdomain calls for a rapid, evidence-led investigation. It is not, by itself, proof of a breach: receiving servers have applied a DMARC disposition after the visible sender or its authentication chain failed the required checks.

Common causes include a new mail service, a broken DKIM selector, an SPF record changed during migration, message forwarding, or a mailing platform rewriting the From address. The decisive issue is whether the traffic came from a known sending path or from infrastructure the organisation does not recognise.

Australian teams should also account for local operating conditions. A domain may serve a Sydney office and a Melbourne branch while an outsourced managed service provider administers it. Logs can mix AEST or AEDT with UTC, and hostnames may sit under .com.au, gov.au or edu.au namespaces.

Confirm the change is real

Preserve the relevant XML aggregate reports before filters or rotation remove them. Count events by reporting mail server, source IP, DKIM signing domain, envelope-sender domain and disposition, then separate quarantine failures from policy or reporting failures. Raw totals alone can be misleading when a large recipient mailbox changes providers.

Compare the affected subdomain with its own previous four to eight weeks and with sibling subdomains over the same period. Look for a matching DNS edit, service launch, campaign or ticket in Australian local time. For organisations with several hostnames, the domain administration guide can help named owners coordinate access to reputation and authentication checks.

Check DNS and alignment

Check authoritative DNS for DMARC records on both the organisational domain and the affected subdomain, including rua and ruf destinations, SPF TXT records, and active DKIM selectors and public keys. If a subdomain lacks its own policy, confirm whether the organisational-domain record or its sp value supplies the inherited setting.

Map each message’s RFC5322.From, original envelope sender, Return-Path and DKIM d domain. Relaxed alignment permits a shared organisational domain, while strict alignment requires an exact match. Selector rotation, a missing CNAME, split-horizon DNS or a provider outage can therefore produce a clean-looking failure; the DMARC troubleshooting FAQ explains the key record relationships.

Trace the sending path

Obtain several quarantined samples with full headers and compare Authentication-Results, ARC chains, Received hops, destination and source IP addresses. Remove personal content before circulating evidence, but retain enough detail to determine which identifier was expected and which one failed.

Follow the source IP to a known mail relay, CRM, invoice system, support desk, list manager or compromised account. Cloud providers may publish broad address ranges, so an unfamiliar IP is not automatically hostile. Check reverse DNS, passive DNS history, observed certificates and sender reputation, then compare those findings with the application and mailbox activity that generated the mail.

If the hostname belongs to your organisation, claim domain administrator access before running bulk checks or assigning an owner to follow-up evidence.

Separate misconfiguration from compromise

Classify the spike before changing policy. One familiar source after a migration usually indicates authentication breakage; an unknown source sending at abnormal volume may indicate account takeover, an open relay or unauthorised use. Many unrelated sources sharing a new lookalike hostname can point to a phishing campaign.

For Australian customer-facing services, preserve suspicious messages and indicators for the Australian Cyber Security Centre or Scamwatch, and avoid public discussion that helps senders adapt. Reputation is supporting evidence, not proof: a legitimate supplier can share infrastructure with abuse, while a low-scoring new domain can still be malicious.

If the investigation exposes personal information from Australian records, involve privacy counsel and assess the Notifiable Data Breaches scheme under the Privacy Act 1988 with the Office of the Australian Information Commissioner. Containment should proceed even when notification is not required.

Contain, fix and verify

Act on the cause. Revert unauthorised DNS changes, revoke exposed tokens, reset affected accounts, remove malicious forwarding rules and block confirmed hostile sources at the gateway. For a legitimate but broken sender, correct its SPF authorisation, restore the intended DKIM key or route it through the approved relay instead of deleting authentication records.

Do not jump straight from quarantine to reject while legitimate mail is still failing. Confirm that the organisational domain and every delegated subdomain have the intended protection, then tighten subdomain policy after clean authentication results appear. Keep failed samples and decisions for audit, including who approved each DNS change.

Monitor the affected subdomain and sender combinations across at least two complete DMARC reporting cycles. A sustained return to baseline, stable aligned DKIM or SPF results and no unexplained source traffic demonstrate recovery. Record the root cause, owners and preventative control so the next volume change is recognised quickly.