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.
The “Bogus DNSSEC record” error you’re seeing is not simply Stalwart trusting or distrusting your resolver’s AD bit. Stalwart performs its own DNSSEC chain validation internally (via the hickory-dns proof/validation logic) on the MX lookup, independent of what dnsviz or your resolver reports. When that internal validation returns Bogus for the MX RRset, Stalwart deliberately treats it as a temporary failure (rather than proceeding insecurely) specifically to prevent DNSSEC downgrade attacks - this is intentional defensive behavior, not necessarily proof of a broken zone.
Because your resolver (1.1.1.1) and dnsviz both say the zone validates fine, but Stalwart’s own validator flags it bogus, this looks like a discrepancy between Stalwart’s internal validator and the upstream resolver/dnsviz, which could stem from things like clock skew on your Stalwart host, an algorithm/curve Stalwart’s resolver doesn’t fully support, or a caching/trust-anchor issue on the Stalwart side. This isn’t something I can pin down further from the docs alone, so it’s worth having a human look at your specific zone (mecsa.dcslab.eu) and Stalwart’s DNS resolver logs.
There’s not much we can do here unfortunately, Bogus is the validation result that hickory is reporting. Try using a different resolver such as a self hosted one. Most Bogus errors are due to large DNSSEC responses being truncated, but this should not be the case with TCP.
I have only done that to avoid the problem of UDP truncated responses. I will change it if everything is working like it supposed to. But currently it’s a variable that I want to avoid.
I don’t believe this is a hickory bug, something in your resolver (or how you configured) is breaking DNSSEC validation. What hickory could do better is report when the error is due to truncation or misconfiguration vs an actual bogus record.
edit: I just sent a message to the hickory developers so they make this distinction
So, I just ran into the same issue with a recipient on mailbox.org, too. Upon further inspection, this appears to affect all users of mailbox.org, no matter if it’s their own domain, @mailbox.org, or @temp.mailbox.org. It just complains about bogus dns records - despite them not being bogus (although midly questionable given RSASHA1NSEC3SHA1).
Because I did not want to turn off DANE globally, I created a no-dane strategy in Settings > MTA > Outbound > TLS Strategies where I turned DANE to “disabled”, and then used the Strategy > TLS setting to use that TLS strategy for the two known domains that affect me (ends_with(mx, '.mailbox.org') || ends_with(mx, '.protonmail.ch')):
To me, that’s better than disabling DANE globally, so… yay?
Edit: Ah, protonmail isn’t even affected. The issue with protonmail is truncation, but I was never affected by that since the hickory issue only effects mailbox.org - and the other domain OP mentioned since they also use RSASHA1NSEC3SHA1, funnily enough…
There are more problems with this library it seems. For example 8yyw37pk4mwpdv9ja6kw8zln6v3y2q.uniq.measurement.email-security-scans.org also gives back bogus MX result for DANE, despite dnsviz, DNSSEC Debugger, dig, kdic Technitium DNS, PowerDNS Recursor and Bind9 not having a problem validating the DNSSEC records. Also it’s not the same problem as mentioned before as it uses algorithm 13 and not 7.
It uses the wildcard *.uniq.measurement.email-security-scans.org MX record which resolves to unsigned zones.
Is there another rust library which can correctly validate DNSSEC which you could use? Or could you add an option so we can use a validating resolver instead of validating the results within stalwart with this flawed library?
Please try again with v0.16.17 (yet to be released), it includes a patch to use the hickory commit that includes the fix you need rather than the latest crates.io release.
Proof of non-existence (nsec3) correctly: the TLSA records
As such the mail should be delivered without DANE
Logs:
Delivery attempt started
A new outbound SMTP delivery attempt is beginning; the server will look up MX records and try to connect to the recipient’s mail server.
21:48:40.000
(+1.0 s)
Span ID
i3g2z0xqanaa
Next retry
11 Aug 2026, 21:50:40
Next DSN
12 Aug 2026, 23:17:23
Expiration
14 Aug 2026, 21:44:16
Delivery attempt ended
The outbound delivery attempt has finished, either successfully or with a temporary/permanent failure recorded.
21:48:40.000
(+1.0 s)
Span ID
i3g2z0xqanaa
Elapsed time
210 ms
@ruffy91 the patched hickory fixes only the RSASHA1NSEC3SHA1 bug but not the other issue you reported. I am not aware of other DNS resolver crates we could replace hickory with.
Hit the same problem with mailbox.org its primarily because they are transitioning keys and have a RRset with two RRSIGs. It only marks one as secure and leaves the other one indeterminate which is breaking things. Will try to draft a patch.
