Outbound: "DNSSEC validation failed" on MX host lookup when the recipient domain is signed but its MX hosts are in an unsigned zone (Google Workspace). Still present in 0.16.24

Issues
1

Issue Description

Outbound mail to a recipient whose domain is DNSSEC-signed and whose MX hosts are Google Workspace (aspmx.l.google.com, alt1-alt4.aspmx.l.google.com) is never delivered. Every delivery attempt fails the address lookup of each MX host with “DNSSEC validation failed”, the message stays queued, and it bounces at queue expiry (about 5 days).

The same Google MX hosts deliver normally for recipients whose domain is NOT signed. On 0.16.23 we logged 83 successful deliveries to aspmx.l.google.com for unsigned domains during the same days the signed domains failed.

DNS facts, checked from the server itself:

  • The recipient domain has a DS record at its parent and validates as Secure (delv reports “fully validated”; validating resolvers set AD).
  • google.com is unsigned. The .com servers return a correct NSEC3 opt-out proof for DS google.com, so the A/AAAA records of aspmx.l.google.com should validate as Insecure, not Bogus.

Setup: single node, all roles, default System DNS resolver. Outbound TLS / DANE settings are at their defaults as far as we know. Upgraded 0.16.23 → 0.16.24 today; the problem is unchanged.

Expected Behavior

The MX host is in an insecure (unsigned) zone, so DANE does not apply to it (RFC 7672 section 2.2). Stalwart should resolve its address without DNSSEC validation failing, skip DANE for that host, and deliver with ordinary TLS, exactly as it does when the recipient domain is unsigned.

Actual Behavior

The address lookup of the insecure MX host fails with “DNSSEC validation failed” (delivery.ip-lookup-failed) and no SMTP connection is attempted. All MX hosts fail the same way, so the message is retried until it expires and bounces.

This is not GitHub issue 3316 (the hickory truncated-response race fixed in 0.16.23 by querying one nameserver at a time): it persists on 0.16.23 and 0.16.24 and only affects “signed recipient domain + MX host in an unsigned zone”.

The 0.16.24 fix “MX records are resolved through the DNSSEC-validating resolver even when DANE is disabled” did not change it: the failure is on the MX host ADDRESS lookup (delivery.ip-lookup-failed), not on the MX lookup.

Reproduction Steps

  1. Run Stalwart 0.16.24 with the default System DNS resolver and default outbound TLS settings.
  2. Send a message to any address at a DNSSEC-signed domain whose MX records point to aspmx.l.google.com (Google Workspace).
  3. Watch the queue: every attempt logs delivery.ip-lookup-failed with “DNSSEC validation failed” for each Google MX host.
  4. Control: send to an unsigned domain that uses the same Google MX hosts. It delivers normally.

We can share two real recipient domains that reproduce this, privately, with a maintainer.

Relevant Log Output

2026-09-28T15:18:07Z INFO IP address lookup failed (delivery.ip-lookup-failed) queueName = "remote", total = 1, domain = "<recipient domain>", hostname = "aspmx.l.google.com", details = "Temporary Failure for aspmx.l.google.com: Connection failed: lookup error: DNS resolution error: DNS error: DNSSEC validation failed", elapsed = 276ms
2026-09-28T15:18:07Z INFO IP address lookup failed (delivery.ip-lookup-failed) queueName = "remote", total = 1, domain = "<recipient domain>", hostname = "alt2.aspmx.l.google.com", details = "Temporary Failure for alt2.aspmx.l.google.com: Connection failed: lookup error: DNS resolution error: DNS error: DNSSEC validation failed", elapsed = 156ms

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.

on

2

This isn’t covered in the current docs. A community member or staff member will follow up.

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

3

We’re still waiting for hickory to be fixed upstream. A PR has been submitted but not merged yet.

4

Hi,

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.

5

Hello,

I’ve updated Stalwart to 0.16.26 (confirmed with stalwart --version) and I cannot send emails to protonmail.com and mailbox.org. Everything else seem to work (I’ve tried with test accounts on gmail.com and outlook.com: I am able to send messages to these providers).

My stalwart installation is a plain vanilla linux binary.

In both cases (proton and mailbox) I get this error if I try the Delivery Test tool.

“DNS resolution error: DNS error: DNSSEC validation failed”

Thanks!

EDIT: This is solved! I changed the DNS Resolver to Quad9 and everything started working.