MOERA Throttle: Microsoft Caps Onmicrosoft.com Email at 100 External Recipients/Day

  • Thread Author
Microsoft is moving to strictly limit outbound email sent from the shared .onmicrosoft.com tenant namespace — commonly called MOERA (Microsoft Online Email Routing Address) — introducing a hard cap that will throttle messages sent from onmicrosoft.com addresses to 100 external recipients per organization in any 24‑hour rolling window, and rolling enforcement out in staged phases beginning with trial tenants on October 15, 2025. y Microsoft 365 tenant receives a default domain that looks like companyname.onmicrosoft.com. That domain was designed for rapid provisioning, testing, and early-stage configuration, not as a production sending identity. Over the years many organizations continued to use their onmicrosoft.com mailbox addresses in production — and attackers repeatedly abused newly created tenants that relied on the shared namespace, causing systemic reputation damage for the entire onmicrosoft.com space. Microsoft’s new policy is a direct attempt to stop that abuse and protect deliverability for legitimate senders.
This policy — whichther Exchange Online outbound and external‑recipient rate controls — is explicitly targeted at the shared onmicrosoft.com namespace. It does not replace tenant‑ or mailbox‑level rate limits already in the Exchange family of protections, but it adds a very low quota specifically for MOERA addresses to make abuse economically and operationally unattractive.

What Microsoft is changing — the​

The new MOERA throttle: the hard facts​

  • Limit: Mail sent from any address in the .onmicrosoft.com namespace will be restricted to 100 external recipients per organization per 24‑hour rolling window. Internal mail (i.e., messages delivered to recipients inside the same tenant) is not counted against this cap.
  • How recipients are counted: Recipient counts are calcun*. That means distribution lists, nested groups, and any expansion that increases the number of external recipients will count against the 100‑recipient cap. A single send to a list that expands to 200 external addresses will consume 200 recipient credits.
  • Failure mode / error code: When a tenant exceeds the MOERA cap, outgoing atcipients from onmicrosoft.com addresses will be rejected and the sender will receive a non‑delivery report (NDR) with SMTP error code 550 5.7.236 until the rolling window moves past the offending sends.
These rules are intentionally surgical: they only apply when the message is sent from onmicrosoft.com ioduction mail flows originate from verified custom domains, they are governed by the regular Exchange outbound controls rather than the MOERA 100‑recipient rule.

Rollout timeline and tenant sizes​

Microsoft is staging enforcement by tenant size (Exchange seat counts), with Message d one month before each stage. The publicized enforcement calendar begins with trials and small tenants and continues through large enterprise tenants:
  • Trial tenants: enforcement begins October 15, 2025.
  • Tenants with fewer than 3 seats: enforcement begins December 1, 2025.
  • The staged rollout continues in waves and reaches very large teats) by June 1, 2026. Administrators will receive Message Center notificati month before their tenant’s enforcement window.
Note: administrators should treat Message Center notices as authoritative timing for their tenant; missing or ignoring those notices is the most common operational failure mode.

ng this — the rationale​

Shared default domains present a classic anti‑abuse problem: creating trial tenants or temporary tenants is cheap and easy, and attackers can weaponize a fnant to send bulk spam or phishing messages with minimal upfront friction. Because the onmicrosoft.com namespace is shared, successful abuse reduces the reputation of the entire namespace and causes collateral deliverability damage to legitimate tenants that continue to use MOERA identities for production mail.
Microsoft’s MOERA throttling directly increases the operational cost and risk of using throwaway tenants for malicious campaigns, nudging organizations toward verified, company‑owned domains where administrators can maintain proper authentication and reputation controls (SPF, DKIM, DMARC). The policy also reduces the noise security teams face from external alerts triggered by onmicrosoft.com‑based abuse.

Who is affected — practical impact​

Beneficiaries​

  • Organizations already using a verified custom domain for production mail should see minimal direct impact, provided their outbound mail does not use onmicrosoft a custom domain enables full control over DKIM/SPF/DMARC and avoids the MOERA quota.

At‑risk groups​

  • Small businesses, nonprofits, hobbyist projects, and trial tenants that never set up a custom domain and rely on onmicrosoft.com for day‑to‑day sending will be directly impacted. Once a tenant using MOERA identities exceeds 100 n 24 hours, outbound messages to external recipients will bounce until the quota window clears.
  • Applications, automation, and third‑party services that are hard‑coded to send from @yourtenant.onmicrosoft.com addresses (service accounts, monitoring alerts, support ticket emailers, embedded OTP systems) will fail if they send to more than 100 external recipients i Administrators who use distribution lists, nested groups, or connectors that expand recipients post‑send are particularly vulnerable because expansion counts toward the quota and can unexpectedly exhaust the 100 recipients.

Hybrid and edge cases​

Organizations with hybrid setups, leomplex routing should be careful: the MOERA policy counts recipients destined to domains not on the tenant’s accepted domain list, regardless of the routing path. Hybrid mail flow that ultimately delivers externally can be counteuld test flows and review connector behavior to determine how expansion and routing are accounted for.

Operational consequences and migration pain points​

Shifting away from onmicrosoft.com in production is straightforward in principle but touches many moving parts. Expect the following operational work:
  • Primary SMTP / UPN changes: Updating mailboxes so that a custom domain is the primary SMTP address may require alignes (UPN). Changing UPNs can force re‑authentication on devices, affect OneDrive profiles, and require users to update credentials in apps. Plan for friction and a post‑cutover support window.
  • Applications & connectors: Scripts, SMTP connectors, third‑party services, and in‑app mailers that send from onmicrosoft.com must be reconfigured to use the custom domain. Where reconfiguration isn’t possible, route those flows through authenticated connectors or a dedicated transactional email service.
  • Authentication and deliverability: lity when moving to a new domain, publish and verify SPF, enable DKIM signing for the domain, and implement DMARC in a phased manner (p=none → quarantine → reject). Leaving these incomplete will create deliverability issues after migration.
  • Distribution list auditing: Because recipients are c a single send to a complex distribution list can consume the entire 100‑recipient quota. Split lists, move external recipients into a marketing platform, or switch high‑volume sends to an ESP.

A practical 30/60/90 migration plan​

Organizations should treat MOERA migration as a short, discrete program. Below administrators can adopt immediately.
  • 0–30 days (Immediate)
  • Audit all senders that use @*.onmicrosoft.com addresses: mailboxes, shared mailboxes, service accounts, connectors, scheduled tasks, and applications. Use Exchange Admin Center and PowerShell reports to locnal senders.
  • Acquire and validate a custom domain in Microsoft 365 / Entra. Add the domain and complete DNS verification records.
  • Communicate the plan to stakeholders and schedule pilot windows.
  • 30–60 days (Plan & Test)
  • Pilot migration with a representative set of users and automation. Update primary SMTP addresses and, where needed, align UPNs to avoid login confusion. Test OneDrive/Teams sign‑in behavior post‑change.
  • Pub DKIM for the custom domain; start DMARC in p=none and monitor aggregate reports for anomalies.
  • Reconfigure connectorices to use the custom domain or authenticated relay.
  • 60–90+ days ( - Complete the migration and retain onmicrosoft.com addresses only as secondary aliases when necessary for legacy logins.
  • Monitor Exchange Admin Center, Message Center, and DMARC reports for deliverability issues. Consider moving hids to a specialist ESP or Azure Communication Services for Email.

Alternatives for legitimate high‑volume sending​

Notould or needs to send high volumes from Exchange Online mailboxes. Consider dedicated or purpose‑built pommunication Services (Email):** Microsoft’s recommended path for high‑volume transactional and B2C messaging when you need first‑party Microsoft platform support.
  • Dedicated ESPs (SendGrid, Mailgun, Amazon SES, SparkPost, etc.): These services provide reputation management, deliverability tooling, and analytics optimized for marketing and transactional vol Online High Volume Email (HVE):** For internal bulk and large‑scale internal message needs, HVE preview features provide a mailbox type and reporting that are better suited to internal high‑throughput use cases; it is not a workaround for MOERA external sending restrictions. HVE is designed for internal messaging with integrated reporting and security controls.

gths and weaknesses of Microsoft’s approach​

Strengths​

  • Directly targets the abuse vector. By throttling the shared namespace, Microsoft raises the cost of using throwaway tenants for spam and phishie systemic reputation damage for legitimate senders.
  • Encourages best practice. The policy nudges tenants to use verified custom domains and implement DKIM/SPF/DMARC, improving long‑term deliverability and brand trust.
  • Surgical enforcement. The cap applies only to MOERA identities and leaves normal custom‑domain sending governed by existing controls. This reducn properly configured organizations.

Weaknesses and operational risks​

  • Collateral disruption for small tenants. Organizations that never set up a custom domain — including legitimate small businesses and nonprofits — risk sudden external mail failures if they exceed 100 external recipients. This is a r organizations with constrained IT capacity.
  • Migration complexity. Changing primary SMTP addresses and UPNs across many users and systems is a nontrivial churn events, hard‑coded service addresses, and overlooked automation are the most common causes of post‑migration outages.
  • Edge cases in counting and expansion. Because the quota counts recipients after expansion ate across sends, seemingly innocuous sends (to distribution lists or nested groups) can unexpectedly exhaust the quota. Administrators must audit and remediate list composition.

Recommended controls, checks, and quick wins for administrators​

  • Run an inventory script (PowerShell) to list mailboxes, service accounts, connectors, an.onmicrosoft.com addresses and log their outbound external recipient counts. Prioritize remediation by external send volume.
  • Preserve onmicrosoft.com aliases as secondary addresses during cutover to reduce login breakage, migrating the primary SMTP to the custen aligning UPNs where required.
  • Audit distribution groups for external membership, split lists that include many external recipients, and move marketing lists to an ESP.
  • For automated flows that cannot be reconfigured to use a custom domain, route them through an authenticated SMTP connectorervice to avoid MOERA throttling.
  • Monitor Message Center and set up notification alerts for tenant‑targeted notices so the IT team never misses the one‑month pre‑notice Microsoft will send before enforcement for your tenant size.

Caveats and unverifiable claims​

The available reporting and communi consistent picture of Microsoft’s intentions and the technical specifics of the MOERA throttle. The enforcement dates and staged schedule cited above come from the same public advisories and ctured in the available briefings, but tenants should treat their Message Center notifications as the definitive source for their tenant’s enf Administrators should not assume the global rollout schedule is immutable; Microsoft has historically adjusted enforcement windows as they refine telemetry and operational readineeviations to the schedule, Microsoft will publish updates in Message Center and on the Microsoft Tech Community channels.

Final assessment — what this means for email deliverability and enticrosoft’s MOERA throttling is a targeted, ecosystem‑level intervention designed to stop a persistent abuse vector and protect deliverability for the majority of enterprises that already use custom domains. For responsibly managed tenants, the change should be benign; for those still using onmicrosoft.com addresses for production messages, the change is consequential and requires immediate action.​

The policy’s strength is that it applies a simple, low cap to a shared namespace that has chronically attracted abuse. The risk is concentrated on small tenants and the numerous automation paths that organizations historically used on the default MOERA identity. The real value for administrators is that this change provides a clear deadline for completing a migration to a verified domain and implementing robust authentication practices — actions that improve security and deliverability for the long term.
Administrators should treat MOERA migration as a short, high‑priority program: inventory senders now, validate a custom domain, migrate primary SMTP addresses in a staged manner, and monitor DMARC and the Exchange Admin Center. Where high‑volume external sending is needed, move that traffic to a purpose‑built platform rather than trying to bend Exchange Online’s mailbox model around bulk use cases.
Microsoft’s message is unambiguous: treat onmicrosoft.com as a testing and tenancy namespace, not a production sending domain. The timing and specifics of Microsoft’s MOERA throttling give administrators a clear window to act — and the cost of inaction is immediate and measurable: bounced outbound mail and disrupted business processes.
Source: Petri IT Knowledgebase Microsoft Restricts onmicrosoft.com Email Use in Exchange Online
 
Click to expand...
Microsoft’s decision to throttle email sent from the shared onmicrosoft.com tenant namespace — what engineers call MOERA (Microsoft Online Email Routing Address) — is a decisive move to curb abuse, protect shared reputation, and force tenants to adopt branded custom domains for production sending. (techcommunity.microsoft.com)

Background / Overview​

Every Microsoft 365 tenant is provisioned with a default onmicrosoft.com domain (and regional variants such as onmicrosoft.de). That domain has long served as a convenience for rapid provisioning, testing, and early-stage configuration. Over time however, many organizations left MOERA addresses as active sending identities — and attackers repeatedly weaponized freshly created tenants to blast spam and phishing, damaging the shared onmicrosoft.com reputation for everyone. Microsoft’s new policy formally restricts MOERA usage for regular external sending and introduces a 100 external recipients per organization per 24‑hour rolling window cap for messages originating from onmicrosoft.com addresses. (techcommunity.microsoft.com) (office365itpros.com)
This article explains the technical specifics, rollout timeline, operational impacts, migration steps, detection and reporting guidance, and a measured risk/benefit analysis for administrators, MSPs, and security teams who must act before enforcement begins for their tenant.

What Microsoft is changing — the technical specifics​

The MOERA throttle: the hard facts​

  • Throttle: Mail sent from any address in the onmicrosoft.com namespace will be limited to 100 external recipients per organization per 24‑hour rolling window. Internal messages (delivered within the tenant’s accepted domains) are not counted. (techcommunity.microsoft.com)
  • How recipients are counted: Recipients are counted after expansion. Distribution lists and nested groups that expand to include external addresses will increment the count by their expanded external-member total. A single send to a list that expands to 200 external recipients consumes 200 credits. (techcommunity.microsoft.com)
  • Failure mode: Attempted sends to external recipients beyond the cap are rejected and result in NDRs (non‑delivery reports) with SMTP error 550 5.7.236 while the tenant remains throttled. (techcommunity.microsoft.com)
  • Scope: The throttle applies only when the original message is sent from an onmicrosoft.com MOERA address. Sending from a verified custom domain remains subject to the regular Exchange outbound/tenant limits (ERR/TERRL/MERRL) rather than the MOERA 100‑recipient rule. (techcommunity.microsoft.com)
These rules are intentionally surgical: they aim to sever the easy path attackers used — namely cheap throwaway tenants using a shared default domain — while preserving normal flows that originate from tenant-owned custom domains.

Where this fits with other Exchange limits​

Microsoft has been rolling out several outbound controls in Exchange Online in recent years: per‑mailbox external recipient limits (MERRL/ERR) and tenant‑wide external recipient limits (TERRL/TERR). The MOERA throttle is narrower: it’s a low, tenant‑level quota that applies only to the shared onmicrosoft.com namespace and is much lower than the mailbox/tenant thresholds used for normal custom-domain sending. Administrators who already send from custom domains will largely be unaffected by the MOERA rule, provided all external sending uses the custom domain identities. (practical365.com) (techcommunity.microsoft.com)

Rollout timeline — phased by tenant size​

Microsoft is enforcing the throttle in stages based on Exchange seat counts (number of Exchange seats/licenses in a tenant). The published schedule (as announced) is:
Microsoft will send Message Center notifications one month before enforcement for each stage to tenants meeting the seat‑count criteria. Administrators must monitor the Message Center; relying on passive awareness is a common cause of operational surprise. (techcommunity.microsoft.com)

Why Microsoft is taking this step — rationale and expected benefits​

  • Directly targets the attack vector. Trial tenants and newly provisioned tenants were a cheap, repeatable resource for attackers to send bulk spam and phishing — which rapidly degraded the shared onmicrosoft.com reputation. Capping external delivery from that shared namespace raises the operational cost of abuse and reduces the incentive to use throwaway tenants. (techcommunity.microsoft.com)
  • Encourages best practice. Requiring tenant owners to use verified custom domains for production external mail nudges organizations toward proper domain ownership, DNS controls, and authentication setup (SPF, DKIM, DMARC), all of which improve long‑term deliverability and security posture. (office365itpros.com)
  • Improves deliverability for legitimate senders. Less reputation bleed from rogue tenants should reduce false positives and improve inbox placement for tenants that follow best practices. (practical365.com)
These are defensible outcomes from an anti‑abuse perspective — the policy changes the economics of abuse while nudging legitimate tenants into cleaner configurations.

Operational impact: who will be affected and how​

Most-impacted groups​

  • Small businesses, trial tenants, and hobbyist tenants that never configured a custom domain and treat their onmicrosoft.com address as primary. Once the tenant sends to more than 100 external recipients within 24 hours, further external sends from MOERA addresses will be rejected. (techcommunity.microsoft.com)
  • Automation, SaaS integrations, monitoring alerts, and third‑party applications that are configured to send from onmicrosoft.com addresses or have hard‑coded MOERA identities. These may silently fail unless reconfigured.
  • Tenants using MOERA as the default domain for features like Sender Rewriting Scheme (SRS) fallback, Bookings invites, or product notifications — those flows must be re‑pointed to a custom domain to avoid being counted as MOERA originators. (techcommunity.microsoft.com)

Likely unaffected or minimally affected groups​

  • Organizations that already send all external mail from verified custom domains and have properly configured SPF/DKIM/DMARC. Production sending that uses a custom domain will be governed by the normal Exchange outbound limits, not the MOERA cap. (techcommunity.microsoft.com)

Edge cases and hybrid complexities​

  • Distribution lists and expansion: Because recipient expansion counts after expansion, a single seemingly small send to a distribution list containing external recipients can exhaust the 100‑recipient cap unexpectedly. Audit all lists that include external members. (techcommunity.microsoft.com)
  • Hybrid routing and mail.onmicrosoft.com: Some hybrid or complex routing configurations use MOERA-style addresses (for example mail.onmicrosoft.com). In many cases these will not be throttled so long as they are not used as original traffic senders, but administrators should test OOF and automated reply scenarios as they can create unexpected external sends. (techcommunity.microsoft.com)
  • Federated domains: Federated domains cannot be set as the tenant default domain; customers that use federation (AD FS) must add a non‑federated custom domain to act as the default. Changing default domains can have downstream authentication implications. (techcommunity.microsoft.com)

Concrete migration checklist (30/60/90 day playbook)​

0–30 days (Immediate triage)
  • Audit current senders to external recipients. Use Exchange Admin Center reports, Message Trace, and PowerShell to identify senders (mailboxes, connectors, applications) sending from onmicrosoft.com addresses. Place a wildcard on the sender field when running Message Trace to find MOERA-originated traffic.
  • Identify hard-coded addresses. Catalog all integrations, monitoring systems, ticketing tools, and scripts that may send as onmicrosoft.com. Prioritize those that send to external recipients.
  • Purchase and verify a custom domain. Buy a domain from a registrar, add it to Microsoft 365/Entra, and validate ownership in the admin center. Prepare DNS management to publish SPF, DKIM, and DMARC records. (techcommunity.microsoft.com)
30–60 days (Plan & test)
  • Add aliases and pilot users. Add custom-domain aliases to a pilot set of mailboxes and set the custom alias as Primary SMTP for pilot accounts. Test sending/receiving, DKIM signing, and DMARC reporting. Communicate to pilot users about possible sign‑in or credential changes if you align the UPN with the new primary SMTP. (techcommunity.microsoft.com)
  • Reconfigure connectors and apps. Update SMTP relays, third‑party senders, and webhooks to use the custom domain or route them through a transactional provider. Validate end‑to‑end delivery and authentication (SPF/DKIM).
60–90+ days (Execute & monitor)
  • Perform staged cutover. Migrate remaining users in waves, preserve MOERA addresses as secondary aliases as needed for legacy login compatibility, and monitor for bounced automation. (office365itpros.com)
  • Lock and observe. Monitor DMARC reports, EAC sender reports, and Message Center alerts. Check for NDRs with 550 5.7.236 which indicate a tenant has hit the MOERA cap. Adjust workflows or split lists if expansion unexpectedly consumes the quota. (techcommunity.microsoft.com)
Practical tips:
  • Keep MOERA addresses as secondary aliases during transition to avoid breaking legacy service accounts that rely on the old username format. (office365itpros.com)
  • If your tenant must send high volumes of external mail (transactional, marketing), move those flows to a dedicated Email Service Provider (SendGrid, Mailgun, Amazon SES, SparkPost) or to Azure’s high‑volume solutions rather than trying to work around Exchange limits.

Detection, diagnostics, and the Message Trace play​

  • Message Trace: Use Message Trace in Exchange Admin Center with a wildcard sender (e.g., *@yourtenant.onmicrosoft.com) to list outbound traffic originating from MOERA addresses. Filter by recipient domain to remove internal traffic. This trace helps identify flows that will be impacted when enforcement starts.
  • NDR 550 5.7.236: When senders encounter the MOERA throttle, the transport stack will generate NDRs with this code. Search mail flow logs and quarantine reports for this specific code to spot throttling events. (techcommunity.microsoft.com)
  • PowerShell: Leverage Get-MessageTrace and Get-MessageTraceDetail in PowerShell for scripted audits. For large tenants, automated scripts can produce lists of suspect senders and list memberships that include external recipients.

Risk assessment — strengths and potential downsides​

Strengths / upside​

  • Reduces systemic abuse. The throttle directly increases the cost of using throwaway tenants for spam, and therefore lowers the frequency of distributed abuse across the onmicrosoft.com namespace. (techcommunity.microsoft.com)
  • Improves deliverability for legitimate tenants. Less reputation noise should translate into higher inbox placement for tenants that adopt proper domain and authentication controls. (practical365.com)
  • Nudges operational hygiene. Organizations are re‑forced to adopt custom domains and publish SPF/DKIM/DMARC, which benefits long‑term security and trust.

Risks / operational challenges​

  • Collateral disruption. Small tenants, trials, and organizations with poor tenant hygiene may see business‑critical messages bounce if they rely on MOERA addresses for notifications, alerts, or customer‑facing messages.
  • Migration friction. Changing primary SMTP addresses and aligning UPNs can impact OneDrive links, cached credentials, device authentications, and application logins. These impacts require coordinated change windows and user communications.
  • Hidden dependencies. Hard‑coded addresses in SaaS products, monitoring systems, or third‑party vendor configurations may break silently. A comprehensive discovery phase is essential.
  • Timing & communication risk. The staged rollout relies on Message Center notices; tenants that do not actively monitor Message Center risk being surprised by enforcement. (techcommunity.microsoft.com)
Caveat: telemetry and edge behavior around expansion counting, connector handling, and hybrid routing can vary by tenant configuration; administrators should treat the published 100‑recipient figure as a strict enforcement value but verify how their specific connectors and routes count recipients via Message Trace before enforcement. Where behavior cannot be validated from tenant logs, treat considerations as potentially impactful and test in a safe environment.

Recommended policies and defensive controls for IT teams​

  • Policy: Mandate a verified custom domain for any mailbox that will ever send external mail. Enforce this for service accounts and automation. (office365itpros.com)
  • Inventory: Maintain an up‑to‑date inventory of senders, connectors, and applications that can originate email. Make that inventory part of onboarding and change control.
  • Authentication posture: Ensure SPF, DKIM, and DMARC are configured for custom domains and that DMARC reports are monitored and triaged. Use gradual DMARC enforcement (p=none → quarantine → reject) as you stabilize sending. (office365itpros.com)
  • Escalation & runbooks: Create runbooks to respond to NDRs with 550 5.7.236, including steps to: (a) determine whether the sender used an onmicrosoft.com address, (b) identify the offending sends via Message Trace, and (c) reconfigure the sending identity to a custom domain or route traffic through an ESP. (techcommunity.microsoft.com)

Checklist for service providers and MSPs​

  • Identify customers that still use onmicrosoft.com as a primary. Prioritize those with upcoming enforcement dates (trial tenants and tiny tenants first). (techcommunity.microsoft.com)
  • Offer migration packages: domain purchase guidance, DNS configuration, DKIM/SPF/DMARC setup, and alias/UPN mapping.
  • Test integrations: run a discovery for hard‑coded senders, verify connectors and hybrid routes, and run simulated sends to measure recipient counting behavior.

Final assessment — practical implications for email deliverability and reputation​

Microsoft’s MOERA throttling is a surgical but consequential policy intended to protect the wider ecosystem from repeated abuse that erodes shared namespace reputation. For administrators who have already adopted best practice — sending externally from tenant‑owned custom domains with appropriate SPF/DKIM/DMARC — the change should be transparent. For the many tenants who still rely on MOERA addresses for notifications, business automation, or user accounts, the change is disruptive but avoidable if action is taken now. (techcommunity.microsoft.com) (office365itpros.com)
The policy also aligns with broader industry guidance: email sending should be tied to domains you own, authenticated with DNS controls, and routed through purpose‑fit platforms for high‑volume or transactional messaging. Attempting to treat Exchange mailboxes as a bulk‑mailing platform is increasingly untenable given Microsoft’s trajectory of tenant and mailbox rate controls (TERRL, MERRL, ERR) and this targeted MOERA cap. (practical365.com, techcommunity.microsoft.com)

Key action summary (immediate priorities)​

  • Audit outbound senders and connectors for MOERA usage.
  • Purchase/verify a custom domain and publish SPF/DKIM/DMARC for it. (techcommunity.microsoft.com)
  • Add aliases and switch primary SMTP addresses for mailboxes that send externally (pilot then roll out). (office365itpros.com)
  • Reconfigure automation, SaaS integrations, and system notifications to use the custom domain or a transactional ESP.
  • Monitor Message Center and Message Trace for NDR 550 5.7.236 events and distribution-list expansions. (techcommunity.microsoft.com)
Microsoft’s MOERA throttle is an invitation to tidy tenant hygiene, adopt verified branding, and make a clean break with legacy convenience that has long undermined shared reputation. The technical constraints are clear, the timeline is public, and the remediation path is straightforward — though operationally nontrivial for some tenants. Administrators who take the migration playbook seriously now will avoid the day‑of surprises and emerge with more robust, consistent, and deliverable email workflows. (techcommunity.microsoft.com, office365itpros.com)
Source: Microsoft Exchange Team Blog Limiting Onmicrosoft Domain Usage for Sending Emails | Microsoft Community Hub
 
You must log in or register to reply here.

Similar threads

  • Featured
  • Article Article
MOERA Throttle: 100 External Recipients per 24h and Migration to Custom Domains
Replies
1
Views
124
ChatGPT
  • Featured
  • Article Article
MOERA Outbound Cap: 100 External Recipients per 24h for onmicrosoft.com
Replies
0
Views
166
ChatGPT
  • Featured
  • Article Article
MOERA Throttling: Migrate from onmicrosoft.com to Your Custom Domain Now
Replies
0
Views
171
ChatGPT