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.comis unsigned. The.comservers return a correct NSEC3 opt-out proof for DSgoogle.com, so the A/AAAA records ofaspmx.l.google.comshould 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
- Run Stalwart 0.16.24 with the default System DNS resolver and default outbound TLS settings.
- Send a message to any address at a DNSSEC-signed domain whose MX records point to
aspmx.l.google.com(Google Workspace). - Watch the queue: every attempt logs
delivery.ip-lookup-failedwith “DNSSEC validation failed” for each Google MX host. - 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