Your question
Stalwart Version: 0.16.13 on Linux Debian 13
If i send a mail to mecsa.dcslab.eu I get a bogus DNSSEC error. I use 1.1.1.1 tcp only as DNS Server. dnsviz shows no errors.
Is this a bug in stalwart or not?
queueId = 319481655683188736, queueName = “remote”, from = “[email protected]”, to = [“[email protected]”], size = 2597, total = 1, domain = “mecsa.dcslab.eu”, hostname = “mecsa.dcslab.eu”, details = “MX”, strict = false, elapsed = 0ms
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.
on
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.
Relevant docs on how the resolver and DANE/DNSSEC events work: DNS Resolver | Stalwart and Events | Stalwart (see dane.bogus-dnssec-record).
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
I have found another domain where the same issues occurs: mailbox.org
They both use DNSSEC algorithm 7 (RSASHA1NSEC3SHA1), I guess stalwart does not support it and that causes the issue?
You have to enable TCP in your resolver or disable DANE.
I have already configured my resolver to use only tcp with the cloudflare DNS 1.1.1.1
I also rebooted the entire server after I saved the settings. The error still appears.
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 now updated to 0.16.14, the issue still exists I have disabled DANE completely now, is it possible to just do it for a specific domain?
If stalwart can’t do anything about it, can you bring the issue to attention at Hickory?
Idea: allow also UDP to Cloudflare DNS
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
Cloudflare DNS or Google DNS from the drop-down in the DNS settings should be a supported resolver right? The problem occurs with both of them.
Cloudflare:
Google DNS:
Or is there another known good DNS that should work?
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).
After I dug a bit deeper, this indeed was a hickory bug: fix(proto): verify RSASHA1-NSEC3-SHA1 (alg 7) with the same crypto as RSASHA1 - Pull Request #3691 - hickory-dns/hickory-dns - GitHub - turns out they just claimed all alg 7 sigs were bogus. It is already fixed in the repo, but no release with the fix is available yet. Slightly annoying.
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…
@skyschub Thanks for investigating, I have asked the Hickory maintainers to release v0.26.2 including that PR.
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.
This issue seems to mention the problem Recursor and forwarder drop NSEC/NSEC3 records from responses with wildcard expansion · Issue #3034 · hickory-dns/hickory-dns It’s from June 2025 without any solution.
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.
In my case with 0.16.17 the DNSSEC validation still fails. All tools I tried validate the records as:
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:39.000
(+0 ms)
Span ID
i3g2z0xqanaa
Queue ID
i3g2j7qianaa
Queue name
remote
From address
[email protected]
To address
tlsrpt@s984csebdzsuqs2807doh5gwvyenxt.uniq.measurement.email-security-scans.org
Size
3’296
Total
1
New delivery attempt for domain
An outbound delivery attempt is starting for a specific recipient domain; MX lookup and connection will follow.
21:48:39.000
(+0 ms)
Span ID
i3g2z0xqanaa
Domain
s984csebdzsuqs2807doh5gwvyenxt.uniq.measurement.email-security-scans.org
Error fetching MTA-STS policy
The MTA-STS policy could not be retrieved from the domain’s HTTPS endpoint; TLS enforcement may fall back to best-effort.
21:48:40.000
(+1.0 s)
Span ID
i3g2z0xqanaa
Domain
s984csebdzsuqs2807doh5gwvyenxt.uniq.measurement.email-security-scans.org
Reason
error sending request for url (https://mta-sts.s984csebdzsuqs2807doh5gwvyenxt.uniq.measurement.email-security-scans.org/.well-known/mta-sts.txt)
Strict mode
false
Elapsed time
168 ms
MX record lookup
Performing a DNS MX record lookup to determine which mail servers accept mail for the recipient domain.
21:48:40.000
(+1.0 s)
Span ID
i3g2z0xqanaa
Domain
s984csebdzsuqs2807doh5gwvyenxt.uniq.measurement.email-security-scans.org
Details
s984csebdzsuqs2807doh5gwvyenxt.uniq.measurement.email-security-scans.org
Elapsed time
37 ms
IP address lookup
Resolving the IP address of an MX host before attempting a connection.
21:48:40.000
(+1.0 s)
Span ID
i3g2z0xqanaa
Domain
s984csebdzsuqs2807doh5gwvyenxt.uniq.measurement.email-security-scans.org
Hostname
s984csebdzsuqs2807doh5gwvyenxt.uniq.measurement.email-security-scans.org
Details
2a0d:8d04:d000:1:141:39:223:98, 141.39.223.98
Limit
2
Elapsed time
5 ms
Bogus DNSSEC record
The DNSSEC signature for the record is invalid; the record cannot be trusted for DANE verification.
21:48:40.000
(+1.0 s)
Span ID
i3g2z0xqanaa
Domain
s984csebdzsuqs2807doh5gwvyenxt.uniq.measurement.email-security-scans.org
Hostname
s984csebdzsuqs2807doh5gwvyenxt.uniq.measurement.email-security-scans.org
Details
MX
Strict mode
false
Elapsed time
0 ms
Message rescheduled for delivery
A delivery attempt failed with a temporary error; the message has been rescheduled for a later retry.
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
I have tested the new update. DANE validation and everything else works now. There is no bogus DNSSEC anymore.
@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.
