DMARC hacked bypassed with empty header.from or only semicolon

WRAP UP

On the 26th of September 2024 an email was delivered to one of our Exchange Online mailboxes from the Internet through EOP that spoofes one of our accepted domains although this domain is protected by a DMARC reject policy and by DKIM and SPF nobody as allowed to use this domain as a sender domain.

INTRODUCTION

Microsoft Support refused to support this case more or less because I insisted on the DKIM and SPF configuration being perfectly fine. They pointed me at community or their paid support.

The domain in question (here: spoofeddomain.de) is only kept by me as an accepted domain in Exchange Online for the purpose of receiving email, but for sending email. The MX points at EOP. I have disabled DKIM in order to make sure nobody can get a DKIM pass and to contribute to nobody can get a DMARC pass using this domain as sender domain. For the same reason I have set the SPF record "v=spf1 -all" prohibiting any IP to send in the name of this domain.

ANALYSIS

Outlook shows the following as sender: f.last@ <spoofeddomain.de email address removed for privacy reasons>

Clicking on properties Outlook shows...

Displayname: f.last@

Email-Address: spoofeddomain.de email address removed for privacy reasons

The Authentication Results Header shows the following:

CAUSE

The attacker seems to be able to work around the mechanism of the EOP that determines the header.from. As a consequence he is able to spoof spoofeddomain.de because the EOP has no header.from domain that it could get a DMARC policy for. If it had, it would have come to a DMARC fail, because we have DKIM disabled and "v=spf1 -all".

ASSESSMENT
I think the best way to argue Microsoft is right, is to say that spoofeddomain.de is not the actual header.from according to RFC. Furthermore the sender shown in Outlook is not unambigous. However if a user wants to determine the sender domain from this, which domain should he or she determine but spoofeddomain.de?

MITIGATION

I put transport rules in place that quarntine emails with Authentication-Results or Authentication-Results-Original "header.from=;". However since I have not established a testing process yet, I'm not sure if they will work.