So, I currently am using an e-mail proxy. It forwards the mails, but I cannot see them in my murena inbox. When I let the mails forward to another mail provider, I receive the mails. So, there must be a problem with murena mail atm.
Regain your privacy! Adopt /e/OS the deGoogled mobile OS and online services
I am having this problem, too, but only with emails forwarded from my Hotmail account and I am not using a proxy. They never show up in the Murena inbox, but they will show up in my Proton inbox if I forward them there. I don’t get a bounceback and they are not in Spam. I will file a ticket with Tech Support unless anyone has a suggestion.
I have problem too. I have tested with my outlook and Simplelogin account.
From outlook to murena: failed
murena → outlook: OK
Simplelogin → murena: failed
It seems that murena has a misconfiguration in DNS which caused DANE validation failure.
Here is the error message from outlook when I tried to send to murena:
Diagnostic information for administrators:
Generating server: SY0P300MB0743.AUSP300.PROD.OUTLOOK.COM
Receiving server: SY0P300MB0743.AUSP300.PROD.OUTLOOK.COM
REDACTED@murena.io
7/9/2025 12:06:25 AM - Server at SY0P300MB0743.AUSP300.PROD.OUTLOOK.COM returned '550 5.7.323 tlsa-invalid: The domain failed DANE validation(450 4.7.323 tlsa-invalid: The domain failed DANE validation)'
7/8/2025 11:56:18 PM - Server at murena.io (95.217.246.96) returned '450 4.7.323 tlsa-invalid: The domain failed DANE validation [Message=450 4.7.323 tlsa-invalid: The domain failed DANE validation] [LastAttemptedServerName=murena.io] [LastAttemptedIP=95.217.246.96:25] [SmtpSecurity=11;-1] [SY2PEPF00005069.ausprd01.prod.outlook.com 2025-07-08T23:56:25.004Z 08DDBE64B054E0CE](450 4.7.323 tlsa-invalid: The domain failed DANE validation)'
Reporting-MTA: dns;SY0P300MB0743.AUSP300.PROD.OUTLOOK.COM
Received-From-MTA: dns;SY0P300MB0612.AUSP300.PROD.OUTLOOK.COM
Arrival-Date: Tue, 8 Jul 2025 23:00:57 +0000
Final-Recipient: rfc822;REDACTED@murena.io
Action: failed
Status: 5.7.323
Diagnostic-Code: smtp;550 5.7.323 tlsa-invalid: The domain failed DANE validation
seems the shared TLSA selector (2 1 1) is the issue. I guess as both 443 and 25 tcp ports are cname aliased to the same selector at _dane.domain, but SMTP limits the record use to 2 types (3 1 1 / 2 0 1) - this is the hiccup?
Edit: 2 1 1 isn’t really verboten, but needs publishing the whole group of digests to be solid (the notes link).
As of writing I see the R3 cert published in the e.email TLSA record, R11 in ecloud.global… while the TLSA cert chain offered on starttls to ecloud was signed by the R10 intermediate… misaligned?
I just got bounceback messaages in the last hour and they, too, say the domain failed DANE validation.
Hello. I tried to debug this issue. It seems that the DNSSEC signature is OK. Murena is currently using a private-CA for DANE authentication.
The flag AD means DNSSEC validation has passed. It seems that the configuration 2 1 1 is an allowed but not popular configuration.
Here is the DNS resources I found:
smith@laptop:~$ dig murena.io MX +short
50 mail.ecloud.global.
10 mail.ecloud.global.
smith@laptop:~$ dig +dnssec +cdflag _25._tcp.mail.ecloud.global TLSA
; <<>> DiG 9.20.0-2ubuntu3.2-Ubuntu <<>> +dnssec +cdflag _25._tcp.mail.ecloud.global TLSA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25624
;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0x0005, udp: 1232
;; QUESTION SECTION:
;_25._tcp.mail.ecloud.global. IN TLSA
;; ANSWER SECTION:
_25._tcp.mail.ecloud.global. 5 IN CNAME _dane.ecloud.global.
_25._tcp.mail.ecloud.global. 5 IN RRSIG CNAME 13 5 10800 20250717000000 20250626000000 24280 ecloud.global. pKF4feL7Q5d2iH6jJCjax1DytCiRlH9p6jAiokhcnbffxw8Qdj3p1fDh L87WbwD3HH/vDdznCFahZf0js4M+tQ==
_dane.ecloud.global. 5 IN TLSA 2 1 1 6DDAC18698F7F1F7E1C69B9BCE420D974AC6F94CA8B2C761701623F9 9C767DC7
_dane.ecloud.global. 5 IN RRSIG TLSA 13 3 300 20250717000000 20250626000000 24280 ecloud.global. I8M8Aaaqp9QII1DfhgWpV5kUAVek8r26nTmatbBS13B81aCi9wOjhfbr cNcBIZD1EC5S8cHyi40H0G8r2chgHQ==
;; Query time: 221 msec
;; SERVER: 192.168.2.2#53(192.168.2.2) (UDP)
;; WHEN: Wed Jul 09 11:11:23 CST 2025
;; MSG SIZE rcvd: 341
private CA? it’s letsencrypt. DNSSEC can be valid, but DANE still fail. The TLSA record says "hey validate up until the place in the certificate chain that I pointed this selector at - and then you show the connecting SMTP a certificate with a signing chain without any certificate this matches to, bang, no validation. The resolution is doing either as the “note” says of the letsencrypt person: publish all certs in the TLSA rec that can be used by LE to hand you out a ssl cert so it will be found eventually - or go to mode 3 1 1 and use the certificates private key without relying on a CA (DANE-EE vs DANE-TA).
Do this: echo | openssl s_client -starttls smtp -connect mail.ecloud.global:25 | openssl x509 -noout -issuer
You’ll see the intermediate is R10, but that TLSA record 6DDAC18698F7F1F7E1C69B9BCE420D974AC6F94CA8B2C761701623F9 is the R11 intermediate. This breaks the chain of trust. If on renewal by accident R11 will be used for the new tls cert it will work again. That is why with the discouraged(?) 2 1 1 it’s advised to publish the whole group that can sign the cert.
This all came about because of the recent renewal of that cert (Not Before: Jul 6 00:05:15 2025 GMT).
It seems that the certificate for MX server mail.ecloud.global was renewed 3 days ago(on 2025-07-06), and my problem(can not receive from outlook) started precisely at that time.
nice screenshot, so things worked pretty well Feb-July 
(I guess the tlsa then was just updated, but the underlying issue is not publishing the group if staying with the 2 1 1 mode)
Okay guys, so I’m not very familiar with e-mail backend technology.
All I have observed at the moment is that I do not get mails from my proxy service. I can receive mails however if I send myself mails from another address. So I don’t really know if it’s the proxy service or murena where the problem lies…
Hey, you were right I guess. The proxy service also reported that some problems with DANE seem to exist.
They included this report in the mail.
things are better now, both ecloud.global tlsa and smtp ssl cert R10 signed, but not yet the whole group in the tlsa
But yes, that report has it right and provides a verbose explanation… bookmark (Edit: ah no - the report was made when smtp was already fine, but then broke 443 - the explanation in there still applies though)
Would it be possible for Murena to give notifications prior to certificate updates? Like a reminder, when mail will not work for a few days? Or is this just unexpected behaviour, that can’t be predicted?
Because I simply wouldn’t notice, if important mails would not arrive.
it’s a reminder to set up a dane probe continously monitoring for failure and let danebot do cert rollover. Enduser shouldn’t see disruptions. It’s a lot of rfcs to get familiar with if you’re not a dedicated mail person and murena is a mixed shop
This issue was resolved yesterday (this is an internal issue and may not be visible to all)
Pl recheck if the issue still exists.
will take to gitlab. Immediate issue was gone 11h ago already. Depends on implementation if it has a chance to come back on next cert renewal (10-12 weeks)
Hello. The configuration 2 1 1 6DDAC…3F9 means that
I only trust a private CA, and its SPKI hash is Lets Encrypt R11
It seems that murena have fixed this issue by setting TLSA record to “2 1 1 LE-R10”. They might have to manually update the record about 2 months later, and may trigger another service outage if they forget. (ACME protocol usually renews a certificate when it has passed 2/3 of its life span).
the spki hash part is right - but that report message has the wrong intro, letsencrypt is a public CA, they sign our certs right?
I guess murena integrated the tlsa part into their mail cert renewal automation. I don’t think this will crop up again significantly. They don’t use R10+R11 and their backup intermediates in a group of tlsa records, something that is more robust for rollovers as the TTL gap will not matter when the two records can get out of sync on renewal for a few minutes
I still have the problem that my simplelogin.io mails are bounced…