Forum Discussion

JeremyTBradshaw's avatar
JeremyTBradshaw
Steel Contributor
Feb 05, 2021

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

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.

    • freddieleeman's avatar
      freddieleeman
      Brass Contributor

      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.

      • Arindam_Thokder's avatar
        Arindam_Thokder
        Icon for Microsoft rankMicrosoft
        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.
  • freddieleeman's avatar
    freddieleeman
    Brass Contributor
    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.
    • Just_Asking's avatar
      Just_Asking
      Copper Contributor

      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

       

       

    • JeremyTBradshaw's avatar
      JeremyTBradshaw
      Steel Contributor
      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!
    • JeremyTBradshaw's avatar
      JeremyTBradshaw
      Steel Contributor
      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.
      • thomaspomroy's avatar
        thomaspomroy
        Copper Contributor
        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.
    • JeremyTBradshaw's avatar
      JeremyTBradshaw
      Steel Contributor

      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.

Resources