Reading DMARC reports with multiple DKIM signatures

When you open a DMARC aggregate report and see two or three different DKIM signatures attached to messages that look identical, the first reaction is often confusion. The report says one domain passed, another failed, and a third signature appears from a sender you don't even recognise. For Australian IT teams managing everything from Sydney headquarters to remote offices in Perth, these reports are an everyday reality, and untangling them is part of keeping email channels trustworthy.

The good news is that multiple DKIM signatures are not necessarily a sign of an attack. They usually reflect how modern email pipelines work: messages pass through relays, third-party senders, and forwarding services that each add their own signature. Learning to read these reports properly helps you spot genuine spoofing attempts and separate them from the harmless complexity of legitimate email routing.

What a DMARC report actually contains

A DMARC aggregate report, sent daily by receiving mail servers, is an XML file that summarises how your domain's messages were handled. It records the source IP, the sending domain, the SPF result, and the DKIM result. Each row represents a batch of messages, not a single email, so a single report can contain thousands of rows from dozens of senders.

The DKIM section is where most of the confusion arises. A single message can carry more than one DKIM signature, and the report lists the result for each signature independently. If you only glance at the top-level DKIM field, you may miss signatures underneath. The structure means you need to look at every signing domain reported, not just the one you expect to see.

Why multiple DKIM signatures appear in one report

There are several legitimate reasons why a message might arrive with signatures from different domains. A common case involves ESPs that sign outbound mail with their own corporate domain alongside the client's domain, a practice known as double signing. Another case involves mailing list managers that wrap messages and add their own signature when redistributing content to subscribers.

Forwarding also plays a role. When an Australian employee forwards a message through a third-party service, that service may re-sign the message with its own key. You may also see signatures from cloud-based relay services used by marketing teams in Melbourne or Brisbane offices. Each of these scenarios produces a separate DKIM result, and each one must be evaluated on its own merits.

Reading the DKIM results for each signing domain

Within the report, each DKIM result includes the signing domain (d tag) and the selector (s tag). The selector tells you which specific key signed the message. Two signatures from the same domain but different selectors usually point to a planned key rotation, a topic covered in detail in guides on why DKIM key rotation matters for email security review.

A passing signature means the cryptographic check succeeded and the message body was not altered in transit. A failing signature means the receiving server could not verify the message, often because the public key was missing from DNS, was rotated without proper overlap, or because the message content was modified after signing. When you see one signature pass and another fail, focus on which domain and selector the failure relates to before drawing conclusions about spoofing.

Common patterns and what they mean

A signature from a domain you do not operate is not automatically malicious. Many SaaS platforms sign messages on behalf of their customers, so a signature from a marketing automation vendor is expected if you use that vendor. The pattern to watch is a signature from a domain with no connection to your sending infrastructure, especially when it is the only signature that passed while your own domain failed.

Another pattern worth noting is repeated failures from the same selector across many messages. This often points to a stale DNS record or a selector that was disabled but is still referenced by older systems. For Australian businesses subject to the Notifiable Data Breaches scheme, persistent authentication failures can indicate a configuration drift that increases the risk of a successful phishing campaign impersonating your brand.

Security risks and compliance implications in Australia

Australia's Cyber Security Centre and the Australian Signals Directorate both recommend strict email authentication as part of the Essential Eight maturity model. DMARC enforcement at p=reject is the strongest posture, but reaching it requires confidence that every legitimate sender is signing correctly. When reports show inconsistent results across multiple signing domains, reaching that posture becomes harder.

For sectors such as banking and superannuation, regulators including APRA and AUSTRAC expect demonstrable controls over outbound communications. A DMARC report full of unexplained DKIM signatures can undermine that evidence. Local teams often find that running a domain check through Trusted Sender Score gives them a clearer baseline for which senders are trusted and which deserve scrutiny.

Practical steps to investigate and fix the issue

Start by exporting the report and grouping rows by signing domain. For each domain you do not recognise, check whether your organisation uses that provider and whether the DKIM key is published in your DNS. Tools that consolidate authentication data can speed this up considerably, and you can review live authentication results through the dedicated metrics dashboard.

Once the legitimate senders are mapped, look at the selectors that are failing. Update stale keys, publish missing TXT records, and document every provider that signs on your behalf. Regular reviews of these reports, ideally weekly, will keep your authentication posture aligned with the expectations of Australian customers and regulators, and will make future reports far easier to read.