Preserve the submission envelope when integrating a phishing-report button

Source facts

For non-Microsoft reporting tools, Microsoft requires the unchanged original message as an uncompressed EML or MSG attachment, not a forwarded message. Submissions with several attached messages are discarded. The original must retain the documented antispam, message, network-message and tenant headers. Microsoft Learn.

The enclosing subject identifies the reporting reason: 1| or Junk:, 2| or Not junk:, and 3| or Phishing:. Without a prefix, the report is classified as phishing. Microsoft also requires preparation of the reporting mailbox as a SecOps mailbox and exclusion from DLP when DLP is used. Microsoft Learn.

Applicability

Review supported non-Microsoft reporting tools submitting email to an Exchange Online reporting mailbox. This is an integration-format check, not advice for users to manually forward suspicious messages or a claim that mailbox receipt guarantees successful triage.

DSE recommendation

DSE recommends documenting the tool’s exact submission envelope before enabling it broadly. Compare a harmless sample’s attachment, preserved headers and reason prefix with Microsoft’s requirements. Treat mailbox preparation as an explicit security configuration decision with an assigned owner. Keep reporting-button behavior separate from any later decision to submit the message to Microsoft for analysis.

Verification

Test junk, not-junk and phishing selections with approved samples and confirm the corresponding reason on the User reported page. Check that each envelope contains exactly one original message. Investigate a missing or wrongly classified entry by inspecting the submission format, rather than asking users to report the same message repeatedly. Preserve a sanitized example for integration regression tests.

Official references

Microsoft Learn: User reported settings.