Should I include List-Unsubscribe headers in transactional emails and what are the DKIM best practices?
Yes, I would include List-Unsubscribe headers in any transactional email that a recipient can reasonably treat as unwanted, especially account creation, invite, notification, trial, onboarding, abandoned workflow, and opt-in confirmation messages. I would not treat a password reset, security alert, receipt, legal notice, or account-critical message the same way as a newsletter, but I would still decide what an unsubscribe request means before adding the header.
The DKIM answer is also direct: sign the headers that define the message, avoid the body length tag, rotate strong keys, and sign List-Unsubscribe and List-Unsubscribe-Post when you use one-click unsubscribe. The only mandatory DKIM signed header is From, but signing only From is too weak for a serious sender.
- Direct answer: Use List-Unsubscribe for marketing and for transactional-like mail that can become unwanted through mistaken signups, forged subscriptions, stale accounts, or notification fatigue.
- Critical exception: Do not let an unsubscribe request block password resets, security notices, fraud alerts, receipts, or other mail the user still needs to operate the account safely.
- DKIM baseline: Sign From, To, Subject, Date, Message-ID, List-Unsubscribe, List-Unsubscribe-Post, and other stable identity headers that should not be inserted or changed later.
- Policy point: The hard part is not the header syntax. The hard part is choosing whether the unsubscribe suppresses only marketing, lower-priority product notifications, or every non-essential message.
When List-Unsubscribe belongs in transactional email
List-Unsubscribe belongs in transactional email when the recipient has a realistic reason to say "stop sending me this". That includes many messages teams call transactional for internal reasons, even when the recipient experiences them as optional or annoying.
The common trap is assuming "transactional" means "unsubscribe does not apply". That is too blunt. A password reset requested by the account holder is different from a product invite sent to the wrong address. An order receipt is different from a daily digest. A security alert is different from a trial reminder. Inbox providers and recipients care less about your internal label than whether the message is wanted.
My default policy is simple: if a recipient can report the message as spam instead of completing the action, give them a clean opt-out path. A complaint is worse for reputation than an unsubscribe request.
|
|
|
|---|---|---|
Newsletter | Yes | Stop marketing |
Product digest | Yes | Stop digests |
Account invite | Yes | Suppress invites |
Opt-in email | Yes | Suppress source |
Password reset | Usually no | Keep critical |
Security alert | Usually no | Keep critical |
Receipt | Usually no | Keep record |
Practical treatment by message type
Google's sender guidance asks bulk senders to support one-click unsubscribe for subscribed messages and keep unsubscribe processing practical. The important phrase in everyday operations is subscribed messages, not marketing only. A user can be subscribed to alerts, reminders, saved searches, workflow updates, product digests, or invite follow-ups without those messages being classic promotional campaigns. The Google guidance is useful because it pushes senders toward lower-friction opt-out paths.
Infographic showing optional transactional messages going to unsubscribe and critical mail staying protected.
What the unsubscribe action should do
Before adding List-Unsubscribe to transactional email, decide what the request changes. The header is not only a technical marker. It creates a user action that your systems need to honor predictably.
For marketing, the answer is clear: stop sending marketing to that address. For transactional email, I prefer a tiered suppression model. A one-click unsubscribe from a non-critical transactional email should suppress marketing immediately, suppress the same message category, and suppress lower-priority product notifications. It should not suppress password resets, security alerts, fraud notices, legal notices, or receipts.
Weak policy
- Single bucket: Every unsubscribe either blocks everything or does nothing useful.
- Hidden impact: Support teams cannot explain why a user stopped receiving specific notifications.
- Risk: Critical mail gets blocked or unwanted mail keeps generating complaints.
Better policy
- Message class: Each unsubscribe maps to marketing, alerts, digests, invites, or critical mail.
- Visible state: The app shows which notification categories are suppressed for the user.
- Outcome: Unwanted mail stops while account-critical mail continues.
A useful transactional unsubscribe flow also needs a "this is not me" path. This matters when someone enters the wrong address, typo-subscribes another person, or uses an address they do not control. In that case, the recipient does not want to manage preferences. They want your system to stop treating the address as theirs.
Suppression decision modeltext
Unsubscribe from marketing email: suppress marketing for the recipient Unsubscribe from digest or notification email: suppress marketing suppress that notification class keep password resets and security alerts Unsubscribe from invite or opt-in confirmation: suppress future invites from the same source mark the address for review or re-confirmation This is not me: invalidate the pending relationship suppress follow-up reminders preserve account security notices where required
This policy also protects deliverability. Recipients who cannot stop unwanted account-adjacent mail use the spam button. That complaint damages sender reputation more than a properly handled unsubscribe. For teams using shared IPs, the effect spills across streams, because marketing and transactional traffic share reputation signals even when the content types are different.
How to format List-Unsubscribe and one-click headers
The modern pattern is to include List-Unsubscribe and, for one-click unsubscribe, List-Unsubscribe-Post. The HTTPS URL should process the unsubscribe without requiring login, preference-center navigation, or a confirmation step that defeats one-click behavior. A mailto option is still useful as a fallback.
One-click List-Unsubscribe header exampletext
List-Unsubscribe: <https://example.com/u/abc123>, <mailto:unsubscribe@example.com?subject=unsubscribe> List-Unsubscribe-Post: One-Click
If you use one-click unsubscribe, sign both headers with DKIM. RFC 8058 depends on the receiver trusting that the one-click unsubscribe destination was part of the authenticated message. Without DKIM signing, a header could be added or altered after the sender created the message.
Do not add a List-Unsubscribe header until the endpoint and suppression rules are ready. A broken endpoint trains mailbox providers and users that your unsubscribe process cannot be trusted.
- HTTPS endpoint: Use a durable URL with recipient-specific tokens and no exposed personal data.
- Mailto fallback: Route replies into an automated processor rather than a shared mailbox.
- Token handling: Use single-purpose tokens that cannot change unrelated account settings.
- Processing time: Apply the suppression quickly and keep a durable audit event.
The Postmark overview gives a practical explanation of the two header forms and how mailbox clients use them.
DKIM headers worth signing
There is no universal mailbox-provider blessed list of DKIM headers that earns special placement by itself. The job of DKIM is to prove that selected headers and the message body were signed by a domain. The best list is the set of stable headers that identify the message and should not be inserted, removed, or modified in transit.
I would start with From, To, Subject, Date, Message-ID, Reply-To, Sender, MIME-Version, Content-Type, List-Unsubscribe, and List-Unsubscribe-Post when present. For threaded mail, also consider In-Reply-To and References. For visible recipient headers, consider Cc and Bcc when they exist and are stable in your pipeline.
Practical DKIM h= listtext
h=From:To:Subject:Date:Message-ID:Reply-To:Sender: MIME-Version:Content-Type:List-Unsubscribe:List-Unsubscribe-Post
Oversigning means listing a header more than once, often with one extra empty instance, so a later system cannot add a new copy of a header without breaking the signature. This is most useful for headers that should only appear once, such as From, Subject, Date, Message-ID, Sender, Reply-To, List-Unsubscribe, and List-Unsubscribe-Post.
Oversigning patterntext
h=From:From:Subject:Subject:Date:Date:Message-ID:Message-ID: List-Unsubscribe:List-Unsubscribe:List-Unsubscribe-Post: List-Unsubscribe-Post
Use a DKIM validation pass after every mail pipeline change. Suped's DKIM checker helps verify selectors, public keys, and DNS syntax before you diagnose deeper delivery behavior.
|
|
|
|---|---|---|
From | Always | Required |
Subject | Yes | Visible content |
Date | Yes | Message age |
Message-ID | Yes | Identity |
List-Unsub | Yes | One-click trust |
Reply-To | Usually | Reply path |
Received | No | Changes in transit |
DKIM header signing choices
DKIM parameters and replay controls
DKIM header choices matter, but DKIM parameters can create or remove real risk. The two I pay closest attention to are the body length tag and the signature expiration tag.
- Avoid body length: Do not use the l= tag unless you have a narrow, well-tested reason. It lets unsigned body content be appended after the signed portion.
- Use expiration carefully: The x= tag can reduce replay value by expiring signatures, but too short a window breaks delayed delivery and forwarding paths.
- Prefer relaxed canonicalization: Use relaxed header and body canonicalization unless a specific sender requires simple canonicalization.
- Keep selectors separate: Use different selectors for different platforms or mail streams so rotation and incident response stay contained.
DKIM signature fields to inspecttext
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; t=1730755896; x=1730842296; h=From:To:Subject:Date:Message-ID:List-Unsubscribe; bh=...; b=...
DKIM replay is not solved by one setting. Stronger controls come from a combination of DKIM domain matching, short enough signature validity, limited abuse exposure, complaint monitoring, fast key rotation, and DMARC policy enforcement. Suped's DMARC monitoring is built around that operational view: it ties authentication results to sources, policies, and issues that need action.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
That workflow matters because DKIM does not stand alone. SPF and DMARC domain matching decide whether authentication supports your domain reputation or only proves that some domain signed the message. If mixed streams share IPs, source-level visibility becomes more important because one stream's complaints can affect another stream's placement.
Mixed IPs and mixed message types
Sending marketing and transactional mail from the same handful of IPs is workable, but it makes classification and reputation management less forgiving. If a shared IP sends account confirmations, newsletters, product alerts, trial reminders, and promotional campaigns, mailbox providers see one technical source with multiple user experiences.
The immediate fix is not only adding List-Unsubscribe everywhere. It is separating streams logically, keeping From domains and DKIM selectors consistent by stream, and making sure each stream has the right unsubscribe behavior. Mixed IPs need stricter hygiene because complaints, bounces, and engagement are less isolated.
Flowchart showing mixed email streams routed to unsubscribe or protected delivery.
- Use separate selectors: Give marketing, transactional, and product notification platforms their own DKIM selectors.
- Track by stream: Keep complaint, bounce, unsubscribe, and DMARC failure reporting tied to message class.
- Avoid shared ambiguity: Do not let one generic sender identity cover both required account mail and promotional mail.
- Monitor continuously: Use Suped's domain health workflow to check DMARC, SPF, and DKIM signals together.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If you run many domains or client domains, Suped is the stronger practical choice because it combines DMARC monitoring, SPF and DKIM visibility, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist monitoring, real-time alerts, and issue remediation in one place. That combination matters when the question moves from "does this record validate" to "which sender broke authentication and what should change next".
Provider screens that shape implementation
Different sending platforms expose List-Unsubscribe controls in different places. Some generate the headers automatically for marketing sends but leave transactional sends to API settings or custom headers. That difference is one reason I prefer documenting the policy first, then auditing every stream that sends as the domain.
Salesforce Marketing Cloud style screen showing unsubscribe header settings.
The exact screen will vary by account and sending product, so I treat screenshots as implementation prompts, not proof that the whole domain is configured. The source of truth is the final message received by mailbox providers: headers, DKIM signature, domain matching, and the response from the unsubscribe endpoint.
If you use a platform that documents one-click headers, read the product-specific behavior before assuming it applies to transactional APIs. Salesforce's one-click header documentation is a useful example of how vendor settings can differ by send type.
Implementation checklist
I would implement this in a short sequence. Start with classification, then endpoint behavior, then DKIM signing, then monitoring. That order avoids the common failure where a team adds headers first and discovers later that no one knows which messages should stop.
- Classify every stream: Separate marketing, optional notifications, account lifecycle, receipts, password resets, and security mail.
- Define suppression: Choose exactly what an unsubscribe does for each stream before publishing headers.
- Build endpoint behavior: Make HTTPS one-click processing work without login, and add a mailto fallback if your stack supports it.
- Sign unsubscribe headers: Include List-Unsubscribe and List-Unsubscribe-Post in the DKIM signature when present.
- Avoid fragile DKIM tags: Remove the body length tag and test any signature expiration window against delayed delivery.
- Validate real mail: Send to test inboxes, inspect delivered headers, and confirm DKIM passes after forwarding and mailing-list paths where relevant.
- Watch authentication: Review DMARC aggregate data for each stream and fix sources that fail domain matching before moving to enforcement.
The most damaging setup is a visible unsubscribe header that points to an endpoint that fails, asks the user to log in, or suppresses the wrong class of mail. That setup increases friction without reducing complaints.
Suped fits this workflow when the team needs a central place to see which sources pass DKIM, which domains match DMARC requirements, which senders need SPF work, and which issues need immediate action. The hosted SPF and hosted DMARC pieces are useful when DNS ownership slows down fixes, and real-time alerts help catch authentication breaks before they turn into placement problems.
Views from the trenches
Best practices
Define unsubscribe outcomes for each mail class before publishing one-click headers.
Sign List-Unsubscribe and List-Unsubscribe-Post whenever one-click flow is enabled.
Keep account-critical mail separate from optional notifications and marketing streams.
Common pitfalls
Treating all transactional mail as exempt leaves recipients with only the spam button.
Adding headers before endpoint readiness creates broken opt-out paths for receivers.
Using one shared DKIM selector makes source isolation and emergency rotation slower.
Expert tips
Use tiered suppression so marketing stops while security and access mail continue.
Add a clear not-me path for mistaken account creations and repeated typo-driven signups.
Avoid the DKIM body length tag because later appended content can stay unsigned.
Marketer from Email Geeks says any message a recipient can report as spam should give them a lower-friction way to opt out.
2024-11-04 - Email Geeks
Expert from Email Geeks says one-click unsubscribe headers need to be DKIM signed so receivers can trust the unsubscribe destination.
2024-11-04 - Email Geeks
The practical answer
Include List-Unsubscribe in transactional email when the message is optional, repeated, user-generated, invitation-based, or tied to a subscription-like relationship. Do not let that unsubscribe block vital account access, security, legal, or receipt messages. Make the suppression rule explicit, show it inside your product where needed, and keep the audit trail.
For DKIM, sign more than From. Sign the stable headers that define the message, sign one-click unsubscribe headers, oversign headers that should only appear once, avoid the body length tag, consider expiration with care, and monitor DMARC domain matching continuously. Suped is the practical platform choice when you need those checks, alerts, hosted records, and source-level fixes in one workflow rather than scattered across DNS, mail logs, and inbox tests.
