dnscheck: query recursive resolvers directly, not the system one

The PTR check reported a correctly published record as wrong. The lookups
went through the container's resolver (127.0.0.11) which forwards to the
host's systemd-resolved, and systemd-resolved synthesises the reverse
lookup of the machine's own addresses from the local hostname rather than
asking public DNS. On the production host that meant

    203.0.113.10 -> provider-assigned-hostname (does not match)

while public DNS has had 203.0.113.10 -> selfpost.example.com all along.

These checks exist to report what a receiving mail server sees, so they
now dial recursive resolvers themselves, defaulting to 1.1.1.1, 8.8.8.8
and 9.9.9.9 and overridable with SELFPOST_DNS_RESOLVERS. The e2e stand
sets it to its CoreDNS, which the `dns:` directive alone no longer covers.

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

deploy/.env.example

@@ -22,6 +22,15 @@ SEND_LOG_RETENTION_DAYS=90
 # monitoring screens does not count as activity, only navigation/actions do.
 PANEL_SESSION_IDLE_DAYS=7
 
+# Comma-separated resolvers the panel's deliverability checks (PTR, SPF, DKIM,
+# DMARC) query directly. They deliberately skip this host's own resolver: with
+# systemd-resolved the reverse lookup of the server's IP answers with the local
+# hostname instead of the PTR record published in public DNS, which made the
+# panel report a correct PTR as wrong. Leave unset for the public defaults
+# (1.1.1.1, 8.8.8.8, 9.9.9.9); set it if outbound port 53 is closed or you run
+# your own recursor, e.g. SELFPOST_DNS_RESOLVERS=10.0.0.2:53
+# SELFPOST_DNS_RESOLVERS=
+
 # Comma-separated CIDRs (bare IPs allowed) of reverse proxies allowed to
 # supply X-Forwarded-For for login/setup rate-limiting. Leave unset unless
 # you know the exact address of your reverse proxy — trusting the wrong