Fix DMARC guidance for send-only relays with optional rua= settings.

The panel now suggests policy-only DMARC by default, lets operators configure a default and per-domain report address, and DNS-checks hub _report._dmarc records. Future in-panel report ingestion is tracked as dmarc-reports in the roadmap.

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/guide.md

@@ -148,8 +148,13 @@ Two different scopes — don't confuse them:
   behalf (e.g. `v=spf1 a mx ip4:<server IP> -all`, adjusted to your setup).
 - **DKIM** — a TXT record with the exact value the panel shows on that
   domain's page (`domain page → DKIM TXT record`), one selector per domain.
-- **DMARC** — a `_dmarc` TXT record (even a conservative `p=none` starts
-  building reporting/reputation history).
+- **DMARC** — a `_dmarc` TXT record. The panel suggests `p=none` (monitoring
+  only, safe to publish immediately). On a send-only relay the sending domain
+  often has no inbox, so `rua=` is optional — configure a default report address
+  in *Settings* or per domain when you have a mailbox that receives inbound mail
+  elsewhere. If `rua=` points at another domain, publish `_report._dmarc` on that
+  hub domain too; the panel checks it. Public mail hosts (Gmail, Outlook, …)
+  cannot be used as external report destinations.
 
 Skipping any of the three per-domain records is the single most common reason
 mail lands in spam even though SelfPost delivered it correctly — DKIM passing
@@ -160,7 +165,8 @@ The panel checks both scopes for you and tells you what is actually published:
 the *Status* page verifies the server's hostname and its reverse record
 (forward-confirmed reverse DNS), and each domain's page shows a *DNS status*
 card comparing the published DKIM record against the key this server signs with,
-plus the domain's SPF and DMARC records. Results are cached for a few minutes;
+plus the domain's SPF, DMARC, and (when configured) DMARC report-authorisation
+records. Results are cached for a few minutes;
 use *Re-check* right after publishing a record. The SPF check is deliberately
 shallow — it looks for a mechanism that literally covers this server's address
 and does not follow `include:` or `redirect=`, so a record that authorizes the

docs/plans/dmarc-reports.md

@@ -0,0 +1,49 @@
+# Plan: dmarc-reports
+
+**Status:** candidate
+
+---
+
+## Goal
+
+SelfPost **receives** DMARC aggregate reports on SMTP, parses them inside the
+image, and **shows summaries in the panel** — pass/fail by source, hints when
+`tighten p=` is reasonable. No external DMARC SaaS and no IMAP workflow for the
+operator.
+
+## Scope
+
+**In:**
+- Inbound SMTP for configured report addresses only (not a general backup-MX).
+- gzip + XML aggregate parsing → SQLite summaries per sending domain.
+- Panel page and/or per-domain section: recent reports, third-party senders,
+  delivery health of report ingestion.
+- Reuse `admin.dmarc_report_email` and `domains.dmarc_rua` for DNS templates;
+  when enabled, suggest a SelfPost-hosted report address.
+
+**Out:**
+- Forensic reports (`ruf=`).
+- Full dashboards, APIs, email alerting.
+- Mailboxes for people (IMAP/POP3/webmail).
+
+## Architecture (sketch)
+
+1. Receiving MTAs → SMTP to SelfPost (hub MX).
+2. Postfix virtual alias or dedicated listener → panel ingest worker.
+3. Parse XML → `dmarc_reports` table (domain, reporter, counts, date).
+4. Panel reads SQLite; links from domain DNS card.
+
+May share port-25 plumbing with [inbound-relay.md](inbound-relay.md) but must
+remain a separate, opt-in feature that does not forward mail upstream.
+
+## Done when
+
+- Operator can point `rua=` at an address SelfPost accepts and see parsed
+  summaries in the panel within one reporting cycle.
+- With the feature off, outbound-only behaviour is unchanged.
+- Documented in [guide.md](../guide.md); migrations are backward-compatible.
+
+## Risks
+
+- Attack surface of accepting mail (mitigate: strict recipient allow-list).
+- Report volume and retention (mitigate: caps + pruning).

docs/roadmap.md

@@ -31,6 +31,7 @@ in `git log` and [CHANGELOG.md](../CHANGELOG.md).
 | inbound-relay | Inbound relay (backup-MX / forwarding) | **agreed** | [plans/inbound-relay.md](plans/inbound-relay.md) |
 | contributing | `CONTRIBUTING.md` | candidate | — |
 | visual-style | Обновление визуального стиля | candidate | — |
+| dmarc-reports | DMARC aggregate report ingestion and panel UI | candidate | [plans/dmarc-reports.md](plans/dmarc-reports.md) |
 
 **Recommended order** (not binding): **web-split → domain-admin →
 inbound-relay** — first the package split, then role-wide authorisation, then
@@ -142,3 +143,30 @@ dark schemes remain supported; readability and contrast are preserved.
 regression across pages; low priority relative to functional work — take up
 after explicit agreement, independently of the feature roadmap order.
 **Version:** no bearing on semver.
+
+---
+
+## dmarc-reports
+
+**Goal:** SelfPost receives DMARC aggregate reports (RFC 7489) on SMTP,
+parses the gzip/XML payloads, and shows pass/fail summaries in the panel — so
+the operator does not need an external DMARC service or a separate mailbox
+workflow.
+
+**Boundary:** an extension of v1.0 — not IMAP/webmail and not a general
+inbound relay. A dedicated inbound path for report messages only; forensic
+reports (`ruf=`) out of scope for v1.
+
+**Done when:** see [plans/dmarc-reports.md](plans/dmarc-reports.md).
+
+**Dependencies / risks:** inbound SMTP in the image (may share infrastructure
+with [inbound-relay](plans/inbound-relay.md) but must not require backup-MX);
+storage and retention of parsed summaries; the `admin.dmarc_report_email` and
+`domains.dmarc_rua` settings added in the DMARC template work must stay the
+source of truth for `rua=` in DNS guidance.
+
+**Order:** after the DMARC `rua=` settings ship; may follow or overlap with
+inbound-relay depending on how port 25 acceptance is structured.
+
+**Version:** `1.x` MINOR.
+