IMAP Migration from Google Workspace to Microsoft 365
Hello Team, Greetings!! We have recently been experiencing significant delays during IMAP migrations from Google Workspace to Microsoft 365 and would like to understand if there are any known issues or recent changes affecting IMAP migration performance. We are aware that Microsoft provides the native Google Workspace migration method, which would generally be preferable. However, in our migration scenarios, we have split routing/coexistence configured, with the domain configured as Internal Relay in Exchange Online. Because of this setup, we are currently unable to select/configure the required target delivery domain as expected during the native Google Workspace migration process. Could you please confirm: Whether there are any known issues, throttling, or performance degradation with IMAP migrations from Google Workspace to Microsoft 365 recently? Whether the Internal Relay/split-routing configuration can affect the native Google Workspace migration process or the availability of the target delivery domain option? Is there any recommended configuration or workaround that would allow us to use the native Google Workspace migration while maintaining split routing? Any guidance or recommended approach would be highly appreciated.
Cross-tenant Migration
Hi all, I will be doing migration from existing tenant to a new one soon. I've recently completed IMAP migration to Exchange online, and also Google Workspace Migration to Exchange online.... So I thought that cross-tenant will be the easiest one as it is all under MS.... Looks that I was wrong, and seems to be quite the most challenging one 🙂 Few details first - there is a COMPANY-A tenant. There is also COMPANY-B domain created in that tenant . Now, COMPANY-B is going to move to a new tenant and keep the name. It will be only 15 users, so not a huge amount. So, I can see that there is a Cross-Tenant migration option available in EAC, so I want to use it. It does look a bit complicated anyway. What I'm trying to confirm/clarify is: Is the Cross-Tenant Migraiton option in EAC the one that I can use for my scenario? Checking https://docs.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration?view=o365-worldwide . It seems to be however a bit of work in powershell etc (I'm not expert with powershell). Is this the only and easiest way to do the migration? 🙂 Anyone has any guide on "step-by-step" that I could have a look? Would help me a lot. Are there any "tricky" parts that I should be aware of during migration? Ppl that already used this way to migrate PS: For SharePoint migration, I will use Migration and Mover that is abailable for via SharePoint... which seems to be quite straight forward. Any info that will help me to prepare for the move would be much appreciated.Microsoft Defender for Office 365: New “Move to Quarantine” Feature Coming Soon
Microsoft introducing Move to Quarantine, a new remediation action in Microsoft Defender for Office 365. It enables security teams to move potentially malicious email messages from users' mailboxes directly to Microsoft Defender quarantine. This provides a safer and more flexible way to contain suspicious messages that bypassed initial detection while preserving the ability to investigate, release, or permanently delete them later. This capability is available with Microsoft Defender for Office 365 Plan 2, including eligible Microsoft 365 subscriptions that include Plan 2. Rollout schedule General Availability (Worldwide): Beginning in early November 2026 and expected to complete by mid-December 2026 Remediate malicious email that was delivered in Office 365 - Microsoft Defender for Office 365 | Microsoft LearnExchange Web Services Enters the Final Mile
Exchange Web Services has entered its final mile, and Microsoft is now prompting Microsoft 365 tenants about the need to find and update EWS applications. All is well if the EWS usage report in the Microsoft 365 admin center lists nothing or a set of known applications, but only six months or so is available if some unidentified or unknown apps are listed. Time is running out and April 1, 2027 will come very quickly. What’s your tenant’s status? https://office365itpros.com/2026/10/23/exchange-web-services-final/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?
Access old Exchage after migration to 365
Hi all So I have migrated from Exchange OnPrem to Exchange Online. Before migration I have taken a snapshot from the Exchange server, just in case. Now, there is a user who claims that some of her contacts vanished during the migration. So I booted up the backup Exchange and tried logging into the OWA to see if I can find some cantacts there. However, when trying the OWA, using the localhost url I get redirected to the online Outlook. Obviously the Exchange server recognizes soemwhere in the AD that we have migrated. So my question: How do I access the old information on the OnPrem Exchange Server if I did not think of keeping a backup of the DC?Why do Apple macOS and Ubuntu clients display Exchange meeting times one hour earlier than scheduled
If a meeting is generated from Apple macOS and Ubuntu clients showing the meeting time as one hour earlier than the actual scheduled time email solution is exchange server 2019, what will be the issue.Teams calendar for exchange on prem users not working
Hello I am having issues to make Exchange On prem users use Calendar on teams. Initially Client autodiscover was blocked externally but they added a cname and open flows but I am still having issues to makecalendar on teams work HCW as passed and new hybrid dedicated app was used any help is welcome
