What it does

Above the commercial quota sits a second set of numbers: the service limits and fair use policy. These are the hard technical ceilings on what one tenant can push through shared infrastructure, and they bind regardless of how much entitlement you've bought.

Key facts

• Interaction sending is capped at 300,000,000 per month with a 10,000,000 daily maximum. Support for monthly volumes above 100 million is a preview you have to request through your Microsoft representative.
• The 10 interactions per interacted person figure appears in this policy as a safe use limit, not just a commercial one — the documented remedy is to increase your interacted people entitlement.
• Segment-based journey throughput is up to 500,000 interactions per hour. That rate isn't automatic: it's granted to tenants with 500,000 or more interacted people, to legacy Marketing standalone tenants with 10,000,000 or more active contacts, or to tenants that buy the 500,000 sending burst add-on through their seller.
• Trigger-based journeys process up to 2,500 triggers per minute. Latency at that rate is documented as P90 under 3 minutes and P95 under 5 minutes.
• Beyond the trigger rate, Microsoft's own wording is that additional triggers are subject to slower processing and potential failures — dropped events. This is the one limit that fails silently rather than blocking.
• A single synchronised table is limited to 500,000,000 rows.
• Segment ceilings: 13,000 total segments in real-time journeys, made up of 3,000 dynamic and 10,000 static. A segment used to start or branch a journey is limited to 10,000,000 members.
• Personalisation limits: 100 distinct dynamic attributes in a single message, and up to six levels of relationship traversal with at most one 1:N or N:M hop in the path.
• Custom triggers accept a maximum of 29 input attributes.
• On the commercial side, Microsoft Learn documents in-app notifications as you approach and as you exceed your paid quota, and points you at upgrading the subscription. It does not document a hard cut-off point at which sending stops.

When to use / skip

Most projects never touch these numbers and shouldn't spend time on them. They matter in three situations: high-volume B2C senders, anyone building trigger-based journeys off a real-time event stream, and anyone migrating from an ESP that quoted a throughput figure the client now expects Journeys to match.

If you're in one of those, read the policy properly before you design. The throughput and trigger numbers are architectural constraints — you can't fix a design that assumes 10,000 triggers a minute by buying more capacity, and the burst add-on has to be bought through a seller rather than self-served.

Configuration decisions

• Whether the sending pattern is segment-based or trigger-based, since the two have entirely different rate ceilings and failure modes.
• Whether the client needs the 500,000 sending burst add-on, or whether their interacted people entitlement already clears the threshold that grants it.
• How to smooth a large send. A single overnight blast that exceeds hourly throughput has to be staged across a window rather than fired at once.
• What happens to trigger volume in a spike — a flash sale, a service incident — and whether an upstream buffer or a segment-based fallback is needed.
• Whether segment design stays inside the dynamic segment ceiling, particularly on projects that generate segments programmatically.
• Whether to raise a request with Microsoft for the above-100-million monthly preview, and how far ahead of the campaign that needs doing.

Gotchas

• Trigger overrun drops events. There's no queue that drains later and no error that lands in front of a marketer — the journey simply doesn't run for some people. Watch this one on anything event-driven.
• The 500,000 per hour throughput is an entitlement, not a default. A tenant under the interacted people threshold that hasn't bought the burst add-on will not reach it, however urgent the campaign.
• Programmatically created segments accumulate. Projects that spin up a segment per campaign or per integration run hit the 3,000 dynamic segment ceiling years later, when nobody remembers who wrote the code.
• Personalisation traversal limits catch B2B models hardest — contact to account to parent account to owner is where you run out of hops, and the failure surfaces at design time as an attribute you simply can't pick.
• Exceeding the commercial quota and exceeding the service limits are different events with different consequences. The first is a billing conversation; the second degrades or drops sends.
• What Microsoft actually does commercially when you run past the paid quota — true-up, retroactive charge, negotiated top-up — is not stated on Learn. It sits in the Dynamics 365 Licensing Guide and in the client's own agreement. Don't improvise an answer.

Consultant notes

• For any client with real volume, put the throughput and trigger numbers into the solution design document explicitly and get them signed off. It's the cheapest way to stop an unrealistic expectation being priced into a business case.
• If they're coming off a dedicated ESP, ask what hourly send rate they're used to before you promise anything. That conversation is much better had at design than at first big send.
• Demo the quota page and explain the difference between the notification you get for quota and the silence you get for dropped triggers. Clients assume the system will tell them; for triggers it won't.
• Check before go-live whether the burst add-on is needed and, if so, that it's actually been ordered — it goes through a seller and takes longer than a self-service purchase.
• When procurement asks what happens if they go over, tell them the mechanics you can evidence and route the commercial question to their account team and the licensing guide. Guessing here is how consultants end up owning someone else's invoice.

---

Worth another look after the next release wave, or if the above-100-million monthly sending preview goes GA.