Merge pull request 'docs(troubleshooting): suppression and bounces (engagement Phase 9)' (#25) from docs/engagement-deliverability into edge

Reviewed-on: #25

src/content/docs/docs/administration/troubleshooting.mdx

@@ -114,6 +114,38 @@ a Team. See [Teams](/docs/administration/teams/).
 - **A missed announcement does not come back.** Nothing retries; the post itself is still
   on the site.
 
+## One person stopped receiving email
+
+Everyone else is getting mail, so the transport is fine. Check
+**Engagement → Suppressions**, then **Engagement → Send Log**.
+
+- **They are on the suppression list.** The site stops mailing an address once the
+  receiving server says the mailbox does not exist. Addresses are stored one way and
+  shown masked (`d***@example.com`), so search by their domain to find the row. If they
+  have since fixed their mailbox, press **Lift a suppression** and type the full
+  address — the screen genuinely does not have it, which is why you are asked.
+- **Suppression only affects engagement rules.** Password resets, invites and address
+  verification still go out to a suppressed address, because those are things the person
+  asked for themselves. So "they can reset their password but get no notifications" is
+  the expected shape of this problem, not a contradiction.
+- **The Send Log says *Not sent*.** That is a suppression: nothing was sent to the mail
+  server at all. *Bounced* means it was sent and the mailbox does not exist. *Failed*
+  means the relay refused it for some other reason — that one is about your
+  configuration, not about them.
+- **The Send Log has no row for them at all.** They were excluded before anything was
+  queued. Either they have not opted in on **Notifications** for that stream, or
+  *Require a verified email address* is on in **Settings** and they have not confirmed
+  theirs. The rule editor's audience preview shows how many people each of those removes.
+
+## Everyone stopped receiving email at once
+
+Do **not** start clearing the suppression list — it is almost certainly not the cause.
+A whole-deployment stop is a transport problem: an expired password, a relay that has
+started refusing you, or *Enable email sending* switched off. The Send Log will show
+*Failed* rather than *Bounced* or *Not sent*, and **Settings → Email delivery** shows the
+last error. A wrong password never suppresses anybody; only the receiving server saying a
+specific mailbox does not exist does that.
+
 ## Uploads and modules fail with permission errors
 
 Docker created a bind-mount source that the container user cannot write — usually because