Jet Mariano

Tag: Performance

  • Exchange Online Throttling Policies: Why They Exist, When to Modify Them, and How to Justify Changes

    Introduction

    Exchange Online throttling policies exist for one core reason — to keep the Microsoft 365 ecosystem healthy, stable, and resistant to abuse.
    Throttling protects the service from:

    • Excessive load
    • Misconfigured applications
    • Compromised accounts sending thousands of emails
    • Bulk operations that can degrade tenant performance

    It’s not a punishment.
    It’s Microsoft’s way of guaranteeing fairness across millions of tenants.

    But in real production environments — especially at the enterprise, hybrid, or application-integration level — default throttling limits can sometimes block legitimate business-critical operations.
    And when that happens, you must know:

    1. Why throttling exists
    2. How to detect throttling
    3. When it’s justified to modify limits
    4. How to request changes with Microsoft support

    This is one of the topics principal-level interviewers love because it shows deep operational understanding.

    Why Throttling Exists in Exchange Online

    Microsoft enforces throttling to prevent:

    1. Service Abuse

    A single compromised account can send 10,000+ spam emails within minutes.
    Throttling slows these bursts so EOP can react and block the session.

    2. Tenant Misconfigurations

    Common misconfigurations that trigger throttling:

    • Line-of-business apps sending too many messages too quickly
    • Applications reusing connections improperly
    • Legacy services using Basic Auth patterns
    • Scripts or PowerShell modules pulling data too fast

    3. System Stability

    If every tenant could push unlimited requests, the shared service collapses.
    Throttling ensures:

    • CPU fairness
    • Bandwidth fairness
    • Queue stability
    • Storage and transport efficiency

    How to Detect Throttling Events

    You will usually see:

    📌 Error Examples

    • Server Busy
    • Backoff due to throttling policy
    • TooManyConcurrentConnections
    • Exceeded message submission rate limit
    • SendAsDenied triggered by backlog saturation

    📌 Where You See These

    • Exchange message trace
    • Transport logs
    • Application logs
    • SMTP client logs
    • EOP reports
    • PowerShell scripts returning "ProcessingStopped"

    📌 Behavioral Symptoms

    • Messages stuck in Outbox
    • Applications retrying endlessly
    • High SMTP queue latency
    • Inconsistent delivery within seconds-to-minutes range

    When It Is Appropriate to Modify Exchange Online Throttling

    This is key.
    You never change throttling “because someone wants faster emails.”
    You change throttling for business justification only, such as:

    1. Application Mailbox Accounts

    These accounts often need higher:

    • MaxSendRate
    • RecipientRateLimit
    • MessageRateLimit

    Examples:

    • ERP systems
    • CRM systems
    • Manufacturing systems (Backflush, MES, D365)
    • Monitoring systems
    • Ticketing systems (ServiceNow, Jira, Zendesk)

    2. Hybrid Exchange Servers

    Hybrid servers may require adjusted:

    • PowerShell concurrency
    • EWS limits
    • MRS (Mailbox Replication Service) migration speeds

    Especially during:

    • Large cutovers
    • Fast-track migrations
    • Bulk mailbox moves

    3. Automated Services Needing High Burst Throughput

    Scenarios where default throttling causes issues:

    • Finance systems sending thousands of statements
    • HR systems sending open enrollment packets
    • Email marketing systems using authenticated SMTP
    • Daily reporting engines generating PDFs for hundreds of users

    How to Justify Throttling Changes to Microsoft Support

    This is where senior-level experience shows.

    Microsoft will not modify throttling unless you prove:

    1. Operational Need

    Explain what system is being blocked.

    2. Business Impact

    Show examples:

    • Delayed invoices
    • Delayed purchase orders
    • Delayed system alerts
    • Delayed manufacturing workflows

    3. Technical Evidence

    Provide logs showing:

    • Backoff errors
    • Submission rate failures
    • EWS throttling hits
    • Application retry loops

    4. Confirmation That It’s Not Spam

    Show the account is app credentialed, not user-driven.

    5. You Have Already Tuned the Application

    Microsoft wants evidence that:

    • Retry logic exists
    • Connection reuse is efficient
    • Burst sending is controlled

    If justified, Microsoft raises throttling for:

    Specific service accounts only
    (Never the whole tenant.)

    They may change:

    • Recipient rate limits
    • Message burst limits
    • EWS or Graph concurrency
    • PowerShell session limits

    Common Interview Question: “Why Not Remove Throttling Entirely?”

    Perfect answer:

    “Because throttling is part of Microsoft’s multi-tenant stability and security model.
    Without it, one tenant’s misconfiguration or compromised account could degrade the entire service.
    Changes should be scoped, justified, temporary, and monitored.”

    PowerShell: Checking Throttling Policy Assigned to a Mailbox

    Get-ThrottlingPolicyAssociation -Identity [email protected]

    PowerShell: View Existing Throttling Policies

    Get-ThrottlingPolicy | fl Name,MessageRateLimit,RecipientRateLimit

    PowerShell: Create a Dedicated Policy for an App Mailbox

    Set-ThrottlingPolicyAssociation -Identity [email protected] -ThrottlingPolicy AppMailboxPolicy

    Conclusion

    Throttling is not the enemy.
    It’s a guardrail.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

error: Content is protected !!