[German]A quick question for Exchange Online administrators. A reader reports problems with the delivery of mails that are delivered from on-premises Exchange servers. Since the November 2023 patchday, these are supposed to be moved directly to quarantine after acceptance. The recipient of the emails therefore never receives them in their Exchange Online mailbox.
Exchange Online blocks suddenly mails
German blog reader Björn has contacted me by e-mail because he has received reports of problems with mail delivery to Exchange Online from various customer systems. Here are the key points:
- Mails from on-premises Microsoft Exchange servers are accepted by Exchange Online.
- On Exchange Online, such messages are moved directly to quarantine.
- Emails that go through the same MTA but whose origin is not a Microsoft Exchange server (dovecot / postfix / roundcube) go through without any problems.
The problem has been occurring since the last patchday (November 14, 2023). The reader has sent me a header of the mails in question.
X-MS-Exchange-Organization-SCL: 5 X-Forefront-Antispam-Report: CIP:212.53.151.***;CTRY:DE;LANG:en;SCL:5;SRV:;IPV:NLI;SFV:SPM;H:sg1ms1.****.de;PTR:sg1ms1****.de;CAT:SPM;SFS:(13230031)(230922051799003)(451199024)(336012)(36756003)(564344004)(86362001)(7636003)(7596003)(356005)(3480700007)(6916009)(8676002)(1096003)(7116003)(19618925003)(5660300002)(19627405001)(22186003)(108616005)(24736004)(26005)(2616005)(58800400005);DIR:INB; X-Microsoft-Antispam: BCL:0;
According to this Microsoft support document, the messages are classified as SPAM. The reader asked if I had come across anything in this regard recently, but I had to deny this. During a quick search, I came across this discussion at German site administrator.de, where a year ago there was a case of all mails getting stuck in the SPAM filter. The advice there was to contact Microsoft.
My thoughts on this
Ad hoc, various thoughts crossed my mind on this topic. These range from a bug in Exchange to the announced security rules to take insecure Exchange servers out of circulation.
A bug in October 2023
On October 11, 2023, Exchange Online experienced a serious disruption to mail traffic. Several readers reported problems receiving emails from external email addresses. This was due to a faulty SPAM rule that Microsoft had rolled out, which blocked all messages from being delivered. I wrote about this in the article Exchange Online: Incident EX680695 (Oct. 11, 2023) reported. But I have not yet come again across a similar message.
Exchange Online blocks specific mails
The second topic spontaneously popped into my head: Microsoft wants to block the acceptance of mail from insecure on-premises Exchange servers under Microsoft Exchange Online. There was an announcement in spring 2023 in which a new security policy for Exchange Online was presented that blocks the acceptance of emails from insecure on-premises Exchange servers (in hybrid environments). The administrators concerned receive a notification that the on-premises Exchange server is vulnerable. If there is no response within 90 days, Exchange Online refuses to accept further emails.
The main aim is to eliminate systems with on-premises Exchange Server 2007, 2010 and, from April 2023, 2013 that have fallen out of support. For example, I reported on this approach in the blog post Exchange Online blocks mail from on-premises Exchange servers with vulnerabilities. And in May 2025, Microsoft launched this approach (see Exchange Online: Microsoft will now block mails from unpatched Exchange systems). However, this does not really fit in with the above topic, as the administrators of the on-premises Exchange servers should receive feedback from Exchange Online that mail acceptance has been denied.
Additional information
There is a heavy discussion about the issue within the German edition of this blog post. The affected administrator has since responded with two supplements, which I will add here.
No insecure Exchange Server
In the text above, I touched on the topic of Exchange Online blocks mail from on-premises Exchange servers with vulnerabilities, but I wrote that I do not consider this scenario to be plausible in terms of the error pattern. The same assumption was also made to me on Facebook by an administrator. Björn contacted me again about this and wrote about it:
The behavior occurs from various on-prem Exchange servers as the sending system.
One of the on-prem Exchange is ours, it is completely patched and Healthchecker says everything is green except for Extended Protection. We will activate this soon.
Do the headers indicate whether extended protection is active?
So this is once again the negation that the new security function of Exchange Online is blocking something planned. I can't say much about the last question regarding extended protection.
Björn then sent me the complete header in a form anonymized by him by e-mail, which I am posting below.
Received: from PAXPR08MB7419.eurprd08.prod.outlook.com (2603:10a6:102:2ba::11) by DU2PR08MB7237.eurprd08.prod.outlook.com with HTTPS; Mon, 20 Nov 2023 13:55:22 +0000 Received: from DB3PR06CA0018.eurprd06.prod.outlook.com (2603:10a6:8:1::31) by PAXPR08MB7419.eurprd08.prod.outlook.com (2603:10a6:102:2ba::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.27; Mon, 20 Nov 2023 13:55:20 +0000 Received: from DU2PEPF0001E9C4.eurprd03.prod.outlook.com (2603:10a6:8:1:cafe::3a) by DB3PR06CA0018.outlook.office365.com (2603:10a6:8:1::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.27 via Frontend Transport; Mon, 20 Nov 2023 13:55:20 +0000 Authentication-Results: spf=pass (sender IP is *.*.*.*) smtp.mailfrom=***.eu; dkim=none (message not signed) header.d=none;dmarc=bestguesspass action=none header.from=***.eu;compauth=pass reason=109 Received-SPF: Pass (protection.outlook.com: domain of ***.eu designates *.*.*.* as permitted sender) receiver=protection.outlook.com; client-ip=*.*.*.*; helo=***.***.de; pr=M Received: from ***.***.de (*.*.*.*) by DU2PEPF0001E9C4.mail.protection.outlook.com (10.167.8.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7025.12 via Frontend Transport; Mon, 20 Nov 2023 13:55:19 +0000 Received: from localhost (localhost [127.0.0.1]) by ***.***.de (Postfix) with ESMTP id 0E85B340517 for <info@***.de>; Mon, 20 Nov 2023 14:55:19 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at ***.***.de Received: from ***.***.de ([127.0.0.1]) by localhost (***.***.de [127.0.0.1]) (amavisd-new, port 10026) with LMTP id qLMryEdIhwbD for <info@***.de>; Mon, 20 Nov 2023 14:55:18 +0100 (CET) Received: from ***.***.eu (***.dip0.t-ipconnect.de [*.*.*.*]) (Authenticated sender: relay@***.de) by ***.***.de (Postfix) with ESMTPSA id CA8473401A0 for <info@***.de>; Mon, 20 Nov 2023 14:55:18 +0100 (CET) Received: from [192.168.1.229] (port=14294 helo=***.***.eu) by ***.***.eu with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <***@***.eu>) id 1r54k8-0004Vc-2A for info@***.de; Mon, 20 Nov 2023 14:55:16 +0100 Received: from ***.***.local (192.168.1.229) by ***.***.local (192.168.1.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Mon, 20 Nov 2023 14:56:54 +0100 Received: from ***.***.local ([fe80::60e6:1863:5d32:509e]) by ***.***.local ([fe80::60e6:1863:5d32:509e%4]) with mapi id 15.01.2507.023; Mon, 20 Nov 2023 14:56:54 +0100 From: *** <***@***.eu> To: "info@***.de" <info@***.de> Subject: Test Thread-Topic: Test Thread-Index: AQHaG7lrVU0/tkXu1Eu4jckar5Dqsg== Date: Mon, 20 Nov 2023 13:56:53 +0000 Message-ID: <1c8c4c5fc2ed409db57c72c44e8424a4@***.eu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.242.2.10] Content-Type: multipart/alternative; boundary="_000_1c8c4c5fc2ed409db57c72c44e8424a4***eu_" MIME-Version: 1.0 Return-Path: ***@***.eu X-MS-Exchange-Organization-ExpirationStartTime: 20 Nov 2023 13:55:19.5843 (UTC) X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000 X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit X-MS-Exchange-Organization-Network-Message-Id: 0a81698e-827c-44f8-e757-08dbe9d05540 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 32c17c4d-863b-4a0c-a8bb-012f38c616e8:0 X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PEPF0001E9C4:EE_|PAXPR08MB7419:EE_|DU2PR08MB7237:EE_ X-MS-Exchange-Organization-AuthSource: DU2PEPF0001E9C4.eurprd03.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Office365-Filtering-Correlation-Id: 0a81698e-827c-44f8-e757-08dbe9d05540 X-MS-Exchange-Organization-SCL: 5 X-Forefront-Antispam-Report: CIP:*.*.*.*;CTRY:DE;LANG:en;SCL:5;SRV:;IPV:NLI;SFV:SPM;H:***.***.de;PTR:***.***.de;CAT:SPM;SFS:(13230031)(230922051799003)(451199024)(336012)(36756003)(564344004)(86362001)(7636003)(7596003)(356005)(3480700007)(6916009)(8676002)(1096003)(7116003)(19618925003)(5660300002)(19627405001)(22186003)(108616005)(24736004)(26005)(2616005)(58800400005);DIR:INB; X-Microsoft-Antispam: BCL:0; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2023 13:55:19.3968 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0a81698e-827c-44f8-e757-08dbe9d05540 X-MS-Exchange-CrossTenant-Id: 32c17c4d-863b-4a0c-a8bb-012f38c616e8 X-MS-Exchange-CrossTenant-AuthSource: DU2PEPF0001E9C4.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB7419 X-MS-Exchange-Transport-EndToEndLatency: 00:00:03.4629586 X-MS-Exchange-Processed-By-BccFoldering: 15.20.7002.027 X-Microsoft-Antispam-Mailbox-Delivery: ucf:0;jmr:0;auth:0;dest:J;OFR:SpamFilterAuthJ;ENG:(910001)(944506478)(944626604)(920097)(930097)(3100021)(140003);RF:JunkEmail;
Perhaps someone from the readership can think of something else.
Cause remains unclear
In the following reader comments, I found it interesting that QR codes integrated into emails could be the trigger for a quarantine. Björn also commented on this in a follow-up email.
The QR code issue was checked immediately after the tip. Björn writes: "Of course I also saw this and checked it immediately. You have images and links in your signature, but no QR codes."
The hint turned out to be a dead end. The reader then added the following findings in the email:
What I find totally annoying, and what I can't get on with, is that on the receiver (if you have access to it, which is very rare) I see under:
*ttps://security.microsoft.com/quarantine
but only get very general reasons for the rejection:
- Reason for quarantine: message with high probability of phishing
- Policy type: Antispam policy
- Policy name: Default
If you then go to the header analysis, you always end up with the "Spam rules", e.g.
(13230031)(7916004)(230922051799003)(230173577357003) (230273577357003)(451199024)(1690799017)(6916009)(58800400005) (19627405001)(26005)(336012)(36736006)(7636003)(7596003)(356005) (166002)(6506007)(6512007)(6486002)(966005)(33964004)(6666004) (9686003)(8676002)(22186003)(1096003)(5660300002)(3450700001) (33716001)(9316004)(76236004)(83170400001)(76899018)(131040200001)But it's not at all clear which rule applies and what each rule does. I can't get any further there.
Regardless of this, we have now set up DKIM for the customer and Exchange Online is now accepting the email with an SCL of 1.
In any case, thank you for your efforts! I would really like to know what the cause is.
I must pass on the thanks of the person concerned to the readership for their participation in the discussion. But we haven't made any progress on the matter – Exchange Online remains a black box in this respect, doesn't it?
German blog reader Henning got in touch on Mastodon and wrote: Has also happened with our customers. It has to do with the content filtering of Exchange Online Protection. The URLs probably have to be activated individually via a case.
