diff --git a/05-troubleshooting/logwatch-wrong-hostname-after-migration.md b/05-troubleshooting/logwatch-wrong-hostname-after-migration.md
index c63fcdc..d84e092 100644
--- a/05-troubleshooting/logwatch-wrong-hostname-after-migration.md
+++ b/05-troubleshooting/logwatch-wrong-hostname-after-migration.md
@@ -2,10 +2,10 @@
 title: "Logwatch Reports the Wrong Hostname (`<host>-hetzner`) After a Migration"
 domain: troubleshooting
 category: monitoring
-tags: [logwatch, hostname, hetzner, migration, monitoring, provisioning]
+tags: [logwatch, hostname, hetzner, migration, monitoring, provisioning, fail2ban]
 status: published
 created: 2026-06-12
-updated: 2026-06-12
+updated: 2026-06-14
 ---
 
 # Logwatch Reports the Wrong Hostname (`<host>-hetzner`) After a Migration
@@ -87,8 +87,47 @@ done
 ```
 
 Any value ending in `-hetzner` (or your provider's build label) needs the fix above.
-In the 2026-06 sweep, `tttpod` and `dcaprod` were still `*-hetzner`;
-`majortoot`, `majormail`, and `majorlinux` were already correct.
+In the 2026-06 sweep, `tttpod` and `dcaprod` were still `*-hetzner` at the OS
+level; `majortoot`, `majormail`, and `majorlinux` had the correct system hostname
+— but see the variant below: `majormail`'s *configs* were still stale even though
+its hostname wasn't.
+
+## Variant: hostname is correct, but a config has the old name baked in
+
+A second, sneakier form of this drift: the **system hostname is already right**, so
+the sweep above passes and the Logwatch report *title* is correct — yet mail still
+arrives **from** `<host>-hetzner` because the old label is hardcoded in a service's
+`From`/`sender` field. These fields are static text, not derived from the live
+hostname, so fixing `hostnamectl` does nothing for them.
+
+Seen on `majormail` (2026-06-14): system hostname was `majormail`, but
+`Logwatch@majormail-hetzner...` was still the sender. Two configs held it:
+
+```bash
+# sweep a box for the old provisioning label in any send-related config
+ssh root@<host> 'grep -rsn "<host>-hetzner" /etc/logwatch/ /etc/fail2ban/ \
+  /etc/postfix/ /etc/aliases /etc/mailname 2>/dev/null'
+# /etc/logwatch/conf/logwatch.conf:MailFrom = Logwatch@<host>-hetzner.majorshouse.com
+# /etc/fail2ban/jail.local:sender         = fail2ban@<host>-hetzner.majorshouse.com
+```
+
+Fix in place (no restart needed for Logwatch; reload fail2ban for its change):
+
+```bash
+ssh root@<host> '
+  sed -i "s/<host>-hetzner/<host>/g" /etc/logwatch/conf/logwatch.conf /etc/fail2ban/jail.local
+  systemctl reload fail2ban
+'
+```
+
+> [!warning] Check the Ansible source, or it comes back
+> A live `sed` is undone by the next playbook run if the repo still carries the old
+> value. Distinguish two cases:
+> - **Templated** (safe): e.g. `logwatch.yml` sets `MailFrom = Logwatch@{{ inventory_hostname }}...`. If the inventory host is named correctly, a run *regenerates* the right value — it even self-heals a stale box.
+> - **Static file** (will regress): e.g. `roles/fail2ban/files/hosts/<host>/jail.local` with the literal `sender = ...@<host>-hetzner...`. Grep the repo (`grep -rn "<host>-hetzner" .`) and fix the file too, or every deploy re-pushes the stale sender.
+
+Inert backups (`jail.local.bak*`, `*~`) may still contain the old string — they
+don't send mail, so leave them.
 
 ## Prevention