As of February 2021, does EOP/Microsoft now send DMARC aggregate reports?

[Jeremy Bradshaw]

I believe I have spotted evidence that the answer is yes.  If you look at this answers.microsoft.com thread the answer states:

TL;DR

Office 365 currently does not send out any DMARC reports. If it was sending out Aggregate reports, being behind a Mimecast would still generate reports for emails not filtered by Mimecast (not SPAM or Phishing). They would probably contain a lot of failures, because, for Office 365, the sending server will be Mimecast, which most likely is not added to the SPF of the sending domain. And, depending on what Mimecast is doing with the emails, the DKIM signature, if present at all, may be broken.

@The_Exchange_Team / @Greg Taylor - EXCHANGE  are you able to confirm if EOP does in fact now send DMARC aggregate reports?  Working with a customer whose MX records point to an on-premises mail gateway, and they're getting reports from affiliates who use DMARC in reporting mode that that their mail gateway is trying to send mail for them, unauthenticated'ly.  Essentially the exact issue that is alluded to in hypothetical terms in the quoted answer excerpt above.

Thanks in advance.

[#2]

BTW, I found the UserVoice request where Microsoft has been requested to start sending the aggregate reports, and where "Sean S" confirms it is "In the plans" as of April 2020 but with no ETA or update since then.
https://office365.uservoice.com/forums/289138-office-365-security-compliance/suggestions/11094318-dm...

[#3 · Accepted solution]

@Jeremy Bradshaw - Not yet Jeremy. You found the right User Voice however there is no ETA yet. 

[#4]

@Arindam Thokder  Thank you for confirming.  I also came into other findings which mooted my suspicion that it was Microsoft/EOP sending the reports.  That is to say, there were many other messages sent into EXO which should/would have been in the aggregate counts of said report, so it wasn't lining up like I thought.

[#5]

@Jeremy Bradshaw Now that Microsoft's Uservoice is dead, I'm curious where we should be pushing for this reporting to happen. It was an extremely popular Uservoice suggestion and never happened. The feedback options here are lackluster at best:
https://support.microsoft.com/en-us/topic/uservoice-pages-430e1a78-e016-472a-a10f-dc2a3df3450a?ui=en...

[#6]

I think the only option after user voice is to hope enough support-subscribing customers have tickets related and somehow Microsoft decides this requested-service would help alleviate the tickets.

I think a big part of the problem is how customers' "hybrid" mail flow into EXO (or mail flow from 3rd party spam service in front of EXO) comes in the same way as all external email so the room for false positive reporting is maximized.

[#7]

That makes sense. I wonder if they could find an elegant way to only report on messages that arrived to domains for which MX records point to Exchange Online. Might be too much overhead but it seems like that would solve the 3rd party hygiene problem.

[#8]

Yesterday I've noticed that Microsoft is sending DMARC aggregate reports, but the emails do not always reach their destination because the emails do not conform to the Internet Message Format (RFC 5322) standard. The BASE64 encoded attachment data is a single line without proper line breaks, causing the message to be rejected by most MTA's.

After forcing our mail servers to ignore the RFC violation for Microsoft's DMARC email address (dmarcreport@microsoft.com), the emails were accepted and processed. After a few hours I've received reports for @hotmail.*, @outlook.*, @live.* and @msn.com recipient addresses.

[#9]

Thanks for sharing this. Considering those recipient domains, I think that is Microsoft's Outlook.com service sending those reports, but not Microsoft 365/EOP.

Hopefully by the time EOP does do it, they'll have ironed out the RFC compliancy!

[#10]

@freddieleeman 

We have only recently started implementing DMARC and had also come across the lack of response from MS domains.  How did you detect that emails were being sent from dmarcreport@microsoft.com if they were not being delivered?

The fact that only consumer domains are being used seems to correspond to this DMARC Mail (Public Preview feature) at  Use DMARC to validate email, setup steps - Office 365 | Microsoft Docs

[#11]

@Martin_SmulianI've noticed "Maximum allowed line length is 998 octets" errors in the mail server reject log.

[#12]

Thanks all for the details and we have fixed the issue and it is rolling out.

[#13]

Great! Can you also add the parent 'version' and omit the 'extra_contact_info' element? It has a minOccurs of 0, so if you are not going to add extra contact information, you should remove the element entirely. Empty elements are not allowed. https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/

[#14]

@Arindam ThokderYou have only solved part of the problem. As of this week, the report attachment has been split into multiple lines, but unfortunately you didn't do this for the headers and body, so the entire message is still not RFC compliant.

And why do you (UTF8 BASE64) encode the subject and body, even when they do not contain special characters? I process DMARC aggregate reports from more than 3,000 organizations, and all of them (with the exception of Seznam) just use plain text, which makes processing them a lot easier.

[#15]

@freddieleeman - we have fixed the base 64 encoding issue by splitting the encoding line of test/html into lines of 78 characters. Could you please have a look.

[#16]

The last DMARC aggregate report we've processed was from today (Oct 27) at 11:55 CET, and it still had a base64 encoded text/html part that was not divided into lines of 78 characters. So why would you even base64 this part and the subject anyway?

[#17]

We are processing new reports from Outlook right now (06:20 CET), and the issue has not been resolved.

[#18]

Hi there, are you aware of any news about this?

[#19]

It looks like they resolved the issue with the email. Unfortunately, Outlook DMARC reports still have an issue with some DKIM signatures that cause about 1% of their reports to fail. https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/

[#20]

The DMARC reports from Microsoft are still broken.

1. RFC2045 clearly says that MIME Base64 lines should wrap at MAX 76 characters, not 78 (although 76 characters plus CRLF is 78 bytes, they send 78 characters plus CRLF, possibly because someone incorrectly used the general limit for mail in RFC5322, not the Base64 limit in RFC2045 section 6.6, which RFC5322 says overrides RFC5322 itself). Interestingly the .NET documentation at https://docs.microsoft.com/en-us/dotnet/api/system.convert.tobase64string?view=net-6.0 gets these numbers right.

2. They Base64 encode a us-ascii mime part, which is unnecessary and just a waste of disk space and network bandwidth.

3. Their cover letter mime-part tells recipient postmasters to send feedback to a specific dedicated address, but that address has been disabled and mail cannot be sent to it. Error is:
550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [DM3NAM06FT004.Eop-nam06.prod.protection.outlook.com]

4. The DMARC reports match a popular anti-spam filter suite (SpamAssassin) due to the above mistakes and one other mistake that I tried to tell them about, only to get that insulting bounce from their misconfigured feedback address.

DMARC reports are a feedback loop, and Microsoft managed to break both directions of that loop.