<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Known issue in 6.3.7 and 6.3.8: mail to some DNSSEC-signed domains stays in the queue]]></title><description><![CDATA[<p dir="auto"><strong>Who this affects:</strong> servers on 6.3.7 or 6.3.8 that deliver mail directly to recipients' mail servers. 6.3.6 may be affected too. Mail sent through an SMTP relay or a route isn't affected.</p>
<p dir="auto"><strong>What you'll see:</strong> messages to some domains stay in the delivery queue and are retried later, even though your DNS server is working. If that goes on long enough, the sender gets a bounce. We've seen it with <a href="http://paypal.com" rel="nofollow ugc">paypal.com</a>, <a href="http://seznam.cz" rel="nofollow ugc">seznam.cz</a>, <a href="http://kpnmail.nl" rel="nofollow ugc">kpnmail.nl</a> and <a href="http://xs4all.nl" rel="nofollow ugc">xs4all.nl</a>, and it isn't limited to those. With application logging on, the log says the DNSSEC lookup of the TLSA records "could not be completed".</p>
<p dir="auto"><strong>The cause:</strong> a bug in our DNSSEC checking. Some signed domains prove that a name doesn't exist in a valid way that our code misreads as incomplete. The server then can't tell whether the domain requires DANE, so it holds the message rather than risk sending it insecurely.</p>
<p dir="auto"><strong>What to do:</strong> the fix is in testing for 6.3.9, which has no date yet. If you have mail stuck now:</p>
<ol>
<li>In the Control Panel, open Transport security, then the Encryption tab, and find DANE &amp; DNSSEC.</li>
<li>Untick "Honour recipient DANE/TLSA records when sending", then choose Save changes.</li>
<li>Open the delivery queue and choose Deliver all now.</li>
</ol>
<p dir="auto">This turns off DANE checks for all your outgoing mail, so tick it again once you're on 6.3.9. Use the Control Panel rather than editing hMailServer.ini, because an ini edit is hard to undo. If you run on Linux, which has no Control Panel, post here and we'll help you with this step.</p>
<p dir="auto"><strong>If nearly all your outgoing mail is stuck,</strong> the cause is more likely a DNS server or firewall that drops DNSSEC data or blocks DNS over TCP. The same steps get mail moving while you look at that.</p>
<p dir="auto">If you're seeing something else, please post the log line here with addresses and passwords removed.</p>
]]></description><link>https://www.hmailserver.co.uk/topic/28279/known-issue-in-6.3.7-and-6.3.8-mail-to-some-dnssec-signed-domains-stays-in-the-queue</link><generator>RSS for Node</generator><lastBuildDate>Thu, 05 Nov 2026 23:45:12 GMT</lastBuildDate><atom:link href="https://www.hmailserver.co.uk/topic/28279.rss" rel="self" type="application/rss+xml"/><pubDate>Wed, 04 Nov 2026 20:31:42 GMT</pubDate><ttl>60</ttl></channel></rss>