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

    81.30.105.2 -> magenta-pink-heliotrope16786 (does not match)

while public DNS has had 81.30.105.2 -> selfpost.mixfed.ru 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>

CHANGELOG.md

@@ -5,6 +5,19 @@ Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); version
 
 ## [Unreleased]
 
+### Fixed
+
+- panel: the PTR (reverse DNS) check no longer reports a correctly published
+  record as wrong. The checks went through the container's own resolver, which
+  forwards to the host's systemd-resolved — and systemd-resolved answers the
+  reverse lookup of the machine's own IP from the local hostname instead of
+  asking public DNS. A server with `81.30.105.2 → selfpost.example.com` in DNS
+  was told its PTR pointed at the provider-assigned hostname. All four
+  deliverability checks (PTR, SPF, DKIM, DMARC) now query recursive resolvers
+  directly, so the panel reports what a receiving mail server actually sees.
+  Set `SELFPOST_DNS_RESOLVERS` if outbound port 53 is closed or you run your
+  own recursor; it defaults to 1.1.1.1, 8.8.8.8 and 9.9.9.9.
+
 ### Changed
 
 - panel: the three monitoring pages now live at URLs that match their nav