RFC 2919: List-Id: A Structured Field and Namespace for the Identification of Mailing Lists

Defines the List-Id header for uniquely identifying mailing lists, used by email clients to organise list mail.

Alaa Touil
Email infrastructure specialist, 8+ years in SMTP and deliverability
7 min read Updated Nov 2, 2026 112 views
RFC 2919 List-Id: A Structured Field and Namespace for the Identification of Mailing Lists - SMTPedia reference
RFC 2919
List-Id: A Structured Field and Namespace for the Identification of Mailing Lists

Current standard

Domain
Mailing lists
Published
March 2001
Supersedes
First in series
SMTP relevance
Medium

↗ Read on rfc-editor.org

What this RFC defines

RFC 2919 defines the List-Id header, which provides a unique, structured identifier for a mailing list. The identifier takes the form of a domain-like string (list-name.list-host.example.com) that email clients can use to filter, organise, and label mailing list messages consistently across messages and providers.

Where you see it in practice

When your email client automatically applies a label or filter to all messages from a specific mailing list, it is reading the List-Id header defined by RFC 2919. Gmail exposes it directly through the list: search operator. The structured format allows clients to extract both a human-readable name and a unique identifier from a single header.

Need the normative text? The full specification is on rfc-editor.org. This page focuses on what the RFC does not show: real List-Id headers, how to read them in your inbox, and how to filter on them in each mail client.

How to find the List-Id of a message

  • Gmail: open the message, click the three-dot menu, then Show original, and search the headers for List-Id.
  • Outlook (desktop): open the message, then File, Properties, and read the Internet headers box.
  • Thunderbird: open the message and press Ctrl+U (Cmd+U on macOS) to view the source.
  • Apple Mail: View, Message, All Headers.

How to filter by List-Id in each mail client

Filtering on List-Id is more reliable than filtering on the From address, which can be the moderator, the digest system, or the individual poster depending on the message.

  • Gmail: use the list: search operator, for example list:newsletter.example.com, then Create filter from the search options to label, archive, or skip the inbox.
  • Thunderbird: Tools, Message Filters, New; in the condition list choose Customize, add List-Id as a custom header, then set List-Id contains newsletter.example.com.
  • Outlook (classic desktop): create a rule with the condition with specific words in the message header and enter the List-Id value.
  • Server side (Sieve):
require "fileinto";
if header :contains "List-Id" "newsletter.example.com" {
    fileinto "Newsletters";
}

Interaction with DMARC

Mailing list managers often need to rewrite the From header to avoid DMARC failures when the original sender domain publishes a strict DMARC policy. When the From is rewritten (typically to the list address with the original sender in the display name), the List-Id header remains unchanged, providing continuity for client-side filtering. This is one reason List-Id is preferred over From-based filtering in modern setups.

Quick Reference

RFC 2919 (March 2001) defines the List-Id header: a stable identifier for mailing lists that persists across list name changes, host changes, and other operational shifts. Format: descriptive name + <list-name.domain>. Enables mail clients to filter, group, and route list messages reliably. Companion to RFC 2369 which defines the List-* URL headers (List-Unsubscribe, List-Post, List-Archive, etc.). Widely adopted; every reputable mailing list manager emits List-Id.

RFC 2919 at a glance

AspectDetail
PurposeStable identifier for mailing lists across name/host changes
HeaderList-Id
FormatDescriptive Name <list-name.domain>
PlacementAny position in headers (typically after Received)
Companion headerRFC 2369 List-Post, List-Unsubscribe, List-Archive, etc.
PublishedMarch 2001

List-Id format

List-Id header examples
Full form with description:
List-Id: Newsletter subscribers <newsletter.example.com>

Minimal form (identifier only):
List-Id: <marketing-list.example.com>

Format rules:
– Descriptive phrase optional; enclosed in double quotes if it contains special chars
– Identifier in angle brackets, dot-separated components
– Identifier acts as an inverted domain: list-name comes first, then hosting domain
– Case-insensitive comparison (like DNS domain names)
– Should remain stable even if the list’s operational parameters change

Multiple List-Id headers are not permitted; only one per message.

Common patterns:
<mailman-users.python.org>
<lkml.vger.kernel.org> (Linux kernel mailing list)
<newsletter.company-name.com>
<support-announce.customer-domain.com>

Client-side List-Id use cases

Use caseBenefit
Rule-based filteringClient rule “if List-Id contains ‘newsletter.example.com’ move to Newsletters folder”
Server-side sortingSieve script filters by List-Id into subfolders
Grouping messagesMail client threads all messages from the same list together
Unsubscribe automationCombined with List-Unsubscribe, one-click unsubscribe filtered per list
Reputation trackingReputation systems tag mail by List-Id for per-list metrics

Why List-Id is preferred over From-based filtering

From address can change; List-Id should not. A mailing list may use various From addresses over its lifetime (list-owner@, list-admin@, no-reply@, or per-message sender addresses). Filtering by From breaks when any of these change. List-Id is designed to be stable across these operational shifts, providing a reliable target for filter rules.

Common List-Id mistakes

Emitting the wrong List-Id format. The identifier must be in angle brackets with dot-separated components. Common errors: missing brackets (List-Id: newsletter.example.com), wrong separator (List-Id: <newsletter@example.com>). Format matters for parsers; malformed headers may be ignored or misinterpreted.
Changing List-Id when the list is migrated. The point of List-Id is stability. If you migrate a list from one server to another or rename it operationally, keep the List-Id the same. Otherwise all filter rules downstream break. Common workaround for consolidation: retain the historical List-Id even when hosting changes.
Emitting multiple List-Id headers. RFC 2919 permits only one List-Id per message. Multiple headers are ambiguous and may be treated as legacy or ignored. If a message passes through nested lists (a list forwarding to another list), the outer list should update or replace List-Id, not append a second one.
Not emitting List-Id on transactional mail. Some senders emit List-Id only on true mailing lists (unsubscribable, opt-in). Transactional mail (password resets, order confirmations, alerts) should not have List-Id because clients might apply list-filtering rules that hide urgent messages. Reserve List-Id for actual mailing lists.
Emitting List-Id without List-Unsubscribe. Every message carrying List-Id should also carry List-Unsubscribe (RFC 2369). Users seeing a mailing list message need a mechanism to unsubscribe. Emitting one without the other creates confusion and drives spam complaints.
Mailing list header family

  • RFC 2369: List-* URL headers (List-Post, List-Unsubscribe, List-Archive, List-Help, List-Owner, List-Subscribe)
  • RFC 8058: One-Click Unsubscribe (POST-based unsubscribe automation)
  • RFC 5322: Message Format
Authentication relevant to lists

  • RFC 8617: ARC (preserves authentication across list re-injection)
  • RFC 7489: DMARC (interacts with list handling of From)
SMTPedia companion guides

Frequently asked questions

What is the difference between List-Id and List-Post?

List-Id identifies the list; List-Post specifies where to send a message that should go to the list. List-Id is a stable identifier used for filtering; List-Post is an actionable URL used by clients to help users post to the list. Both are complementary; List-Id per RFC 2919 and List-Post per RFC 2369. Well-configured lists emit both.

Should transactional mail have List-Id?

No. List-Id is for actual mailing lists (opt-in, unsubscribable). Transactional mail (password resets, order confirmations, alerts) is expected by the recipient and should not carry List-Id. If a client filter routes “list mail” to a specific folder, transactional messages carrying List-Id will be misfiled and possibly missed. Reserve List-Id for actual list traffic.

Can List-Id contain dashes and dots?

Yes, both. The identifier follows domain-name conventions: alphanumeric, dashes, and dots as separators. Best practice: use meaningful dot-separated components (list-name.owner-domain.com) rather than opaque strings. Case-insensitive comparison per RFC 2919.

What happens if I change List-Id on an existing list?

All downstream filter rules break. Users who filter by List-Id into a “Newsletters” folder will suddenly see the list arrive in Inbox. Server-side Sieve rules similarly. Best practice: keep List-Id stable across operational shifts. If you must change (e.g., domain sale, brand change), announce the change to subscribers so they can update filters.

Do all mailing list managers emit List-Id correctly?

Classic list managers such as Mailman, Sympa, and Google Groups emit List-Id by default. Commercial email platforms vary: some add it automatically, some only on certain plans, and some let you set it yourself. Custom or minimal sending scripts often omit it. The reliable check is to send a test to your own inbox and look for the header with Show original in Gmail.

Did this guide save you time?

SMTPedia is free and independent. A coffee helps keep every guide accurate.

Buy SMTPedia a coffee

See SMTPedia first on Google

Add us as a preferred source in Top Stories.

Add as preferred source

About the Author

Alaa - SMTPedia author

Alaa ยท LinkedIn

Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. Iโ€™ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.


About SMTPedia

SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.

We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.