How to Record Long Term Statistics About Mail Flow Rule Reports
A question about an article describing how to use a mail flow rule to suppress inbound email from spammer domains led to a discussion about gathering statistics over a longer period than the ten days allowed by the Get-MailDetailTransportRuleReport cmdlet. The solution is a scheduled Azure Automation runbook to update a CSV file stored in SharePoint with weekly statistics. Over time, data accrues to support statistical analysis. The solution works, with some care taken with Graph SDK Files cmdlets. https://office365itpros.com/2026/10/22/mail-flow-rule-long-term/
Exchange RFC 6710, RFC 6758 and RFC 4021 compliance
I need to verify whether Exchange Online supports the following SMTP extension RFCs: RFC 6710 - Simple Mail Transfer Protocol Extension for Message Transfer Priorities (MT-PRIORITY) RFC 6758 - Tunneling Plaintext Authentication Credentials Using TLS (CRAM) RFC 4021 - Registration of Mail and MIME Header Field Names Specifically, I need to know: Are these RFCs implemented and advertised in the Exchange Online SMTP EHLO response? Is there official Microsoft documentation that lists the complete set of supported SMTP extensions for Exchange Online? If these RFCs are not supported, is there a published list of unsupported RFCs or a roadmap for future implementation? Context: I'm integrating third-party mail systems that require RFC 6710 (MT-PRIORITY) support for priority message handling. Currently, Microsoft documentation only references RFCs 3030, 2920, 6698, and 8461 as supported extensions, but there is no comprehensive list of unsupported RFCs. Any clarification or documentation would be greatly appreciated.
Accepted Domain Verification Causes Mail Flow Failure to Google Workspace Recipients (No MX Changes)
Scenario Source: - Google Workspace (production) - All users actively using Gmail Target: - Microsoft 365 tenant - Existing Exchange Online users Actions Performed 1. Added the production domain to Microsoft 365. 2. Added only the TXT record required for domain verification. 3. No MX, SPF, or other mail-routing records were changed. 4. Domain verification completed successfully. Observed Behavior - Users in the Microsoft 365 tenant could no longer send email to recipients hosted in Google Workspace using the same domain. - Google Workspace users continued to receive email from external senders. - MX records remained pointing to Google Workspace. Testing Performed 1. Removed the domain from Microsoft 365. Result: Mail flow to Google Workspace users worked normally. 2. Added the domain and TXT verification again. Result: Mail flow failure immediately reoccurred. 3. Repeated the test multiple times with consistent results. Question Is this expected behavior when a domain becomes an accepted domain in Exchange Online, even if MX records remain pointed to Google Workspace? Has anyone experienced similar recipient-resolution or routing behavior during Google Workspace to Microsoft 365 migration preparation?
