diff --git a/cloudron-server-migration.md b/cloudron-server-migration.md
index 7ac0111..51ee6c3 100644
--- a/cloudron-server-migration.md
+++ b/cloudron-server-migration.md
@@ -89,7 +89,14 @@ needed to restore are inside the thing being restored.
       answers, 80/443 are silently dropped — a provider firewall default). Cloudron manages
       the host's own iptables but explicitly does not touch the provider firewall: its docs
       say "ensure the firewall does not block port 80 (HTTP) and 443 (HTTPS)". Ports:
-      **22, 80, 443, 465, 587, 993, and 25 inbound** (mail delivery
+      **22, 80, 443, 25, 465, 587, 993** (plus 995 and 4190 to match the old box; leave
+      8448, 110 and 143 closed). Verified 2026-10-30 against what the old box serves:
+      22/80/443/465/587/993/995/4190 answer; 8448, 110, 143 and 25 are dropped. The 25
+      result is not trustworthy — it came from a server whose network may block outbound
+      25 — and it must be open, because the platform has **inbound mail enabled**:
+      `GET /api/v1/mail` → `{"domain":"inference.coop","inbound":true,
+      "dkimSelector":"cloudron","relay":{"provider":"cloudron-smtp"}}`. The DKIM selector
+      there matches the `cloudron._domainkey` TXT record, which is a useful cross-check. (mail delivery
       — test from outside, e.g. `telnet my.inference.coop 25` once DNS moves; note that
       many networks block *outbound* 25, so a closed result from inside another server is
       not conclusive). **8448 is intentionally closed** — federation is delegated to
@@ -188,6 +195,14 @@ needed to restore are inside the thing being restored.
 
 ## 7. Open unknowns — resolve before cutover
 
+- **Are MAILBOX CONTENTS inside the Cloudron backup?** Mail is ON for
+  `inference.coop` with inbound enabled, and the mail server is part of the
+*platform*, not the Mail app's container (that app listens only on 3000 — it is a
+  UI, not an MTA). Platform config is backed up, so the DKIM key and mail settings
+  survive; whether members' mailboxes do is **unverified** and would be silent,
+  permanent data loss if they do not. Confirm against Cloudron's docs or the
+  dashboard's backup contents before the freeze. This is now the most consequential
+  open question in this runbook.
 - Whether the Vault export (§3 blocker) has actually been done.
 - The Cloudron host's OS version, disk and RAM (not visible over the API).
 - Whether the S3 access key is in the off-box JSON or only inside Cloudron.