Not sure where to report the problem I experienced tonight when sending an email using my murena account. In short the message bounced back with the error message " Email bouncing back due to not passing DMARC verification". Seemingly the murena server would not be adequately configured (not sure according to whose standard though).
If this can help the begining of the error message is attached below (I only replaced my email address with murena_user_name@murena.io). The same happens with the e.email domain.
Happy to provide more information if this can help one way or anotherâŚ
Guitz
gel@zfk-logistik.de
Remote server returned â550 5.7.509 Access denied, sending domain murena.io does not pass DMARC verification and has a DMARC policy of reject.â
Original message headers:
ARC-Seal: i=4; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
b=BDvgysOHRApYJsOT73ExA3SeP42sujNr7pWCv16WEkbbPy/fNMu/Re64ytijmKcbD2e4/tF3SZtrEnjumt51ryDZ4/LJy4+QQ5wWXzgDBG7qDVSqiHx2TpdcZti1/rNjunNhl7bBEVYDaoHOVwLZ7jpJF4cHefk4BfOfs3CEEbRrtEU8k3IVAbr9P+2YG+Hjd7gBldpoh2OHJs5mzEXy4rVT3NWR+7sEGXJeQ+nyTj0vn3MSOFfG2wfnd9ARNc/nXTTE0wIfTjwPNiHLgIQaTxe14TVkmPuaqfrHdwmIRJJg/tgI0SAsq0sDmNTkLP+9Cjyhj7Bg7Rz7NKDPvVxigg==
ARC-Message-Signature: i=4; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=QdQVzUMzdZxk65CrDS+eNUR4ZtXxmWpbnqa2bxmrvfM=;
b=mGNi+g/VFFPzI8DCA1BKoTcHCKsCnXn4W844Kf0igAYDnT5wOK8OzQteAMHtCuVIw6jI41M6ifstQKkKaSibkdrPaHDhATORWpO8hKaEC3M4NChgTNUB8csyUrkEO5ewDiMnB4m90kRo4N5bC/o1nDGwUoYTqwclyTT8Y5Q17D3bxAzqy6BPdcH50aW5pSjFpT9T07VeTq2QzSGGVKPx2ueqjMNeN+YP0+wVNhsGTfMKu8rnVw4PNedUYvrQzwHb5FPZNUr2g/E3U97HFlLdCdMHi2gc1Lziy9M322CCqHHSFlo/xgeuxmoC7ArL5nlXuLvmakAKzU3CPUazwl81gg==
ARC-Authentication-Results: i=4; mx.microsoft.com 1; spf=pass (sender ip is
2a01:111:f403:c20a::7) smtp.rcpttodomain=zfk-logistik.de smtp.mailfrom=gel-express.de; dmarc=fail (p=reject sp=reject pct=100)
action=oreject header.from=murena.io; dkim=pass (signature was verified) header.d=gelexpresslogistik.onmicrosoft.com; dkim=fail (signature did not
verify) header.d=murena.io; arc=pass (0 oda=0 ltdi=0 93)
Received: from BE1P281CA0091.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:79::14)
by FR3PPF6C7912448.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d18:2::14f) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.21; Mon, 30 Jun
2025 19:02:15 +0000
Received: from BE1PEPF0000056D.DEUP281.PROD.OUTLOOK.COM
(2603:10a6:b10:79:cafe::84) by BE1P281CA0091.outlook.office365.com
(2603:10a6:b10:79::14) with Microsoft SMTP Server (version=TLS1_3,
cipher=TLS_AES_256_GCM_SHA384) id 15.20.8901.18 via Frontend Transport; Mon,
30 Jun 2025 19:02:15 +0000
Authentication-Results: spf=pass (sender IP is 2a01:111:f403:c20a::7) smtp.mailfrom=gel-express.de; dkim=pass (signature was verified) header.d=gelexpresslogistik.onmicrosoft.com;dkim=fail (signature did not
verify) header.d=murena.io;dmarc=fail action=oreject header.from=murena.io;compauth=fail reason=000
Received-SPF: Pass (protection.outlook.com: domain of gel-express.de
designates 2a01:111:f403:c20a::7 as permitted sender) receiver=protection.outlook.com; client-ip=2a01:111:f403:c20a::7; helo=PA4PR04CU001.outbound.protection.outlook.com; pr=C
Received: from PA4PR04CU001.outbound.protection.outlook.com
(2a01:111:f403:c20a::7) by BE1PEPF0000056D.mail.protection.outlook.com
(2603:10a6:b18:1::6) with Microsoft SMTP Server (version=TLS1_3,
cipher=TLS_AES_256_GCM_SHA384) id 15.20.8901.15 via Frontend Transport; Mon,
30 Jun 2025 19:02:14 +0000
ARC-Seal: i=3; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
@Didou S3150 is fundamentally different (at this time resolved - sure can come back, but itâs about rate limiting).
This here is about mail forwarding inevitably breaking dmarc alignment and how receivers can still make it work (not senders): [murena (i=1) â X (i=2)? - (dkim breaks earliest here) â gel-express (i=3) â zfk-logistik (i=4)]. The responsibility in forwarding to ensure delivery isnât with the original sender, itâs the mail admins forwarding and finally receiving.
@guitz 1. just mail the final receiver directly and link this thread for their mail admins - 2. youâre quoting i=4 to i=3 for ARC-Authentication-Results, Iâd need to see down to i=2 (example).
To make forwarding nowadays work, intermediaries needs to stamp ARC and the final mailserver trust all previous intermediaries to sensibly override its own policy (as in to not dmarc p=reject as murena wants, but to deliver to mailbox). The latter isnât setup at zfk logistik.
zfk-logistik needs to trust gel-express (i=3) and yet unkown (i=2) arc seals. As the headers are all ms/office365 internal, its admin portal allows to add trusted arc sealers. For i=3 and i=4 it was all arc cv (chain validation status) pass, arc-a-r with arc=pass too.
thanks! I can quote the AARs. The previously unknown i=2 was an internal gel-express forward:
ARC-Authentication-Results: i=4; mx.microsoft.com 1; spf=pass (sender ip is 2a01:111:f403:c200::3) smtp.rcpttodomain=zfk-logistik.de smtp.mailfrom=gel-express.de; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=e.email; dkim=pass (signature was verified) header.d=gelexpresslogistik.onmicrosoft.com; dkim=fail (signature did not verify) header.d=e.email; arc=pass (0 oda=0 ltdi=0 93)
ARC-Authentication-Results: i=3; mx.microsoft.com 1; spf=pass (sender ip is 135.181.6.248) smtp.rcpttodomain=gel-express.de smtp.mailfrom=e.email; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=e.email; dkim=pass (signature was verified) header.d=e.email; arc=pass (0 oda=0 ltdi=0 93)
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 135.181.6.248) smtp.rcpttodomain=gel-express.de smtp.mailfrom=e.email; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=e.email; dkim=pass (signature was verified) header.d=e.email; arc=pass (0 oda=0 ltdi=0 93)
ARC-Authentication-Results: i=1; mail2.ecloud.global; auth=pass smtp.mailfrom=example@e.email
you see intermediaries are happy (spf/dkim=pass for e.email) until the final recipient, itâs up to zfk-logistik then to trust the previous hop.
The action=oreject is a MS custom one. Possibly you got the bounce and they delivered to the destination mailboxes spam folder. With some config knobs it will get delivered to the regular mailbox, but the responsibility is on those employing forwarding.
technically it is the other way around: murena telling zfk to deny, as in their own DMARC policy published by their DNS it tells recipients to p=reject (âpolicy rejectâ) mail from murena-io if evaluated to illegitimate.
In zfks eyes the mail is a spoofed email from murena, and the murena domain tells it to deny it. With p=quarantine itâd be a âput it in spam pleaseâ.
If zfk uses forwarding from gel, but doesnât trust gel when it modifies the mail, then it will eval to illegitimate. DMARC alignment was fine in the gel realm, forwarding happened and what seems like modifications to both mail subject (â[EXTERN]â) and body (âAchtung: âŚâ), breaking the original senders dkim signature on those fields and dooming the mail.
Microsoft overwrites the policy to p=oreject (o as in optional?) to give mail admins a transition period to learn about current RFCs (ARC is from 2019) and issue the configs. For mail the 2000s are definitely over.
