Identify the operation behind the address
An address called a group can distribute copies, collect messages in a shared mailbox, or run a mailing-list workflow that edits and redistributes posts. Those operations have different authentication consequences. Classify the actual handling steps before asking why a group message failed DMARC. A familiar product label does not establish the outgoing envelope, signed content or receiver decision.
This guide compares proposed evidence, not inspected accounts. No group membership, shared mailbox, list configuration or original delivery sample was accessed. The fictional flows below illustrate how to ask better questions. Required original evidence: Direct and indirect delivery samples with route, envelope, signatures and trusted results compared.
Distinguish distribution from shared access
Microsoft describes Exchange Online distribution lists as a way to distribute messages and distinguishes them from dynamic groups, security groups and Microsoft 365 groups. Its shared-mailbox documentation instead describes several people accessing the same mailbox, with appropriate permissions for sending as or on behalf of that mailbox. These documented purposes do not predict how a particular tenant routes an external copy. Microsoft distribution lists Microsoft shared mailboxes
Separate receiving a message into shared storage from forwarding it elsewhere and from composing a reply. An employee opening a stored message has not thereby created another SMTP hop. A forwarding rule can create one. A reply sent using the shared address is a new outgoing message whose author domain and signing configuration need their own assessment. Record which operation the reported failure actually concerns.
Trace the envelope and message independently
At each SMTP boundary, record the connecting host and MAIL FROM identity separately from the visible RFC5322.From. SPF evaluates the sending connection against the relevant envelope identity. A redistributed message can retain the original visible author while reaching the next receiver from a different server. That difference is a reason to investigate SPF, not proof that every distribution mechanism must fail. RFC 7208 sections 2.4 and 4
DKIM follows a different dependency. A signature identifies its signing domain and covers selected header instances plus the canonicalized body, subject to any body-length limit. Merely sending the same content to additional recipients does not necessarily alter those inputs. Editing covered material may invalidate the signature, while a change removed by the selected canonicalization can leave verification unchanged. Inspect the actual h=, c= and any l= values. RFC 6376 sections 3.4–3.5
Recognize when a list becomes a mediator
A mailing-list manager may add a subject prefix, footer, list headers, digest packaging or a replacement author address. RFC 7960 documents these indirect-flow patterns and their interoperability problems. Use it as an explanation of possible transformations, not evidence that a named list enabled every feature. Capture the message before and after redistribution to establish which transformations occurred. RFC 7960 section 3.2.3
Evaluate every relevant DKIM signature independently. A list's additional signature does not repair an original signature whose covered content changed. For DMARC, a valid signature is useful only when its signing domain aligns with the author domain being evaluated. Likewise, SPF passing for a list-controlled envelope domain does not establish alignment with an unchanged external author domain. RFC 6376 section 4.2 RFC 9989 sections 3.2.10 and 5.3.5
Compare two fictional delivery branches
Imagine a fictional message from alex@writer.example addressed to discussion@club.example. One branch distributes an otherwise unchanged copy to an external member. Another list branch appends a footer after the original writer.example DKIM signature was added. Assume that signature originally verified, covers the full body and uses relaxed body canonicalization. These are explicit scenario assumptions, not observed results.
On the unchanged branch, the original signature can remain valid, subject to its other verification requirements. The added footer on the second branch changes the covered canonicalized body and invalidates that signature. If neither branch has aligned SPF, the first can still have an aligned DKIM path while the second needs a different explanation or mitigation. A fresh list-domain signature alone cannot align with the unchanged writer.example From address. RFC 6376 section 3.4.4 RFC 9989 section 5.3
Locate trustworthy authentication observations
Preserve the original raw copies and identify who inserted each Authentication-Results field. A result written at the organization's trusted ingress can describe the message before an internal modification. A downstream check describes the later representation. Both can be accurate at their respective boundaries. An arbitrary sender-supplied result header is not equivalent evidence; RFC 8601 requires a trust-boundary model for consuming these assertions. RFC 8601 section 7
If ARC appears, record its chain validation and the receiver's trust decision separately. RFC 8617 is Experimental and ARC is not a universal trust framework. The official proposal to reclassify it was an active Internet-Draft when reviewed on 8 November 2026, not an approved replacement specification. Neither an ARC header nor an accepted message proves that the original DKIM signature currently verifies. RFC 8617 section 9.3 IETF ARC status proposal
Choose a repair that fits the flow
The proposed decision should identify the actual failing branch: unauthorized envelope use, covered-content modification, incorrect author identity, or a receiver-specific trust decision. Then consider supported configuration changes with the service owner. Preserve required security processing and user expectations rather than disabling group features broadly. No permission to alter a group, tenant, signer or list is implied by this analysis.
An approved verification should compare a direct control with the relevant indirect branches, including external members and shared-address replies where in scope. Retain raw messages, timestamps, route evidence, signature details and results from known evaluators. Until those samples exist, the defensible output is a flow map and a test plan, not a declaration that the organization's groups are DMARC-safe.