server-dmarc-hint: the server's own name gets a DMARC record

Owner, 2026-10-18: "Оба предложения делаем"; the mockup is 8b2dc8f. The
security audit's S3 left a product side: the panel showed the DKIM and SPF
records of the server's own name, not a DMARC one, and without it a
receiver does not refuse mail forged in that name - a false password-reset
message among it.

dnscheck.ServerMail checks a third record (Mail.DMARC, checkServerDMARC):
the sending-domain DMARC check held to more - missing is an error, as a
missing DKIM or SPF record of this name is (the page draws it as a
warning: notifications still go), p=none a warning ("weak": it refuses
nothing), quarantine or reject ok - and Overall includes it. The record to
publish is ServerMailDMARC, v=DMARC1; p=reject: only the panel sends as
the name, signed with its key, from the address its SPF names, so reject
costs nothing. Settings › Notification mail draws it after SPF
(view.ServerMailDMARC, folded when published), Health's card has the row,
Re-check DNS re-reads it with the others.

Tests: TestServerMailDMARC (missing, p=none, quarantine, reject); the
Settings and Health tests publish and expect three records. Help word for
word with the mockup; guide § Notifications; roadmap; CHANGELOG.

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

docs/guide.md

@@ -679,18 +679,24 @@ the Outbound log and count against no rate limit. They name the page of the
 panel to open and carry no link: the panel does not know the address its
 reverse proxy serves it under.
 
-**Two DNS records make them arrive.** The server's own name is not one of your
+**Three DNS records make them arrive.** The server's own name is not one of your
 sending domains, so it needs records of its own, shown with the values to
 publish under **Server › Settings › Notification mail**:
 
 - a **DKIM** key for the hostname, which the panel generates and signs
   notifications with (`<selector>._domainkey.<hostname>`, TXT);
-- an **SPF** record for the hostname: `v=spf1 a -all` (TXT).
+- an **SPF** record for the hostname: `v=spf1 a -all` (TXT);
+- a **DMARC** record for the hostname: `v=DMARC1; p=reject` at
+  `_dmarc.<hostname>` (TXT). It has receivers refuse mail forged in the
+  server's name - a false "reset your password" message among it. Only the
+  panel sends as this name, signed with its key, from the address its SPF
+  names, so reject costs nothing; `p=quarantine` is accepted too, `p=none`
+  is shown as weak, since it refuses nothing.
 
 **Server › Health** shows whether each is in place in the *Notification mail*
 card. Without them notifications are still sent, and a receiver may file them
 as spam or, if the parent domain publishes a strict DMARC policy, refuse them.
-Mail of your sending domains depends on neither. If the hostname is itself one
+Mail of your sending domains depends on none of them. If the hostname is itself one
 of your sending domains, the DKIM record is that domain's and is already
 published - and whoever administers that domain can then send mail that
 looks like the panel's; a hostname that is nobody's sending domain is the