Should I include List-Unsubscribe headers in transactional emails and what are the DKIM best practices?
Updated on 5 Jul 2026: We tightened the guide around one-click syntax, transactional exceptions, DKIM coverage, and compliance boundaries.
Include List-Unsubscribe headers in marketing and subscribed messages, and in transactional-adjacent email that a recipient can reasonably treat as unwanted. That includes account creation, invites, notifications, trial reminders, onboarding, abandoned workflow mail, opt-in confirmations, optional alerts, and recurring product digests. Do not treat password resets, security alerts, receipts, legal notices, or account-critical messages like newsletters.
For DKIM, sign the headers that define the message, avoid the body length tag, use strong keys, rotate selectors by platform or stream, and sign List-Unsubscribe and List-Unsubscribe-Post when one-click unsubscribe is enabled. The only mandatory DKIM signed header is From, but signing only From leaves too much important message context unsigned.
- Use List-Unsubscribe on marketing, product digests, account invites, opt-in confirmations, optional alerts, and other messages a recipient can reasonably stop.
- Keep password resets, security notices, fraud alerts, receipts, and required account mail outside normal unsubscribe suppression.
- For one-click unsubscribe, publish both List-Unsubscribe and List-Unsubscribe-Post, then cover both headers with DKIM.
- Use 2048-bit DKIM keys where supported, keep selectors separate by stream, and avoid the DKIM body length tag.
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". Many messages teams call transactional are better handled as subscribed or preference-based streams because the recipient experiences them as optional, repeated, or unexpected.
The common trap is assuming "transactional" means "unsubscribe does not apply". 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 the internal label than whether the message is wanted.
The 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 |
Trial reminder | Yes | Stop reminders |
Terms update | Usually yes | Manage notices |
Password reset | Usually no | Keep critical |
Security alert | Usually no | Keep critical |
Receipt | Usually no | Keep record |
Practical treatment by message type
Google and Yahoo require easy unsubscribe for bulk marketing and subscribed messages. The important phrase in day-to-day 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.
List-Unsubscribe decision infographic for optional alerts, invites, digests, and critical mail.
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, use 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
- Every unsubscribe either blocks everything or does nothing useful.
- Support teams cannot explain why a user stopped receiving specific notifications.
- Critical mail gets blocked or unwanted mail keeps generating complaints.
Better policy
- Each unsubscribe maps to marketing, alerts, digests, invites, or other non-critical mail.
- The app shows which notification categories are suppressed for the user.
- 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 can spill 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, cookies, redirects, 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: List-Unsubscribe=One-Click
Expected one-click POST bodytext
POST /u/abc123 HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded List-Unsubscribe=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 coverage, a header can 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.
- Use a durable HTTPS URL with recipient-specific tokens and no exposed personal data.
- Route mailto fallback requests into an automated processor instead of a shared mailbox.
- Use single-purpose tokens that cannot change unrelated account settings.
- Apply suppression within two days or faster, and keep a durable audit event.
DKIM headers worth signing
There is no universal mailbox-provider list of DKIM headers that earns special placement by itself. DKIM proves 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.
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, sign Cc when it exists and is stable. Do not depend on Bcc in delivered mail because Bcc should normally be removed before delivery.
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 by DKIM |
Subject | Yes | Visible content |
Date | Yes | Message age |
Message-ID | Yes | Message identity |
List-Unsubscribe | 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. Pay close attention to the body length tag, signature expiration, key length, canonicalization, and selector design.
- Avoid the l= tag unless you have a narrow, well-tested reason. It lets unsigned body content be appended after the signed portion.
- Use the x= tag carefully. A sensible expiration window can reduce replay value, but a window that is too short breaks delayed delivery and forwarding paths.
- Prefer relaxed header and body canonicalization unless a specific sender requires simple canonicalization.
- Use 2048-bit keys where supported. Gmail and Yahoo require at least 1024-bit DKIM keys, but 2048-bit is the stronger operating baseline.
- 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 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 visible From 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 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.
Email stream routing flowchart for marketing, optional alerts, and critical transactional mail.
- Give marketing, transactional, and product notification platforms their own DKIM selectors.
- Keep complaint, bounce, unsubscribe, and DMARC failure reporting tied to message class.
- Do not let one generic sender identity cover both required account mail and promotional mail.
- 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.
For teams running many domains or client domains, Suped's product brings DMARC monitoring, SPF and DKIM visibility, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist monitoring (blacklist monitoring), real-time alerts, and issue remediation into one workflow. That 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. Document the policy first, then audit every stream that sends as the domain.
Email platform settings screen showing List-Unsubscribe and one-click unsubscribe header controls.
The exact screen will vary by account and sending product, so 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.
Audit the delivered message after every setting change. Check the final List-Unsubscribe value, the List-Unsubscribe-Post value, the DKIM h= list, the signing domain, and the endpoint response before assuming one-click unsubscribe is ready.
Legal and compliance caveats
Treat this as deliverability guidance, not legal advice. The technical recommendation and the legal requirement are related, but they are not the same thing. The right policy depends on where recipients live, what the message says, why it was sent, and whether the email includes commercial content.
- In the United States, CAN-SPAM uses primary purpose. A receipt or security notice does not become marketing because it contains a preference link.
- In Canada, review commercial electronic messages more strictly and keep required account mail separate from optional mail.
- In Europe and the UK, consent, legitimate interest, contract necessity, and local marketing rules need counsel review.
- For global systems, build preference categories flexible enough for regional rules and product-level controls.
Do not let an unsubscribe action stop password resets, one-time codes, security alerts, required legal notices, receipts, or invoices. If the message contains promotional content, either remove that content or handle the message as subscribed mail.
Implementation checklist
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, redirects, or cookies, and add a mailto fallback if your stack supports it.
- Confirm one-click syntax: use List-Unsubscribe=One-Click in List-Unsubscribe-Post.
- 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 pass DMARC requirements, which senders need SPF work, and which issues need immediate action. Hosted SPF and hosted DMARC help 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
Practical recommendation
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, use strong keys, keep selectors separate by stream, and monitor DMARC domain matching continuously.
Suped's product is useful when those checks need to sit in one workflow: authentication results, alerts, hosted DNS records, source-level diagnostics, and practical remediation steps.
