Unauthorized: You don't have permission to access this page or perform this action
I frequently encounter an 'Unauthorized' error when attempting to manage Distribution Lists in the Exchange Admin Center, even while logged in with Global Administrator or Exchange Online Administrator privileges. Is this a known widespread issue, or is it specific to the configuration of these individual tenants?
How to resolve Junk email validation error
I'm attempting to add an email address to all users mailboxes using Set-mailboxJunkEmailConfiguration. The command fails and returns an email address as the error (see below). I've dumped the three lists contained in the record and the address displayed in the error isn't in any of them. The lists are TrustedSendersAndDomains, TrustedRecipientsAndDomains, and BlockedSendersAndDomains. The command I'm running is: set-mailboxjunkemailconfiguration -identity email address removed for privacy reasons -TrustedSendersAndDomains @{Remove="email address removed for privacy reasons"} The error returns: Set-MailboxJunkEmailConfiguration: |Microsoft.Exchange.Data.Storage.JunkEmailValidationException|Junk email validation error. Value: mailto:email address removed for privacy reasons. Note: all email addresses have been changed. The error happens on a handful of accounts and the value is unique to each user. This error happens on approx. 20 of 5100 mailboxes. Any ideas?HVE for Microsoft 365: When to Use It, When Not To, and Who Should Be Allowed to Send at Scale
Microsoft recently announced the General Availability of High Volume Email for Microsoft 365, also known as HVE, in Exchange Online. This is an important and long-awaited capability for organizations that need to send large volumes of internal email from applications, devices, or line-of-business systems without using regular user mailboxes as bulk-sending engines. But HVE should not be misunderstood. It does not mean that every mailbox in Exchange Online should now be used for mass email. It does not mean Exchange Online has become a general-purpose marketing platform. And it does not remove the need for proper outbound email governance. Why HVE Matters For years, many organizations have used regular Exchange Online mailboxes, shared mailboxes, or service accounts to send automated messages from applications, scanners, monitoring platforms, ticketing platforms, and custom business applications. That approach creates several problems. Standard mailboxes are designed for human and business communication, not for sustained high-volume automated traffic. Exchange Online has recipient limits, message rate limits, outbound spam protections, and tenant-level controls to protect the service and reduce abuse. HVE introduces a more appropriate model for specific high-volume scenarios. Instead of using a normal mailbox for automated traffic, organizations can create dedicated HVE accounts and use specific SMTP endpoints, admin controls, reporting, and governance for approved high-volume internal messaging scenarios. What HVE Is Designed For HVE is designed for automated, operational, and transactional messaging at scale, primarily for internal recipients within the tenant. Examples include: Internal application notifications. Line-of-business system messages. Device-generated messages. Operational alerts. Security advisories. Internal workflow communications. Monitoring platform alerts. IT service notifications. Large-scale internal announcements generated by systems. This is especially relevant when the organization needs to send messages at scale but still wants to keep the workload within Microsoft 365 governance and Exchange Online mail flow. In practical terms, HVE is useful when the sender is not a human user, but a controlled business system. What HVE Is Not HVE is not a replacement for marketing platforms. HVE is not a general-purpose internet bulk email engine. HVE is not a way to bypass Exchange Online sending limits for external campaigns. HVE is not the correct platform for newsletters, promotional campaigns, large-scale customer communication, or high-volume external transactional email. For external transactional, marketing, or customer-facing bulk email, organizations should evaluate platforms designed for that purpose, such as Azure Communication Services Email, SendGrid, Amazon SES, Mailchimp, Brevo, or another specialized delivery platform. When to Use HVE Use HVE when the workload matches these characteristics: The sender is an application, device, service, or business system. The recipients are primarily internal users in the Microsoft 365 tenant. The volume is higher than what should be sent from a standard mailbox. The workload is operational, automated, or transactional. The organization needs centralized Microsoft 365 administration and reporting. The organization wants to avoid impacting user mailbox sending limits. The use case is approved, documented, monitored, and governed. Good examples: A security platform sending internal security advisories. A monitoring system sending infrastructure alerts to internal teams. A business workflow system sending high-volume approval or status notifications. An IT service platform sending internal notifications. A service management platform sending ticket updates to internal users. A device management system sending operational messages to internal teams. When Not to Use HVE Do not use HVE when the workload is external bulk email. Avoid HVE for: Marketing campaigns. Newsletters to customers. Promotional email. Mass external invitations. External transactional email at scale. Customer invoices and receipts in high volume. OTP or password reset flows for external users. External portal notifications. Any workload where deliverability, bounce handling, reputation management, unsubscribe handling, analytics, or customer consent management are required. Those workloads require a platform designed for external delivery, reputation management, suppression lists, opt-out, tracking, bounce handling, and compliance. Who Should Be Allowed to Use HVE HVE should not be enabled casually for every team or every application. It should be treated as a controlled platform capability. Recommended eligible senders: Approved line-of-business applications. Corporate systems owned by IT, Security, Operations, Facilities, or Service Management teams. Managed devices or services with a clear business purpose. Internal platforms that send operational messages to employees. Applications with documented ownership, authentication, monitoring, and expected volume. Recommended non-eligible senders: Normal users. Shared mailboxes used by humans. Marketing teams sending to external audiences. Unmanaged scripts. Legacy systems with no owner. Applications with unknown volume. Systems that send to external recipients at scale. Any application using HVE just to avoid standard mailbox limits. The core principle is simple: HVE should be enabled for workloads, not for convenience. Governance Model Before enabling HVE, organizations should define a governance model. At minimum, each HVE account should have: A named business owner. A technical owner. A documented purpose. Expected daily and monthly volume. Recipient scope. Authentication method. Monitoring process. Incident response path. Decommissioning criteria. Review frequency. HVE accounts should not become invisible service accounts that nobody owns. They should be treated as privileged communication identities. Security and Authentication HVE supports OAuth authentication, and Microsoft provides guidance for restricting OAuth authentication to specific Microsoft Entra ID applications. This is important because organizations should avoid broad, uncontrolled access. They should restrict which applications can send through each HVE account, monitor usage, and separate workloads by purpose. For example: One HVE account for security alerts. One HVE account for monitoring systems. One HVE account for IT service notifications. One HVE account for internal operational communications. This separation improves visibility, investigation, accountability, and risk containment. HVE vs Standard Exchange Online Mailboxes A standard Exchange Online mailbox should be used for normal human communication. A shared mailbox should be used for collaborative business processes. An HVE account should be used for approved high-volume internal system email. A dedicated external delivery platform should be used for marketing, bulk external communication, or high-volume transactional email. Scenario Recommended Platform Human business email Exchange Online mailbox Team or department mailbox Shared mailbox Low-volume application notifications Standard Exchange Online, if approved High-volume internal system notifications HVE Internal operational alerts at scale HVE Marketing campaigns Marketing platform External transactional email Transactional email service Customer newsletters Marketing automation platform OTP/password reset for external users Dedicated transactional platform External bulk email Dedicated bulk email provider HVE and the Mailbox External Recipient Rate Limit Cancellation Microsoft also announced that the Mailbox External Recipient Rate Limit in Exchange Online was cancelled indefinitely. However, that cancellation should not be interpreted as permission to use Exchange Online for uncontrolled bulk sending. Microsoft was clear that other limits remain unchanged, including the existing Recipient Rate Limit and the Tenant-level External Recipient Rate Limit. That distinction is important. The cancellation of one mailbox-level external recipient limit does not remove the need for proper architecture. Exchange Online still has service limits. Outbound spam controls still apply. Tenant-level protections still matter. And HVE is still not a marketing engine. Practical Architecture Decision Before enabling HVE, ask these questions: Who is sending? Is the sender a human, shared mailbox, application, or device? Who are the recipients? Are they internal or external? What is the expected volume? Is the workload operational, transactional, promotional, or human communication? Does the business need Microsoft 365 mail flow and governance? Does the use case require bounce handling, unsubscribe, tracking, or reputation management? Is the application properly authenticated and monitored? Who owns the account? Who approves the sending pattern? Who responds if the account is abused? If the workload is internal, automated, high-volume, and business-approved, HVE may be the right answer. If the workload is external, promotional, customer-facing, or marketing-driven, use a dedicated email delivery platform. Recommended Enablement Approach Organizations should enable HVE in phases. First, identify existing systems currently using user mailboxes, shared mailboxes, or SMTP AUTH for automated sending. Second, classify each workload as internal, external, operational, transactional, marketing, or human communication. Third, migrate only approved internal high-volume workloads to HVE. Fourth, move external high-volume workloads to dedicated email delivery platforms. Fifth, monitor usage and review HVE accounts regularly. This avoids turning HVE into another uncontrolled sending layer. Conclusion High Volume Email for Microsoft 365 is an important addition to Exchange Online. It gives organizations a native way to support high-volume internal system messaging without using standard mailboxes for automated high-volume traffic. But HVE is not a free pass for bulk email. It is not a marketing platform. It is not a replacement for transactional email services. And it should not be enabled for every mailbox or every application. The right approach is workload classification. Use Exchange Online for corporate communication. Use HVE for approved high-volume internal system messaging. Use dedicated platforms for external bulk, marketing, and transactional email. The question is not only: “Can this system send email through Microsoft 365?” The better architectural question is: “What type of email is this, who is the audience, and what is the correct platform for this workload?” That is where proper email architecture begins.
550 5.7.705 Tenant Email Block 55+ Hours - Support Unresolved
Our M365 tenant (labaradorpake.onmicrosoft.com) has been blocked from sending outbound email for over 55 hours with error 550 5.7.705 Access denied, tenant has exceeded threshold. Despite multiple support tickets and promises of 24-hour resolution, the block remains active. **Error Details:** - NDR: 550 5.7.705 Access denied, tenant has exceeded threshold - Scope: External outbound email only is blocked; internal tenant-to-tenant email works fine - Microsoft Defender Restricted Entities page shows 0 restricted users — the block is at tenant level, NOT user level - No transport rules exist that could be blocking outbound - No alerts in Exchange Admin Center **Timeline:** - June 19: Support ticket #2606190040005588 created, agent Manisha confirmed remediation complete and promised block would be lifted within 24 hours - June 21 (55+ hours later): Block STILL ACTIVE. Manisha has not responded to follow-ups. - June 21: Created 2nd ticket #2606210040000778, assigned to agent Odunayo — no action taken - June 21: Created 3rd ticket #2606210040000844 with phone callback request — no callback received yet **What we have tried:** 1. Three Microsoft support tickets (all Sev C) 2. Escalation emails to agent, tech lead, team manager (all bounce due to tenant block preventing outbound email) 3. Support Assistant chat bot — cannot escalate to human agents 4. Azure Portal support — No Access for this tenant tier 5. getsupport.microsoft.com — No Access 6. Microsoft Learn Q&A post: https://learn.microsoft.com/en-us/answers/questions/5926147 7. Phone callback requested on 3rd ticket — still waiting **Critical Impact:** The tenant cannot send ANY external email. All outbound messages to external recipients bounce with 550 5.7.705. This is a complete business email outage that has persisted for over 55 hours despite Microsoft support confirming remediation was complete. Has anyone experienced a similar tenant-level block (550 5.7.705) that took this long to resolve? What escalation paths actually work when support agents are unresponsive? Any advice on getting this block lifted urgently would be greatly appreciated. Cross-posted from Microsoft Learn Q&A: https://learn.microsoft.com/en-us/answers/questions/5926147Exchange 2010 to Microsoft 365 Migration – Recommended Approach and Tools
I’m looking for guidance on migrating Exchange 2010 (on-premises) to Microsoft 365 / Office 365. Is a direct migration from Exchange 2010 supported, or is an intermediate hop (such as upgrading Exchange or setting up a hybrid configuration) required? Additionally, could you please recommend any reliable tools that can help with this migration? I also have a few PST files that need to be migrated as part of the process. I’d appreciate insights on best practices, common challenges, and lessons learned from real-world migrations. Thanks in advance for your help.
Send admin notifications on x number of messages from an email address
Hi, We're having a problem with a repeat spam/phishing offender that recycles email addresses from a particular domain. Because the email address is new it hasn't had a chance to be picked up by blacklists, so it doesn't get picked up as spam. We can't block on content, subject or sender because it all changes so for these campaigns we're relying on user reports to give us the heads up. We also can't block the domain because we receive legitimate email from the domain also. I'd like to change this so we can hit them before users notice and possibly whilst the spam campaign is in flight but I'm unsure as to how to go about it. Is there a rule or other setting I can configure which sends notifications to specific e-mail addresses if, say 100 emails were received from any email address (or from a specific domain?) within an hour, or 5 hours? I don't see how I can configure such a rule in mailflow rules so I'm guessing this might be somewhere else. There's an element of us likely being falsely alerted to marketing campaigns, but hopefully it's configurable enough that we can limit it down to only applying this against a specific sender domain, or adding a new custom mailflow rule which will lower the likelihood of false positives. Many thanks, - LswardTenant-to-Tenant Migration with Orchestrator – Technical Overview (Microsoft 365 | Preview)
Tenant-to-tenant migration with Orchestrator in Microsoft 365 introduces a native, API-driven, and highly validated approach for cross-tenant migrations. It is designed for enterprise scenarios where sequencing, dependencies, and governance are critical. Note: This capability is currently in preview. Features and behavior may change before GA. Architecture and execution model Migration is executed through batches (jobs) managed via Microsoft Graph (Beta) User-level execution: one user failing validation does not block others in the same batch Mandatory Standalone Validation before migration submission Date-driven cutover using completeAfterDateTime Supported workloads (actual scope) Exchange Online Microsoft Teams ODSP (OneDrive for Business) Important clarification on SharePoint Orchestrator does not migrate shared SharePoint content such as Team sites, Channel sites, or collaboration sites. The ODSP workload covers personal user data (OneDrive) only. SharePoint team/workload sites remain out of scope and require separate tooling or processes. Critical prerequisites Identity Mapping (CTIM) is mandatory and must remain stable during migration Target users must not have Exchange mailboxes or OneDrive sites provisioned before migration Licenses must be assigned only after Identity Mapping (ExchangeGuid stamping) Migration apps and service principals (Teams, Meetings, CTMS) must be correctly provisioned Organization Relationships and Migration Endpoints must be in place Exchange autoforwarding must be enabled for Meetings migration Validation and lifecycle Standalone Validation acts as a full “what-if” check Key states include: Cancellation or user removal is possible only before cutover Post-migration cleanup After completion, tenants must be returned to a non-migration state: Remove Identity Mapping data Remove Organization Relationships Remove Migration Endpoints Revoke migration app permissions and service principals Decide whether to retain or remove MailUsers in the source tenant Skipping cleanup leaves the tenant in an exception state. When this approach fits Mergers and acquisitions Divestitures and tenant splits Regulated environments requiring strict control Scenarios where dependency-aware sequencing matters more than speed Technical conclusion Orchestrator is not a one-click solution. It delivers native orchestration, deep validation, and predictable execution when Identity Mapping, licensing order, and scope boundaries are fully understood. For experienced administrators and architects, it represents a major step forward in tenant-to-tenant migrations within Microsoft 365, even while still in preview.Exchange Hybrid Configuration Wizard - Error 1603 - Connector registration failed
Did any of you encounter this error while installing hcw on an exchange server? Here is the event viewer error details: Connector registration failed: Make sure you are a Global Administrator of your Active Directory to register the Connector. Error: '"The registration request was denied. "'
