Delivery failure for domains with DNSSEC enabled but no TLSA record

Issues
1

Issue Description

I was trying to send mails to domains protected by MS Exchange. For some, it works, but for others, it does not.

After investigating the issue, I found a potential culprit in the Server behaviour: if the recipient’s mailserver has a valid DNSSEC configuration, Stalwart expects it to have a TLSA record.

Expected Behavior

If no TLSA record is found and the DANE strategy is set to ‘Optional’, the mail should be sent.

Actual Behavior

INFO Error fetching TLSA record (dane.tlsa-record-fetch-error)
        queueName = "remote"
        from = "[email protected]"
        to = ["[email protected]"]
        domain = "targetserver.tld"
        hostname = "targetserver-tld.mail.protection.outlook.com"
        causedBy = DNS error (mail-auth.dns-error)
                details = "DNS error: error response: Server Failure"
        strict = false
        elapsed = 177ms

Reproduction Steps

  1. Use the default TLS strategies on the sender’s mailserver
  2. Configure DNS entries on the recipient’s server so that DNSSEC passes (https://powerdmarc.com/dnssec-checker/), but TLSA does not (https://powerdmarc.com/dane-record-checker/)

Relevant Log Output

When the recipient’s server does not have a valid DNSSEC configuration, everything works:

  INFO New delivery attempt for domain (delivery.domain-delivery-start)
  INFO TLS-RPT record not found (tls-rpt.record-not-found)
  INFO MTA-STS policy not found (mta-sts.policy-not-found)
+ INFO TLSA record not DNSSEC signed (dane.tlsa-record-not-dnssec-signed)
  INFO Connecting to remote server (delivery.connect)
  INFO SMTP STARTTLS command (delivery.start-tls)
  INFO Message delivered (delivery.delivered)
  INFO DSN success notification (delivery.dsn-success)
  INFO Delivery completed (delivery.completed)
  INFO Delivery attempt ended (delivery.attempt-end)

If the server has DNSSEC but not TLSA:

  INFO New delivery attempt for domain (delivery.domain-delivery-start)
  INFO TLS-RPT record not found (tls-rpt.record-not-found)
  INFO MTA-STS policy not found (mta-sts.policy-not-found)
- INFO Error fetching TLSA record (dane.tlsa-record-fetch-error)
  INFO Message rescheduled for delivery (queue.rescheduled)
  INFO Delivery attempt ended (delivery.attempt-end)

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

FoundationDB

Blob Storage

S3-compatible

Search Engine

Elasticsearch

Directory Backend

OIDC

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

Looking at the outbound delivery code, this matches a genuine gap in the current DANE handling. When Stalwart looks up a TLSA record for a DNSSEC-secure MX host, the resolver’s error is inspected:

  • If the DNS error is a plain “record not found” (NXDOMAIN-style), Stalwart correctly treats it as “no TLSA record” and, when the strategy is optional, falls through to regular STARTTLS.
  • If the DNS error is anything else (including a SERVFAIL, which is what several Microsoft 365/Exchange domains apparently return when there’s no TLSA record but the zone is DNSSEC-signed), Stalwart logs dane.tlsa-record-fetch-error and unconditionally aborts the delivery attempt to that host, regardless of whether the DANE strategy is require or optional. Unlike the other TLSA outcome branches, this error path does not check the strict flag at all before failing.

So the “Optional” DANE strategy is only honored for a missing-record (NXDOMAIN) response, not for a SERVFAIL response while resolving _25._tcp.<host> records, which is why delivery to these particular Exchange-protected domains gets rescheduled/fails even though DANE is set to Optional.

Relevant docs on the intended behavior of the optional/require DANE setting: TLS | Stalwart (DANE section) and DANE | Stalwart

This looks like a real inconsistency in how SERVFAIL-type TLSA lookup failures are handled versus NXDOMAIN ones, worth a maintainer’s review; a human will follow up on this thread.

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

3

The trigger is not the absent TLSA record. A real “no such record” answer is handled and delivery goes ahead under optional; what you are hitting is a TLSA lookup that comes back SERVFAIL, which is a different thing. Once the recipient’s MX RRset has validated under DNSSEC, an inconclusive TLSA answer cannot be told apart from a stripped record, so RFC 7672 section 2.2 requires us to defer rather than downgrade. That is why optional does not help: it governs the missing-record case, not the failed-lookup case.

It’s a good idea to establish where the SERVFAIL comes from, because it may well be yours rather than theirs. Try dig +dnssec _25._tcp.<mx-hostname>. TLSA against your configured resolver and against an independent one. We run a validating resolver on top of whatever forwarder you have configured, and forward-mode validation throws SERVFAIL on awkward delegations often enough to be worth ruling out first.

If the destination cannot be fixed, set dane to disable on a TLS strategy scoped to that domain.

4

Using the connectivity test from Microsoft itself, it seems that they standardized this non-compliant behavior:

image
image2099×736 87.1 KB

From what I see, the mail is still being delivered, while a SERVFAIL is returned for TLSA records.

You can also try with their own test domain: contoso.com:

~$ dig contoso.com MX

; <<>> DiG 9.18.49 <<>> contoso.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31188
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;contoso.com.                   IN      MX

;; ANSWER SECTION:
+  contoso.com.            3408    IN      MX      10 contoso-com.mail.protection.outlook.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Aug 24 10:53:31 CEST 2026
;; MSG SIZE  rcvd: 92

~$ dig _25._tcp.contoso-com.mail.protection.outlook.com. TLSA

; <<>> DiG 9.18.49 <<>> _25._tcp.contoso-com.mail.protection.outlook.com. TLSA
;; global options: +cmd
;; Got answer:
-; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55521
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_25._tcp.contoso-com.mail.protection.outlook.com. IN TLSA

;; Query time: 573 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Aug 24 10:53:41 CEST 2026
;; MSG SIZE  rcvd: 77

I have also looked up the Microsoft Learn documentation about DANE, and it seems that this error is returned when the recipient’s server is wrongly configured.

Back to the square one :-/

EDIT: I found that the error is different based on which DNS server I use:

  • With Cloudflare, I have a NXDOMAIN answer (DANE optional passes)
  • With Quad9, I have a SERVFAIL
  • With Google, it’s a better SERVFAIL:
    ;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
; EDE: 23 (Network Error): ([104.47.72.81] rcode=NOTIMP for _25._tcp.contoso-com.mail.protection.outlook.com/tlsa)
; EDE: 23 (Network Error): ([104.47.34.49] rcode=NOTIMP for _25._tcp.contoso-com.mail.protection.outlook.com/tlsa)
; EDE: 22 (No Reachable Authority): (At delegation mail.protection.outlook.com for _25._tcp.contoso-com.mail.protection.outlook.com/tlsa)
;; QUESTION SECTION:
;_25._tcp.contoso-com.mail.protection.outlook.com. IN TLSA
5

Also seeing this with Stalwart 0.16.19 and a local Unbound as DNS Resolver when trying to send to Domains using `*.mail.protection.outlook.com` as MX.

Microsofts authoritative DNS Servers seem to return `NOTIMP` which leads Unbound to return `SERVFAIL`. Quad9/Google DNS behave the same, only Cloudflare DNS seems to have a different handling of this error and returns `NXDOMAIN`.

$> dig @ns1-proddns.glbdns.o365filtering.com _25._tcp.contoso-com.mail.protection.outlook.com TLSA +norecurse +noedns
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 31619
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_25._tcp.contoso-com.mail.protection.outlook.com. IN TLSA

Codex pointed to RFC 7672 §2.2.2 mentioning this behavior and how mailservers should handle it. Quote from the RFC:

Note that DNS queries with type TLSA are mishandled by load-balancing
nameservers that serve the MX hostnames of some large email
providers. The DNS zones served by these nameservers are not signed
and contain no TLSA records. These nameservers SHOULD provide
“insecure” negative replies that indicate the nonexistence of the
TLSA records, but instead they fail by not responding at all or by
responding with a DNS RCODE [RFC1035] other than NXDOMAIN, e.g.,
SERVFAIL or NOTIMP [RFC2136].

To avoid problems delivering mail to domains whose SMTP servers are
served by these problematic nameservers, the SMTP client MUST perform
any A and/or AAAA queries for the destination before attempting to
locate the associated TLSA records. This lookup is needed in any
case to determine (1) whether or not the destination domain is
reachable and (2) the DNSSEC validation status of the chain of CNAME
queries required to reach the ultimate address records.

If no address records are found, the destination is unreachable. If
address records are found but the DNSSEC validation status of the
first query response is “insecure” (see Section 2.1.3), the SMTP
client SHOULD NOT proceed to search for any associated TLSA records.
In the case of these problematic domains, TLSA queries would lead to
DNS lookup errors and would cause messages to be consistently delayed
and ultimately returned to the sender. We don’t expect to find any
“secure” TLSA records associated with a TLSA base domain that lies in
an unsigned DNS zone. Therefore, skipping TLSA lookups in this case
will also reduce latency, with no detrimental impact on security.

@stalwart Is this something Stalwart could implement?

Workaround

For the time being I disabled DANE for this destinations (like also proposed above).

Add a `MtaTlsStrategy`:

{
  "name": "microsoft-365-no-dane",
  "description": "Skip DANE for Microsoft 365 MX hosts with broken TLSA DNS responses",
  "dane": "disable",
  "mtaSts": "optional",
  "startTls": "optional",
  "allowInvalidCerts": false,
  "mtaStsTimeout": 300000,
  "tlsTimeout": 180000
}

Configure `MtaOutboundStrategy` to use the strategy:

"tls": {
  "match": {
    "0": {
      "if": "ends_with(to_lowercase(mx), '.mail.protection.outlook.com')",
      "then": "'microsoft-365-no-dane'"
    },
    "1": {
      "if": "retry_num > 0 && last_error == 'tls'",
      "then": "'invalid-tls'"
    }
  },
  "else": "'default'"
}
6

Fixed in v0.16.20 (yet to be released).