DANE SMPT records are wrong?

Questions
1

Your question

I’m on Stalwart 0.16.12 currently. The domains are DNSSEC-enabled. Stalwart creates TLSA records with usage/selector/matching as 3 1 1 for DANE-EE and 2 1 1 for DANE-TA. However, RFC 7672 recommends selector 0 for DANE-TA, so it should be 2 0 1 (you can test your MX with mailhardener and it will point to that for example). I don’t see any configuration though that could fix that - does it exist? Could it be fixed somewhere/somehow?

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 a misconfiguration you can adjust, it’s how the DANE/TLSA generator is currently hard-coded. Looking at the certificate-to-TLSA conversion logic in the server, both the DANE-EE (3 1 1) and DANE-TA (2 1 1) records are always built with selector 1 (SubjectPublicKeyInfo) and matching type 1 (SHA-256):

let cert_usage = if cert_num == 0 {
    TlsaCertUsage::DaneEe
} else {
    TlsaCertUsage::DaneTa
};
...
record: DnsRecord::TLSA(TLSARecord {
    cert_usage,
    selector: TlsaSelector::Spki,
    matching: TlsaMatching::Sha256,
    cert_data: cert_data.to_vec(),
}),

There is no selector field exposed in the DANE/MtaTlsStrategy configuration objects to override this per usage type, so 2 0 1 for DANE-TA isn’t currently something you can set through the WebUI, config, or CLI. It’s purely determined by this code path, and both anchors always publish selector 1 (SPKI hash) rather than selector 0 (full certificate) for the TA record.

Reference: DANE / TLSA records docs

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

3

Stalwart emits 3 1 1 for DANE-EE and 2 1 1 for DANE-TA, with the selector hardcoded to SPKI (1) for both, and there’s currently no configuration to change the selector. The 3 1 1 DANE-EE record is the one RFC 7672 recommends and the one receiving MTAs primarily validate, so that part is correct and is what matters most in practice.

On the 2 1 1 vs 2 0 1 point: 2 1 1 is itself a valid RFC 6698 record, so it isn’t malformed, but you’re right that some tooling (mailhardener among them) prefers selector 0 for the TA record. Since the selector is hardcoded, there’s no way to switch it today.