Microsoft Issues Updated Guidance for Defender for Office 365 Licensing
Some inconsistencies in the MDO P2 service description and licensing terms exposed a need for tenants to license every user and shared mailboxes. Microsoft has changed the service description and licensing terms to make them simpler. Mailboxes still need MDO licenses, but only if they benefit from MDO protection, including MDO P2 if that’s what they use. Tenant admins have some extra work to do to deploy policies. All explained here. https://office365itpros.com/2025/10/31/mdo-p2-licensing/
Compliance licenses at tenant level
Hi, We are a small organization of about 200 employees, and we have following requirements. DLP policies configuration at Exchange, OneDrive, SharePoint BYOD security Users should not be able to send files outside the org And so on as we evaluate We already have M365 Business Premium. However, after researching we figured out that M365 Business premium will alone not solve our requirements. May be compliance license will. We want to apply security policies at tenant level in our organization but definitely do not want every user to get licenses as this will be expensive for us and there is no requirement at all for our users. The question is, Is there a way to solve the above scenario?Disable Direct Send in Exchange Online to Mitigate Ongoing Phishing Threats
Direct Send allows devices and applications to send unauthenticated emails over port 25 directly to Exchange Online. While this may support legacy devices like printers or scanners, it also opens the door for threat actors to deliver spoofed emails without authentication. These messages often appear to come from trusted internal sources, making them especially dangerous. To reduce your organization’s exposure to this threat, it's strongly recommended to disable Direct Send using Microsoft’s newly introduced RejectDirectSend setting. You can quickly enable this setting using PowerShell: Connect-ExchangeOnline Set-OrganizationConfig -RejectDirectSend $true If you still have devices or applications that need to send emails, use authenticated SMTP submission or set up connector-based routing with certificate or IP restrictions.Securing the Modern Workplace: Transitioning from Legacy Authentication to Conditional Access
Authored by: Gonzalo Brown Ruiz, Senior Microsoft 365 Engineer & Cloud Security Specialist Date: July 2025 Introduction In today’s threat landscape, legacy authentication is one of the weakest links in enterprise security. Protocols like POP, IMAP, SMTP Basic, and MAPI are inherently vulnerable — they don’t support modern authentication methods like MFA and are frequently targeted in credential stuffing and password spray attacks. Despite the known risks, many organizations still allow legacy authentication to persist for “just one app” or “just a few users.” This article outlines a real-world, enterprise-tested strategy for eliminating legacy authentication and implementing a Zero Trust-aligned Conditional Access model using Microsoft Entra ID. Why Legacy Authentication Must Die No support for MFA: Enables attackers to bypass the most critical security control Password spray heaven: Common vector for brute-force and scripted login attempts Audit blind spots: Limited logging and correlation in modern SIEM tools Blocks Zero Trust progress: Hinders enforcement of identity- and device-based policies Removing legacy auth isn’t a nice-to-have — it’s a prerequisite for a modern security strategy. Phase 1: Auditing Your Environment A successful transition starts with visibility. Before blocking anything, I led an environment-wide audit to identify: All sign-ins using legacy protocols (POP, IMAP, SMTP AUTH, MAPI) App IDs and service principals requesting basic auth Users with outdated clients (Office 2010/2013) Devices and applications integrated via PowerShell, Azure Sign-In Logs, and Workbooks Tools used: Microsoft 365 Sign-In Logs Conditional Access insights workbook PowerShell (Get-SignInLogs, Get-CASMailbox, etc.) Phase 2: Policy Design and Strategy The goal is not just to block — it’s to transform authentication securely and gradually. My Conditional Access strategy included: Blocking legacy authentication protocols while allowing scoped exceptions Report-only mode to assess potential impact Role-based access rules (admins, execs, vendors, apps) Geo-aware policies and MFA enforcement Service account handling and migration to Graph or Modern Auth-compatible apps Key considerations: Apps that support legacy auth only Delegates and shared mailbox access scenarios BYOD and conditional registration enforcement Phase 3: Staged Rollout and Enforcement A phased approach reduced friction: Pilot group enforcement (IT, InfoSec, willing users) Report-only monitoring across business units Clear communications to stakeholders and impacted users User education campaigns on legacy app retirement Gradual enforcement by department, geography, or risk tier We used Microsoft Entra’s built-in messaging and Service Health alerts to notify users of policy triggers. Phase 4: Monitoring, Tuning, and Incident Readiness Once policies were in place: Monitored Sign-in logs for policy match rates and unexpected denials Used Microsoft Defender for Identity to correlate legacy sign-in attempts Created alerts and response playbooks for blocked sign-in anomalies Results: 100% of all user and app traffic transitioned to Modern Auth Drastic reduction in brute force traffic from foreign IPs Fewer support tickets around password lockouts and MFA prompts Lessons Learned Report-only mode is your best friend. Avoids surprise outages. Communication beats configuration. Even a perfect policy fails if users are caught off guard. Legacy mail clients still exist in vendor tools and old mobile apps. Service accounts can break silently. Replace or modernize them early. CA exclusions are dangerous. Every exception must be time-bound and documented. Conclusion Eliminating legacy authentication is not just a policy update — it’s a cultural shift toward Zero Trust. By combining deep visibility, staged enforcement, and a user-centric approach, organizations can securely modernize their identity perimeter. Microsoft Entra Conditional Access is more than a policy engine — it is the architectural pillar of enterprise-grade identity security. Author’s Note: This article is based on my real-world experience designing and enforcing Conditional Access strategies across global hybrid environments with Microsoft 365 and Azure AD/Entra ID. Copyright © 2025 Gonzalo Brown Ruiz. All rights reserved.Building Enterprise-Grade DLP with Microsoft Purview in Hybrid & Multi-Cloud Environments
Authored by: Gonzalo Brown Ruiz, Senior Microsoft 365 Engineer & Cloud Security Specialist Date: July 2025 Introduction Data is the lifeblood of every modern organization, yet it remains one of the most exposed assets. As organizations embrace hybrid and multi-cloud models, traditional endpoint or email-only DLP solutions no longer provide sufficient protection. The explosion of data across Exchange, SharePoint, Teams, OneDrive, and third-party SaaS applications introduces new risks and compliance challenges. Microsoft Purview Data Loss Prevention (DLP) provides a powerful solution that unifies data governance, sensitivity labeling, and policy enforcement across your cloud ecosystem. However, building an enterprise-grade DLP strategy goes far beyond enabling policies. Why Traditional DLP Fails in Modern Environments Traditional DLP approaches often: Protect only endpoints or email without covering cloud services Lack integration with data classification and labeling frameworks Generate excessive false positives due to generic rule sets Create operational friction for end users In hybrid environments with Teams, SharePoint, and OneDrive, these limitations lead to fragmented coverage, compliance blind spots, and user workarounds that expose sensitive data. The Microsoft Purview Advantage Microsoft Purview DLP offers: Unified policy management across Exchange Online, SharePoint, Teams, and OneDrive Integration with Sensitivity Labels for data classification and encryption Real-time policy tips that educate users without blocking productivity Built-in compliance manager integration for audit readiness When architected properly, Purview becomes a strategic enabler of data governance and compliance rather than just a security checkbox. Key Components of an Enterprise-Grade DLP Strategy 1. Data Classification and Labeling Implement Sensitivity Labels with auto-labeling policies to classify and protect sensitive data at scale. 2. Policy Scoping and Exceptions Handling Design DLP policies that balance security with operational needs, incorporating exceptions for justified business processes. 3. Insider Risk Management Integration Correlate DLP events with insider risk signals to identify intentional or accidental data misuse. 4. Audit, Reporting, and Compliance Evidence Configure alerting, detailed reporting, and data residency mapping to fulfill regulatory and internal audit requirements. Implementation Framework: Your Step-by-Step Guide 1. Preparation Conduct a data inventory and sensitivity assessment Identify regulatory and contractual compliance obligations Engage business stakeholders for adoption readiness 2. Pilot Deployment Roll out policies to a controlled user group Review policy matches and refine rules to minimize false positives Provide targeted user training on policy tips and data handling expectations 3. Full Deployment Scale DLP policies across workloads (Exchange, SharePoint, Teams, OneDrive) Implement automated remediation actions with user notifications and audit logs 4. Optimization and Continuous Improvement Review policy match reports regularly to fine-tune thresholds and rules Incorporate feedback from security, compliance, and end users Integrate with eDiscovery workflows for legal readiness Best Practices and Lessons Learned Start with monitor-only policies to baseline activity before enforcing blocks Combine DLP with Sensitivity Labels and encryption policies for holistic protection Regularly educate users on data classification and handling standards Create clear governance structures for DLP ownership and policy management Balance security controls with user productivity to avoid shadow IT workarounds Conclusion Data Loss Prevention is no longer optional – it is a critical enabler of trust, compliance, and operational excellence. By architecting Microsoft Purview DLP as part of an enterprise data governance strategy, organizations can protect their most valuable asset – data – while empowering users to work securely and efficiently. Author’s Note: This article is based on my extensive professional experience designing and implementing Microsoft Purview DLP solutions for global enterprises across hybrid and multi-cloud environments. Copyright © 2025 Gonzalo Brown Ruiz. All rights reserved.The Art of Corporate Domain Rebranding in Microsoft 365: Technical and Compliance Challenges
Introduction Corporate domain rebranding is often perceived as a simple marketing change — a new name, refreshed logo, and website updates. However, within Microsoft 365 environments, rebranding becomes a complex technical operation impacting identity systems, authentication, collaboration tools, compliance archives, and user experiences. Having led multiple major domain rebranding initiatives, I’ve uncovered strategic and technical challenges organizations must anticipate, along with best practices to ensure seamless transformation. Key Technical Challenges in Domain Rebranding 1. Email Identity and Legacy SMTP Preservation Every user, shared mailbox, and distribution list must be readdressed, preserving historical SMTP aliases for continuity and legal compliance. Reference: https://learn.microsoft.com/en-us/exchange/email-addresses-and-address-books/email-address-policies/email-address-policies 2. OneDrive for Business and SharePoint Online URL Dependencies Rebranding requires careful planning for OneDrive and SharePoint URLs, tied to the tenant’s primary domain. Microsoft now supports renaming SharePoint domains — a feature I implemented to transition from legacy SharePoint domains to new branded domains using PowerShell and Microsoft’s supported process. Reference: https://learn.microsoft.com/en-us/sharepoint/change-your-sharepoint-domain-name 3. Authentication and Directory Synchronization Impacts When using Microsoft Entra Connect (Azure AD Connect), all User Principal Names (UPNs) must be adjusted to reflect the new domain, ensuring no disruptions to hybrid synchronization or Conditional Access policies. Reference: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-staging-server 4. Microsoft Teams and External Federation Teams relies on domain-based routing. Updating the primary domain affects federation trust and meeting invitations, requiring proactive partner communication. 5. Compliance and eDiscovery Integrity Archived content in Exchange Online, SharePoint, and Teams must maintain legal hold continuity and eDiscovery searchability, even after email addresses change. Reference: https://learn.microsoft.com/en-us/microsoft-365/compliance/ediscovery 6. Office 365 Apps: Identity, Activation, and Licensing Breaks Apps like Outlook, Teams, Word, Excel, and OneDrive cache user credentials and domain suffixes. Rebranding can cause: Activation failures Sign-in errors in Outlook or Teams Cached credential conflicts Strategic Solutions and Best Practices 1. Dual SMTP Strategy Add the new domain as the primary SMTP, retaining previous addresses as secondary aliases to maintain continuity, customer service, and compliance. 2. OneDrive and SharePoint Communication Plan Prepare user communication plans, support documentation, and staged URL testing before renaming SharePoint Online domains. 3. UPN and Sign-In Alignment Sequence UPN updates carefully in hybrid environments, testing Conditional Access, SSO, and MFA in staging before deployment. 4. Teams External Federation Refresh Inform external partners of domain changes, validate federation re-establishment, and update meeting templates. 5. Maintain eDiscovery Chain of Custody Document every mailbox address change. Confirm Microsoft Purview holds and content searches remain intact for both old and new identities. 6. Office 365 Apps Rebinding Strategy Communicate expectations clearly Instruct users to sign out before cutover Push credential cache clearing via script or Intune Re-authenticate apps post-UPN change Lessons Learned Rebranding is an identity transformation, not just cosmetic. Office apps can silently break; proactive reconfiguration avoids support spikes. Testing is non-negotiable. Communication reduces user friction and IT escalations. SharePoint domain renaming works with precision when following Microsoft’s official process. Conclusion Corporate domain rebranding in Microsoft 365 is a delicate balance of technical precision, compliance management, user experience preservation, and Office app continuity. Done correctly, it strengthens organizational agility and brand alignment without sacrificing trust. Cloud identity is brand identity — and managing it well is an art. About the Author Gonzalo Brown Ruiz is a Senior Microsoft 365 Engineer and Cloud Security Specialist with over 21 years of experience delivering secure, compliant, and resilient cloud environments across North America and Latin America. Specialized in Microsoft Teams, Exchange Online, OneDrive for Business, SharePoint Online, Microsoft Purview, and Entra ID.
EOP and user digest messages
I'm setting up antispam policy as I migrate to EOP. I have a pretty standard policy, everyone gets the same settings not one is special and has more relaxed or more restrictive antispam rules. However I do have only a limited group who receive user digest messages not everyone. When setting up my antispam policy I see you can apply it to users groups or all but I don't see that you can only send digested to set users\groups. Does this mean if I want a digest sent to one group only I need two policies that are basically the same (one with digest and one with not) and apply the policy with the direct to the group that receive the digest and the other policy to everyone else? If that's the cases my next question is there a way to copy an antispam policy into a new one? It will take ages to create a new one exactly the same (long story why it just does).
'$skiptoken' limit error for Microsoft Exchange online Reporting web service API
I was working on integrating MessageTrace report API as a part of my SIEM integration: https://reports.office365.com/ecp/reportingwebservice/reporting.svc/MessageTrace[?ODATA%20options] I have noticed that, whenever my $skiptoken reaches the limit 999999 , it throws the following error with 500 status code: { "odata.error": { "code": "UnknownError", "message": { "lang": "", "value": "An error has occurred on the server." } } } It was working fine for the 999998 value, but wasn't for the $skiptoken value 999999. Is there any limitations on $skiptoken value from the API itself? Also, need information, if $skiptoken value 999999 exists, for example, "odata.nextLink": "../../reportingwebservice/reporting.svc/MessageTrace?$filter=StartDate%20eq%20DateTime'2024-12-02T00%3A00%3A00Z'%20and%20EndDate%20eq%20DateTime'2024-12-02T23%3A59%3A59Z'&$skiptoken=999999" then how can we request the data from next set of events? Can someone let me know, is there any max limit from Microsoft API side or for the $skiptoken?
