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

Question

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

Hugo Lorenzo Mato 0

We send marketing newsletters through Azure Communication Services Email (SMTP relay smtp.azurecomm.net:587, customer-managed domain; Domain, SPF, DKIM and DKIM2 all Verified; DMARC p=reject).

Each message carries the RFC 8058 headers:

List-Unsubscribe: <https://example.invalid/unsubscribe/...>

List-Unsubscribe-Post: List-Unsubscribe=One-Click

At the receiver (Gmail) the message arrives in the Inbox with SPF=pass, DKIM=pass and DMARC=pass, and both headers arrive intact and unencoded. However, the DKIM signature that ACS applies is:

DKIM-Signature: ... d=<our domain>; s=selector1-azurecomm-prod-net; h=from:to:cc:subject:date:messageid ...

RFC 8058 section 4 says: "The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the 'h=' tag of a valid DKIM-Signature header field. If the message does not have the required DKIM signature, the mail receiver SHOULD NOT offer a one-click unsubscribe." Google's bulk sender requirements (February 2024) require one-click unsubscribe for senders above 5,000 messages/day. Because ACS does not include those two headers in h=, a message sent through ACS can never be eligible for one-click unsubscribe, regardless of what the sender does on its side.

Questions:

Is there any setting on the Email Communication Service or the domain resource to include List-Unsubscribe and List-Unsubscribe-Post (and ideally Reply-To, MIME-Version, Content-Type and Feedback-ID) in the DKIM h= tag when they are present in the message? If not, can this be treated as a product request? It is a MUST in RFC 8058 and a requirement of the major mailbox providers.
Which headers does the SMTP relay add, rewrite or re-encode between submission and delivery (Message-ID, Date, Content-Transfer-Encoding, body re-encoding)? Does the REST/SDK path sign differently from the SMTP path?
Does the relay preserve, unmodified, a DKIM-Signature header added by the client before submission (own selector under the same verified domain, covering those two headers), so that the message would carry two valid signatures? An earlier thread (question 1693203) suggests a client-side signature can arrive preserved but failing verification.
Will the ACS opt-out management feature (preview) emit RFC 8058 headers itself for SMTP submissions, so that senders do not end up with two competing List-Unsubscribe headers?

Observed with Azure Communication Services Email over SMTP, September 2026. Our quota case (2609020050002510) was about sending limits only; this is a separate product question.

Hugo Lorenzo Mato 0 Reputation points

2026-09-08T05:38:12.71+00:00

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.
Santhi Siruvuri 0 Reputation points Microsoft External Staff Moderator

2026-09-10T19:45:04.3366667+00:00
Hello @Hugo Lorenzo Mato ,

Thanks for the detailed question.

The ACS-generated DKIM signature uses a fixed header set (h=from:to:cc:subject:date:messageid …). List-Unsubscribe and List-Unsubscribe-Post are not included, so the message cannot satisfy the MUST requirement in RFC 8058 §4 even when the headers themselves arrive intact and unencoded. There is no setting on the Email Communication Service or domain resource that extends the signed header list; DKIM composition is service-owned (customers only provision the DNS records).

I’ve raised this as a design change request with the ACS Email product group (include both unsubscribe headers in the ACS signature after any internal transformation, or reliably preserve a valid client-applied signature covering them).

In the meantime, the practical path that avoids the body-hash breakage you’ve observed is:

Prefer the REST/SDK send path over SMTP. ACS constructs the MIME itself, so you eliminate the renormalization class of failures (MIME boundary changes, 8bit → quoted-printable, etc.).

Pass the two headers through the supported custom-headers surface:

.NET: EmailMessage.Headers (IDictionary<string, string>)

JavaScript / other SDKs: the equivalent headers dictionary See the official guidance: https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-headers

This gets the headers delivered correctly and keeps the ACS signature valid, but it still does not put the unsubscribe headers under the ACS h= tag, so full RFC 8058 one-click eligibility is not achieved yet.

A few related notes that match your questions:

The opt-out management feature (currently in preview) is a domain-level suppression list. It does not emit List-Unsubscribe / List-Unsubscribe-Post headers, so you won’t get competing headers. Because it is preview, there is no SLA and it is not recommended for production workloads.

Watch the reserved x-ms-acsemail-* headers (especially x-ms-acsemail-validate-message-id) so you don’t unintentionally lose or replace your Message-ID.

SMTP path transformations are not fully documented; the REST path is the more predictable surface for header integrity.

Relevant documentation:

https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-headers

https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-domain-and-sender-authentication

https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-smtp-overview

https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-optout-management

https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/email/add-custom-verified-domains

Kindly let us know if the above information helps or you need further assistance on this issue. Thanks.

1 answer

Your answer

Answer 1

Hi @Hugo Lorenzo Mato

Your analysis is correct, and I'll be straight about which of your four questions have real answers and which only the product group can resolve.

No, there is no setting for this. The only DKIM surface exposed to customers on the Email Communication Service or domain resource is publishing the two selector CNAMEs. The h= header set is fixed by the platform signer, and nothing in the resource, the SMTP relay options or the SDKs lets you extend it. So your conclusion stands: as of today, mail signed only by ACS cannot be RFC 8058 eligible, since the spec requires List-Unsubscribe and List-Unsubscribe-Post to be covered by a valid DKIM signature, and Gmail enforces one-click unsubscribe for senders above 5,000 messages/day. Yes, this should be a product request, and this thread is a good vehicle for it. Ask explicitly that a moderator log it with the ACS Email product group as a design change request, and file the same text through a support ticket labeled as a DCR rather than a break/fix. Your framing (RFC 8058 section 4 MUST plus the mailbox provider mandates) is exactly the evidence such requests need.
Not publicly documented, and nobody outside the product team can enumerate the relay's rewrites or confirm whether the REST path signs differently from SMTP. What you can do is settle it empirically for your exact content: send an identical MIME message through smtp.azurecomm.net and through the REST SDK to a mailbox you control, then diff the raw delivered sources against your submission. That diff answers which headers are added or normalized and whether the body bytes are re-encoded, and it becomes hard evidence for the DCR.
Two signatures are structurally legal, and receivers evaluate each DKIM-Signature independently, so a valid client-side signature with your own selector on the same domain covering those two headers would satisfy RFC 8058 on its own. The field report you cite (signature preserved but failing) means the pipeline mutates something the client signed. If you want to give it a fair test: use relaxed/relaxed canonicalization, sign the minimal set (From, Subject, List-Unsubscribe, List-Unsubscribe-Post) and deliberately exclude Date, Message-ID, To, Cc, MIME-Version, Content-Type and Content-Transfer-Encoding, since those are what relays typically touch. After that, the only remaining failure point is bh=. If your diff from question 2 shows the body is re-encoded, then no client-side signature can survive this relay and the DCR is the only path. If the body is byte-identical and it still fails, the diff will show which signed header got touched.
The public docs describe opt-out management as a centralized managed unsubscribe list meant to help meet one-click requirements, but they don't document injecting RFC 8058 headers into SMTP submissions, or how it would interact with sender-supplied List-Unsubscribe headers. That's genuinely unanswered publicly, so fold it into the same product group escalation rather than trusting any guess here. Until then, keep emitting your own headers.

Bottom line, being honest with you: questions 2 and 4 have no public answer, question 1 is a confirmed product gap, and question 3 has a real but unproven workaround that your own diff test will confirm or kill. The moderator escalation plus a DCR ticket is the correct route, and you've already written the justification better than most requests I've seen.

References: https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/email-optout-management https://datatracker.ietf.org/doc/html/rfc8058#section-4