Cold email tenant isolation: the limit nobody checks

Cold email advice is unanimous about domains. Send from a separate one, never the domain your invoices leave from, and accept that a burned domain is replaceable while a burned primary is not. That advice is correct and it is only half the structure.

Above the domain sits the tenant: the Microsoft 365 organisation that owns the mailboxes. It is invisible from inside a mailbox, it is almost never mentioned on a provider pricing page, and it carries a sending limit and a reputation of its own. If you are buying mailboxes rather than building them, the tenant is the part of the stack you have least visibility into and the least control over.

Microsoft 365 cold email sending limits

There are three separate ceilings on a Microsoft 365 mailbox, and they are not interchangeable. Confusing them is the most common reason a sending plan looks fine on paper and fails in practice.

The first two are per mailbox and generous. The third is the one worth understanding, because it does not belong to your mailbox at all. The Tenant External Recipient Rate Limit, usually shortened to TERRL, caps how many external recipients the entire organisation can reach in a day. Every mailbox in the tenant draws from the same pool.

It scales with licence count rather than being fixed: roughly 500 times the licence count raised to the power 0.7, plus 9,500. A hundred licences works out around 22,000 external recipients a day. That is far above any sane cold email volume, which is exactly why it gets dismissed. It should not be: on a tenant of our own, refusals started at about 950 to 1,000 a day, a tenth of the published floor, as covered in the tenant sending limit post.

Dismissing it is safe only while the tenant is yours. The moment it is shared, the number stops describing your headroom and starts describing everyone’s combined headroom, and you have no way to see how much of it is left.

None of these platform ceilings are deliverability guidance. The volume that keeps a mailbox out of spam is roughly three cold emails per day, which is far below every number in that table.

That last point matters before going further. A platform cap is an abuse threshold, not a recommendation, and sending anywhere near one is how domains get burned. The safe per-inbox rate is a behavioural question, not a technical one.

Does your provider share a Microsoft tenant?

Providers who sell Microsoft 365 mailboxes have to put them somewhere. There are two ways to do it, and the pricing page rarely says which.

The cheaper approach is one tenant holding many customers’ domains. It is faster to provision, needs fewer licensed accounts, and reduces the administrative overhead of running the business. From the customer’s side it looks identical: a mailbox at your own domain, working credentials, mail that sends.

The other approach is a tenant per customer, or a tenant per domain. It costs more to run, because the per-domain licence and setup overhead no longer amortise across everyone. What it buys is that the tenant-level ceiling and the tenant-level reputation belong to one party.

You cannot tell which one you have by looking at a mailbox. The address is at your domain either way, the credentials work either way, and nothing in Outlook names the organisation you are inside. It has to be asked.

What sharing a tenant actually costs you

Three things move from your control to someone else’s, and none of them are visible until they matter.

The daily ceiling is divided, invisibly

TERRL is one pool per tenant. If four customers share a tenant, the four of you share one ceiling, and none of you can see the others’ consumption. Your own volume plan can be conservative and still hit a wall because somebody else in the same organisation had a busy week.

Reputation attaches above the domain

Spam complaints, spam-trap hits and throttling events register against the tenant as well as the sending domain. Domain isolation protects your other domains from each other. It does not protect you from a stranger in the same tenant whose list quality you cannot audit and whose sending you cannot see.

Enforcement is blunt

When Microsoft restricts a tenant for outbound abuse, the restriction lands on the tenant. It does not exempt the well-behaved senders inside it. On a shared tenant, the worst sender sets the floor for everyone, and you find out at the same time they do.

The pattern is the same argument that put your cold email on a separate domain in the first place, moved one level up. Domain strategy covers the layer below this one.

The trade a provider is actually making

It is worth being fair about why shared tenants exist. They are not a scam; they are a cost decision, and the cost is real.

• Each isolated tenant needs its own licensed account to send from, so the licence cost stops being spread across every customer.
• Tenant setup, authentication and DNS configuration repeat per tenant rather than once.
• Administration multiplies: more tenants means more credentials, more consoles, more places for a configuration to drift.

A provider running one shared tenant can be cheaper and can pass that saving on. What they cannot pass on is isolation, because they no longer have it to give. The question is not whether shared tenancy is dishonest. It is whether the saving is worth a ceiling and a reputation you share with senders you will never meet.

What to ask before you buy

Four questions, none of which require a technical conversation to interpret.

1. Will my domains be in a Microsoft 365 tenant shared with other customers? A provider that isolates will answer immediately and specifically; a vague answer is itself an answer.
2. How many domains sit in one tenant? "One per customer" and "one per domain" are different commitments, and both are stronger than no answer.
3. What daily send rate is each mailbox sized for? If the reply quotes a platform ceiling rather than a per-mailbox rate, that is a sign the sending model has not been thought about.
4. If another customer in my tenant gets the tenant restricted, what happens to my mailboxes? The answer reveals whether the risk has been considered at all.

Note that "isolated workspaces" and "separate domains" are not answers to the first question. Both are true of a shared tenant. The word that matters is tenant, and it is worth insisting on it.

How we do it, and why

Every domain we provision gets its own Microsoft 365 tenant, and a second domain is never added to an existing one. Each tenant carries one licensed service account that the mailboxes send as, which is the per-domain cost that model implies.

The reason is as much self-interest as customer benefit, and it is more credible stated that way. A shared tenant would put our own infrastructure at the mercy of the least careful sender on it. One bad list, loaded by one customer, would degrade delivery for everyone in that organisation and there would be nothing the others could do about it. Isolation is the cheapest insurance against a problem we cannot supervise.

It is worth stating the boundary too. Tenant isolation removes other customers as a variable. It does not make a domain unblockable, and it does not compensate for a bad list, a bad offer or a volume ramp that outruns warmup. Infrastructure decides whether mail arrives. It does not decide whether anyone wants to read it.

The buying guide covers the rest of what separates providers, and the measured results page publishes what this infrastructure actually produced across eleven of our own campaigns, including the ones that replied at zero.