# Bug: DANE/DNSSEC validation rejects live.com MX records and blocks outbound SMTP delivery ## Summary hMailServer 6.3.6-B45 may incorrectly reject DNSSEC-signed MX records for `live.com` when outbound DANE enforcement is enabled. The issue was also observed with version 6.3.4-B43. Although public DNS resolvers successfully resolve the MX records and a validating resolver reports successful DNSSEC authentication, hMailServer rejects the MX RRset and defers message delivery without attempting an SMTP connection. Disabling outbound DANE enforcement restores delivery. ## Affected versions * hMailServer 6.3.4-B43 * hMailServer 6.3.6-B45 Operating system: Windows Server 2022 x64. ## Steps to reproduce 1. Configure hMailServer to deliver outgoing SMTP messages directly to recipient MX servers. 2. Enable outbound DANE/TLSA enforcement. 3. Enable DNSSEC validation. 4. Enable MTA-STS. 5. Send a message to an address at `live.com`. 6. Examine the SMTP delivery logs. ## Actual behavior The MX lookup succeeds: `DNS MX lookup: live.com DNS - Result. Query: live.com, type 15, status 0, records 1, system servers, success` However, hMailServer subsequently reports: `MTA-STS policy mode 'enforce' active for live.com. TLS with certificate validation is required. the MX RRset for live.com failed DNSSEC validation. Skipping live-com.olc.protection.outlook.com (RFC 7672 section 2.2). TLS-RPT: a failed session with live.com recorded: dnssec-invalid at live-com.olc.protection.outlook.com (policy tlsa). Delivery to live.com deferred: the MX records of live.com failed DNSSEC validation. No host was attempted.` The message remains queued for a subsequent delivery attempt. ## Public DNSSEC verification The publicly resolvable MX record is: `live.com MX 2 live-com.olc.protection.outlook.com.` During testing, DNS responses included: * An RRSIG covering the MX RRset. * DNSKEY records using DNSSEC algorithm 13. * A DS record using algorithm 13 and digest type 2. Independent DNS-over-HTTPS validation using Cloudflare returned: `Status: 0 AD: true CD: false Answer: live.com MX 2 live-com.olc.protection.outlook.com.` This indicates that the validating resolver successfully authenticated the MX response. It does not, by itself, identify why hMailServer's internal DNSSEC validation fails. ## Temporary workaround Disabling outbound DANE/TLSA enforcement allows delivery to complete. The following protections remain enabled: * DNSSEC validation. * MTA-STS. * TLS certificate validation when required by MTA-STS. After applying the workaround, a test message was successfully accepted by Microsoft's receiving infrastructure over TLS 1.3. The workaround restores delivery but reduces transport security for destinations relying on DANE without MTA-STS. ## Expected behavior hMailServer should correctly process DNSSEC-authenticated MX records and proceed with outbound SMTP delivery according to the applicable DANE and MTA-STS policies. If DNSSEC validation genuinely fails, diagnostic logging should identify the validation stage and reason for failure. A global reduction in DANE enforcement should not be necessary to deliver messages to destinations with valid DNSSEC records. ## Questions for maintainers 1. Is this a known DNSSEC/DANE validation issue in versions 6.3.4-B43 or 6.3.6-B45? 2. Could the failure be related to DNSSEC algorithm 13, DNSSEC chain validation, or DNS response handling? 3. Are additional diagnostic logs available for the DNSSEC validator? 4. Is there a supported per-domain DANE enforcement exception? 5. Is a fix or configuration change available that would allow outbound DANE enforcement to remain enabled? ## Additional notes The observed failure occurs before an SMTP connection to the destination MX is attempted. Disabling DANE enforcement is a confirmed workaround in the tested environment, but the underlying cause remains undetermined.