design: notifications on Account, Server > Settings and Server > Health

Accepted by the owner on 2026-10-12 from screenshots, after two changes of
his: DKIM for the server's own name as well as SPF ("we need the best
deliverability for these messages"), and the records themselves under
Settings with only their state on Health.

- account: a checkbox "Send me notifications" in the Profile box, under the
  e-mail it writes to. No box of its own, no choice per event.
- settings: box 03 Notifications with the instance switch; box 04
  Notification mail with the two DNS records of the server's own name, DKIM
  and SPF, drawn with the record component of a domain's DNS page. Sending
  rate limits move to the left column as box 02.
- health: card 06 Notification mail - the state of each record and a link to
  Settings - beside Configuration, now 07, each half the width.
- help: a Notifications topic (what is sent, when, to whom, what makes it
  arrive); Settings and Your account each gain a clause.

outlines.json rewritten with check.py --write: the structure of settings and
health changed. build.py: 35 pages; check.py: 32 screens, 52 sp- classes,
0 violations. The plan records both of his changes; step 1 of 10.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/plans/panel-notifications.md

@@ -40,10 +40,23 @@ From `postmaster@<SELFPOST_HOSTNAME>`, submitted locally. Not from one of the
 sending domains (owner): with several domains the choice is arbitrary, and a
 message about the certificate has no business coming from a domain.
 
-The server's name usually has no DKIM key. One DNS record is enough for such
-mail to pass SPF and DMARC on the name itself: `v=spf1 a -all` for the
-hostname. Server › Health gains that check next to reverse DNS, and the guide
-describes it. Without the record notifications are still sent.
+These messages have to arrive (owner: "we need the best deliverability for
+them"), so the server's own name gets what a sending domain has:
+
+- a **DKIM key for the hostname**, generated by the panel, with which
+  notifications are signed - no domain has to be chosen for it. An SPF record
+  alone would pass DMARC, but not after the user's mailbox forwards the
+  message on, and large receivers treat unsigned mail more strictly;
+- an **SPF record** for the hostname, `v=spf1 a -all`.
+
+The records themselves are under **Server › Settings** (owner: "the DNS
+records go to Settings, Health has only the status"), in a box of their own
+drawn with the record component of a domain's DNS page: host, value to
+publish, copy buttons, state. **Server › Health** has a card of its own,
+*Notification mail*, with the state of each record and a link to Settings.
+A DMARC record for the hostname is not asked for: the name inherits its
+parent domain's policy, and with SPF and DKIM aligned it passes any.
+Without the records notifications are still sent, and the card warns.
 
 Notifications are the panel's own mail: they are not rows of the Outbound log
 and count against no level-2 limit.
@@ -94,7 +107,7 @@ to the owner before any code ([panel-redesign.md](panel-redesign.md)
 
 ## Implementation checklist
 
-- [ ] Mockups: Account checkbox, Settings switch, Health SPF check, help topic; accepted by the owner (`design:` commit)
+- [x] Mockups: Account checkbox, Settings switch and records, Health status card, help topic; accepted by the owner 2026-10-12 (`design:` commit)
 - [ ] Migration and store: user flag, instance switch, event state
 - [ ] Sending: local submission from `postmaster@<hostname>`, message text
 - [ ] Background checker: DNS, certificate, queue; the rules of *When a message is sent*