## TL;DR
Accept that a footer changes the body and therefore breaks a simple body hash, then fix the path that can actually survive it: set the list to not modify the body, or rely on the original sender DKIM with relaxed handling where possible, or have the list re-sign with its own aligned domain after modification. Test with a real list message and confirm which signature the receiver can still verify.

```text
dkim=neutral "signature did not verify" after mailing list added footer
```

## Use this when
- Direct mail from the sender passes DKIM, but mail through the list shows dkim=neutral with signature did not verify.
- The list adds a footer, subject tag, or unsubscribe block.
- DMARC for list mail depends on the original sender signature surviving.

## Not for this skill when
- The message has no DKIM-Signature at all after the list. That is signature stripping, a different fault.
- Your own outbound mail fails DKIM without any list involved. That is a signing or key problem.

## Steps
1. Send the same message direct and through the list, save both delivered copies, and diff the bodies and headers. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the exact list modification that changes the signed body is visible
2. Check the sender signature canonicalisation in the DKIM-Signature header, noting whether body canonicalisation is simple or relaxed. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: you know whether small whitespace changes would already break this signature
3. Change the list configuration to stop modifying the body where the list software allows it, or switch the list to wrap or re-sign mode deliberately. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: a test list message either keeps its original body intact or carries a new list signature
4. If the list re-signs, confirm the signing domain and its DNS key record, and check how that interacts with DMARC for the original From domain. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the re-signed message verifies for the list domain and the DMARC outcome is understood and accepted
5. Send a final list test to an external mailbox and read Authentication-Results. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the delivered list mail shows a verifiable DKIM result instead of neutral

## Why it happens
DKIM signs a hash of the body as sent. Mailing lists classically append footers, rewrite links, and tag subjects, and every one of those edits invalidates a signature computed over the original body. The neutral verdict means the signature present could not be verified against the modified content. Well run lists either leave the body alone, or take ownership by re-signing, and ARC helps receivers see the original authentication when a list must modify mail.

## Variants and edge cases
### dkim neutral signature did not verify mailing list footer
The exact header and list phrasing from the failing message.
### mailing list breaks dkim dmarc footer added fix
The fix-seeking variant list owners search.
### mailman google groups dkim fail after footer re-sign arc
The product variant naming common list platforms and ARC.

Compatibility: RFC 6376 DKIM, RFC 8617 ARC, Mailman 3, Google Groups, Microsoft 365 group mail.

Edge cases to check:
- Subject tagging breaks header hashes too, not just footers; check both modifications.
- Some lists convert HTML to plain text, which is a total body rewrite and no canonicalisation setting will save the original signature.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cveBCampgllVsqlvBnC2hA