All mails going to ProtonMail (protonmail.com, proton.me, …) are never sent due to wrong “Bogus A/AAAA records were found” error messages. The target mailserver and DNS records are fine.
Expected Behavior
Stalwart should send mails to ProtonMail.
Actual Behavior
Stalwart refuses to send mails to ProtonMail.
Stalwart Version
v0.16.x
Installation Method
Docker
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
Internal
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
This happens because Stalwart is performing DANE/DNSSEC validation and getting a “Bogus” (validation-failed) result for the A/AAAA records used to resolve ProtonMail’s MX host, not because the destination itself is unreachable. A “Bogus” DNSSEC status specifically means the resolver’s DNSSEC signature check failed for the address record, which can happen if the configured DNS resolver isn’t validating correctly (e.g. clock skew, EDNS issues, or a resolver that mishandles DNSSEC for that particular zone), even though the records themselves are valid when checked with a proper validating resolver like dig +dnssec.
Two things worth checking:
DNS resolver — Stalwart’s DnsResolver setting controls which resolver and options (like enableEdns, required for DNSSEC) are used for lookups. If you’re using the System resolver and the underlying OS resolver isn’t a proper validating DNSSEC resolver, you can get spurious Bogus results. Switching to Cloudflare or Quad9 (which do full DNSSEC validation) often resolves this.
DANE enforcement — DANE/DNSSEC validation strictness is set per MtaTlsStrategy via the dane field (optional, require, disable). If you don’t need DANE validation for this destination, you can set dane to disable on the relevant TLS strategy, which skips the DNSSEC check that’s producing the “Bogus” verdict and falls back to normal STARTTLS.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
This is an update on the DNSSEC and DANE delivery failures reported across several threads here. They come from bugs in hickory, the DNS library Stalwart uses to validate DNSSEC, and each one now has a fix submitted upstream:
Google Workspace MX hosts (aspmx.l.google.com and the altN hosts) failing with “exceeded max validation depth”: hickory#3974, fixed in #3976 and #4007. Both are merged but not yet in a hickory release.
Domains delegated two or more labels below an NSEC3 opt-out zone, such as port.venice.it and the comune.*.fr.it municipality domains: hickory#3985, fix in #4001.
Unsigned zones without an NS record at their apex, for example akokan.pl: hickory#4027, fix in #4028.
Microsoft 365 hosts (*.mail.protection.outlook.com) failing when the upstream resolver answers SERVFAIL for them, which Google Public DNS and many local resolvers do: hickory#4063, fix in #4064.
Truncated UDP responses never retried over TCP when several name servers are queried at the same time: hickory#3963, fix in #4062.
Valid answers rejected because the response also carries an unrelated NSEC record, plus some correctly signed wildcard answers rejected: hickory#4047, fix in #4055.
Validating queries sent without the CD bit, which makes a validating upstream resolver answer SERVFAIL: hickory#3966, fix in #4014 and #4036.
DANE delivery has been broken for some of you for weeks now, and the hickory maintainers seem to be busy at the moment, so most of these PRs are still waiting for review. We have forked hickory at stalwartlabs/hickory-dns with all of the fixes above applied, and Stalwart will build against that fork until hickory publishes a release that contains all of them. We ran the patched resolver against every domain reported in these threads, with Cloudflare, Google and Quad9 as upstream resolvers, and they all validate correctly now.
v0.16.26 ships with the patched resolver and will be out today or tomorrow. After upgrading you can remove any TLS strategy you added to turn DANE off for specific domains. If a domain still fails after the upgrade, post it in this thread together with the DNS resolver you use and we’ll look into it.