Microsoft is finally sending DMARC aggregate reports (...poorly)

Microsoft has started sending DMARC aggregate reports, but unfortunately they don't know how to format a proper email.

Microsoft is finally sending DMARC aggregate reports (...poorly)

While doing routine maintenance, we encountered errors in our email rejection log. It turns out that Microsoft has been sending us DMARC aggregated reports from for quite some time, but they were never accepted and processed.

Microsoft's emails containing the DMARC reports do not conform to the Internet Message Format (RFC 5322) standard because the BASE64 attachment data is not divided into lines of 78 characters.

RFC 5322 chapter 2.1.1
There are two limits that this specification places on the number of characters in a line.  Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.

Below is a screenshot of a (raw) Microsoft DMARC email message. As you can see, the BASE64 encoded attachment data is a single line without proper line breaks.

Microsoft DMARC report email

The absence of line breaks caused our mail servers to refuse the email and fill our reject log with "Maximum allowed line length is 998 octets" errors.

Mail server reject log.

After forcing our mail servers to ignore the RFC violation for Microsoft's DMARC email address, the emails were accepted and processed within URIports. After a few hours, we had successfully processed reports for @hotmail.*, @outlook.*, @live.* and recipient addresses. DMARC reports within URIports.

We tried to contact Microsoft to inform them of their DMARC reporting issues, but unfortunately, the email address specified in the contact information field in the XML file was invalid, and our email got bounced.

For now, we will continue to ignore the RFC violation until Microsoft resolves the issue so that we can use the report data to assist our users in monitoring their email infrastructure.

UPDATE 2021/09/17:

As of today, Microsoft has partially resolved the issue by dividing the report attachment into multiple lines. Unfortunately, they didn't do this for the headers and body, so the email isn't RFC-compliant. Reports are now also generated for "non-Microsoft" recipient domains (other than @hotmail.*, @outlook.*, @live.* and