Transmission problem to outlook.com

Questions
1

Your question

Hello, after setting up things for gmail, this works now.
but outlook still gives an error:

lookup error: DNS resolution error: DNS error: DNSSEC validation failed

what should I do to solve this?

2

Let me look at the resolver page fully to see variants (system, cloudflare, custom, etc.) and DNSSEC-related notes.

A “DNSSEC validation failed” lookup error usually surfaces from the DANE/TLSA lookup step, and it means the resolver Stalwart is using got a cryptographically invalid (bogus) DNSSEC response, most often for the recipient’s TLSA or MX records. Stalwart deliberately treats a bogus DNSSEC answer as a failure rather than silently ignoring it, to prevent downgrade attacks, so mail to that domain will be deferred rather than delivered insecurely.

To resolve it:

  1. Check which DNS resolver Stalwart is using, this is controlled by the DnsResolver singleton (Settings â€ș Network â€ș DNS â€ș DNS Resolver in the WebUI). If you’re on System, verify the OS resolver is DNSSEC-validating and reachable; if it isn’t reliable, switching to a validating public resolver such as Cloudflare or Quad9 often clears up spurious bogus results.
  2. Confirm your server’s clock is accurate. Expired or not-yet-valid DNSSEC signatures are reported as bogus and are a very common cause of transient validation failures.
  3. Check the MtaTlsStrategy applied to outlook.com’s route: the dane field defaults to optional, which should fall back to normal STARTTLS if TLSA/DNSSEC can’t be validated. If it’s set to require, delivery will hard-fail on DNSSEC problems, consider whether that’s intended for this domain.

Docs: DNS Resolver and DANE

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

This problem could be related to MX lookup fails with "DNSSEC validation failed" for signed zone (mail.de, RSA/SHA-512) on 0.16.21, regardless of DANE setting if you are on version 0.16.21

4

yes, i’m on version 0.16.21 too.

5

Same symptom here on 0.16.21. In my case the resolver choice made no
difference and dane set to disable did not help either, the validation
runs regardless of that setting.

thornbux bisected it in the linked thread: 0.16.20 is fine, 0.16.21 is
not, the change is in hickory-resolver 0.26.1 to 0.26.2.

Rolling back to 0.16.20 is currently the only known workaround.

6

Same problem here, had to go back to 16.20.

7

Happening to me too, since the 16.21 update.

Proton domains are also affected.

8

It’s due to a hickory-resolver bug, rollback to the previous version or wait a few days until 0.16.22.

9

Version 0.16.22 did not fix the issue. I am having the exact same issue with Proton domains at the very least.

10

Also continuing to see this error with 0.16.22; with proton domains and gmail.

11

Further Hickory issue resolved in v0.16.23

12

I confirm the issue seems to be resolved in v0.16.23 :slightly_smiling_face:

13

Strange, it still doesn’t work for me. Is there a reset I need to do somewhere.

Current version:
2026-09-22T03:05:22Z INFO Starting Stalwart Server (server.startup) hostname = “xxxxxxxx”, version = “0.16.23”

Screenshot 2026-09-22 at 1.23.18 PM
Screenshot 2026-09-22 at 1.23.18 PM2326×2266 417 KB

14

What DNS resolver are you using? It may be the source of the issue if it doesn’t return results correctly.

15

I was using System, which defaulted to my network hosts’ DNS. I changed it to Cloudflare, then Google, and got the same errors. Downgrading to v0.16.20 still resolves the issue.

Screenshot 2026-09-22 at 10.47.00 PM
Screenshot 2026-09-22 at 10.47.00 PM2306×1596 298 KB

Screenshot 2026-09-22 at 10.45.41 PM
Screenshot 2026-09-22 at 10.45.41 PM1904×1546 214 KB

16

Seems to be a issue with hickory-dns: DNSSEC "exceeded max validation depth" after upgrading to 0.26.3 · Issue #3974 · hickory-dns/hickory-dns · GitHub

17

That was the original problem that setting the concurrency to 1 in 0.16.23 was supposed to avoid until they fixed it properly. Guess it isn’t a full workaround.

18

I’m on 0.16.24 and I’m also still running in to these ‘DNS resolution error: DNS error: DNSSEC validation failed’ for any domain hosted at MS365 (MX pointing .mail.protection.outlook.com). Already using DNS over TCP.

Delivering through a simple exim4 relay works but requires a custom outbound delivery strategy and a server restart.

Any ideas on improving the workaround or getting to a definitive solution?

19

I can only test with normal @outlook.com addresses ( MX outlook-com.olc.protection.outlook.com ), but it works with 0.16.24. I configured a DNS Resolver in Settings->Network->DNS ( Quad9 with TLS and default settings).

20

This bug report was written from the perspective of Stalwart and not Hickory, and because it cited 0.16.24 with the ‘workaround’ as fixed, it was closed. It didn’t actually address the underlying problem.

Two different DNSSEC bug reports of networking: hickory-proto's broad DNSSEC validation exceeds max depth on mainnet's real SRV response, even with edns0=true (GH-Actions-runner soak, #1611 follow-up) · Issue #1614 · xarmian/algod-rust · GitHub and networking: bound DNSSEC-validating SRV lookup stages with a timeout (addresses #1614) - Pull Request #1615 - xarmian/algod-rust - GitHub were however posted and appear resolved, unknown if those actually resolve the issue in Stalwart or not once the updated crate is included.