Migrating to Mailman 3, step by step

Migrating to Mailman 3 is a five-step process: export your current members and archive, create the new list, import both, switch SPF, DKIM and DMARC to the new sending setup, then announce the new address and redirect the old one. For a list under 10,000 archived messages, the whole sequence typically fits into an afternoon, with the old platform left running until the new one is confirmed to work.

you@lists:~$ cat 00-gather-first.txt

## what to gather before you start

• The full member list, exported as addresses — not just a headcount.
• The archive, in whatever format the old platform exports (mbox is ideal; Takeout output, per-thread exports, or an old Mailman 2 archive directory all work with some cleanup).
• A list of current moderators and owners, and what each one is allowed to do.
• The sending domain the list should use going forward — the same address, or a new one.
• Any existing SPF or DKIM records for that domain, so the new setup does not conflict with them.

you@lists:~$ cat 01-export.txt

## step 1 — export the old list

Google Groups: use Members → Export for the subscriber list. For the archive, Google Takeout or a per-thread manual export is what is available for smaller groups — expect to clean the output up afterward, since it was not built for mailing-list migration.

Mailman 2: the easiest case — bin/list_members writes the subscriber list, and the var/archives mbox files already hold the full archive in the format Mailman 3 wants, with little conversion needed.

Legacy listserv or Yahoo-Groups-era lists: usually a manual pull — export whatever subscriber list the platform still allows, and pull archived messages while access still exists. These older platforms tend to disappear before their users expect it, so this step is worth doing early rather than "eventually."

you@lists:~$ cat 02-create.txt

## step 2 — create the list in Mailman 3

Provision the new list in Postorius, the web admin UI: set its name, address, and type — announce-only or open discussion — along with default moderation rules. None of this needs shell access.

One decision matters here: keep the exact old address, or move to a new one under a domain you control end-to-end. Keeping the address means less relearning for members; moving it usually means a cleaner DMARC story if the old domain's sending reputation was already damaged.

you@lists:~$ cat 03-import.txt

## step 3 — import members and the archive

Member import runs in one pass from the exported address list. Mailman rejects malformed addresses individually rather than failing the whole batch — check the rejected count against your original export so nothing quietly goes missing.

Archive import into HyperKitty reads the mbox file message by message and indexes it. Threading and original dates carry over, so search and browse work on day one, not just for mail sent after the move. Spot-check a handful of old threads before moving on, and confirm the new subscriber count matches the old platform's.

you@lists:~$ cat 04-dmarc-cutover.txt

## step 4 — DMARC, SPF and DKIM cutover

Mailman 3 signs outgoing mail per list and handles the From header so strict recipient domains — Gmail, Yahoo, Microsoft — do not reject list mail sent "as" a subscriber whose own domain enforces a strict p=reject DMARC policy. Getting this order right is what keeps messages out of spam during the switch:

1. Publish an SPF record for the sending domain.
2. Add the DKIM selector and key, and enable per-list signing.
3. Set DMARC to p=quarantine and watch aggregate reports for about a week.
4. Move DMARC to p=reject once those reports come back clean.
5. Enable Reply-To-List munging, so a reply goes to the list instead of just the original sender.

you@lists:~$ cat 05-announce.txt

## step 5 — announce and redirect

Test-fire a message to a small internal group first, not the whole list. Once that confirms delivery is clean, announce the new address to everyone, set the old Google Group or Mailman 2 list to read-only or forwarding, and keep it visible for a transition window so latecomers can still find their way over.

Watch bounce and moderation queues closely for the first week — that is when address typos and stale filters surface, not later once everyone has settled in.

you@lists:~$ cat 06-checklist.txt

## the full migration checklist

you@lists:~$ cat 07-how-long.txt

## how long this actually takes

If you have not yet decided whether Mailman 3 is the right move at all, our Google Groups alternatives comparison lays out the cost and trade-off case first.

you@lists:~$ cat 08-faq.txt

## faq