ACS Email: DKIM signature does not cover List-Unsubscribe / List-Unsubscribe-Post, so RFC 8058 one-click unsubscribe is never eligible

Update on 8 September 2026, 17:20 UTC, after independently reviewed controlled tests.

Earlier today, two messages sent through our real PHP campaign worker had correlated Delivered events and originals in INBOX. Their valid native ACS signatures omitted List-Unsubscribe and List-Unsubscribe-Post. Their additional sender signatures covered both headers but failed with a body hash mismatch. No pre-SMTP capture was retained for those earlier messages.

We have now completed a separate internal diagnostic pair, one using only ACS signing and one additionally signed by the sender. Both have correlated Delivered events and received originals. The exact prepared MIME, SMTP DATA input, message bytes written by the SMTP client, and received original were retained privately.

For the sender-signed multipart sample, the complete sender DKIM header, including b= and bh=, is identical before submission and in the received original after normalizing LF/CRLF line endings. The sender signature validates independently against the prepared MIME, SMTP DATA input and captured message bytes written by the SMTP client. In the received original, MIME boundaries differ and both text parts have changed from 8bit to quoted-printable; decoded content remains equivalent. The sender signature fails with a body hash mismatch, while the ACS signature validates.

The pre-submission and received relaxed-canonicalized bodies also differ for this sample. This is not a claim that every possible format must fail. The DATA evidence captures local client writes, not packets observed at the ACS server. These requested diagnostic messages contain no List-Unsubscribe headers and do not demonstrate RFC 8058 compliance.

Our earlier isolated PHPMailer 7.1.1 checks also remain relevant: six synthetic signatures survived local SMTP DATA processing; eighteen header/body alterations were detected. A fresh relaxed/relaxed signature tolerated equivalent whitespace but failed after a MIME boundary change.

Correction to the initial question: universal impossibility was too broad. A valid additional signature covering both unsubscribe headers could satisfy RFC 8058; we have not demonstrated a supported way to preserve one through this flow. Signing fewer headers does not resolve a changed body. Receiver obligations differ, so we are evaluating a restricted native-signature route without claiming RFC 8058 compliance or waiving receiver policies. Commercial sending remains paused.

Could a moderator route this evidence to the ACS Email product group as a design change request and confirm a supported solution: either include both unsubscribe headers in the ACS-generated signature after transformation, or preserve a valid sender-applied signature? Please also clarify the supported SMTP opt-out/header behavior. If REST provides a solution, identify the exact contract: the published 2025-09-01 send API accepts structured content, not an identical raw MIME submission.

This updates the existing report. No recipient data, message identifiers, unsubscribe tokens, MIME or private keys are included.

Hi @Hugo Lorenzo Mato ,

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?

Hi @Santhi Siruvuri,

Thanks for following up, and thanks for the clear reply. It is the first authoritative statement we have that DKIM composition is service-owned and that the signed header set cannot be extended, which is genuinely useful.

To answer your question directly: no, the issue is not resolved. Two of the four questions are now settled, two are not, and the suggested workaround does not address the one that matters.

What is settled. Question 1 is confirmed as a product gap. Question 4 is answered: opt-out management is a domain-level suppression list and does not emit the headers. I verified that against the public documentation, which never mentions RFC 8058, DKIM or the two headers anywhere on the page. One documentation note, if you can route it: that page states the feature "helps developers meet the guidelines of email providers that require a one-click unsubscribe implementation". It reads as if the feature delivered one-click eligibility, which your reply makes clear it does not.

Why the workaround does not help us. As you write yourself, custom headers "still does not put the unsubscribe headers under the ACS h= tag", so the RFC 8058 section 4 MUST is still unmet. On our side the headers already arrive intact and unencoded over SMTP, so that was never the failure. Moving to REST also removes the only remaining candidate path, because ACS builds the MIME and a client therefore cannot compute a body hash for its own signature. For our scenario REST is a rewrite with no gain, so we are not pursuing it.

Five specific things I am asking for.

1. The tracking ID for the design change request, its status (under consideration or accepted) and any expected timeframe, even a quarter. I am not asking for a commitment, I am asking for something I can plan against.
2. A public item we can follow. There is currently no issue mentioning DKIM in the Azure/Communication repository, so today the request is not trackable by any customer. Filing it there, or pointing me at an equivalent public entry, would solve that.
3. An explicit on-record confirmation that no current ACS send path (SMTP or REST, any API version, any preview feature) produces a DKIM signature covering List-Unsubscribe and List-Unsubscribe-Post. A yes or no lets us close our internal evaluation.
4. Whether preserving a valid client-applied signature is in scope of that design change request or explicitly out of scope. That single answer decides whether we wait or move the traffic.
5. On question 2, which remains unanswered: can the product group document the SMTP relay transformations (multipart boundary regeneration, 8bit to quoted-printable), even as a known-behaviour note? That is precisely what breaks client signatures. We retained the before and after evidence privately and will share it through whatever channel the product group prefers.

For calibration on why I am asking for a date rather than an intention: opt-out management has been in public preview since April 2024 and is still in preview today, so "raised with the product group" is not something we can plan a sending strategy around.

For context, and not as pressure: we are not blocked on delivery. Our volume is below Gmail's bulk sender threshold, so one-click unsubscribe is not required of us today, and commercial sending remains governed by our own controls. But since ACS cannot satisfy RFC 8058 at all, the only compliant option available to us if we ever cross that threshold is a provider whose platform signature already covers both headers. That is a migration we would rather not make.

Your comment is the authoritative confirmation we were missing, and I am glad to have it on record. If it helps to close this out formally, post it as an answer and I will accept it as confirmation of the gap. What I would ask is that the thread not be treated as resolved on the merits, or if it has to be closed, that you point me at the tracking item so the request survives the closure.

Thanks again for routing this to the product group.