> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tenantcore.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Understand how TenantCore structures Microsoft 365 infrastructure for cold email and why the model is built the way it is.

## What TenantCore does

TenantCore provisions and manages Microsoft 365 infrastructure for cold email operators. You connect a Microsoft 365 tenant to TenantCore, and TenantCore handles the rest. Domain attachment, mailbox provisioning, and send limit enforcement at the Exchange level.

The app and API expose the same operations. Use the app for manual provisioning and monitoring. Use the API to automate provisioning into your own workflows.

## The infrastructure model

TenantCore enforces a specific structure:

| Layer   | Unit      | Limit              |
| ------- | --------- | ------------------ |
| Account | Tenant    | Based on your plan |
| Tenant  | Domains   | Up to 12           |
| Domain  | Mailboxes | Up to 3            |

This isn't arbitrary. Running too many mailboxes per domain is the most common reason cold email infrastructure gets flagged. The 3-mailbox-per-domain ceiling exists to protect sending reputation at the domain level.

## One tenant per client

<Note>
  This is TenantCore's recommended approach. One tenant per client gives you clean isolation. A deliverability problem or suspension event for one client cannot affect another.
</Note>

TenantCore's model is built around this:

* One tenant = one client
* Up to 12 domains on that tenant
* Up to 3 mailboxes per domain
* Up to 36 active sending mailboxes per client

Separation is the point. When infrastructure is isolated, problems are isolated too.

***

### Shared tenant approach

Agencies can run multiple clients on a single tenant to reduce cost. This works, but it requires stricter discipline.

When multiple clients share a tenant, you as the agency are responsible for enforcing send limits across all mailboxes so the tenant stays healthy at the Microsoft level. A single mailbox sending aggressively can affect the reputation of every other mailbox on the same tenant.

TenantCore's recommended ceiling of **900 sends per day across a tenant** is intentionally well below Microsoft's Tenant External Recipient Rate Limit (TERRL). This headroom is deliberate — staying far below the TERRL keeps your tenant in good standing even as you scale.

<Card title="Tenant External Recipient Rate Limit (TERRL)" icon="shield" href="/concepts/terrl">
  Understand Microsoft's tenant-level sending limits and how TenantCore stays within them
</Card>

## Where TenantCore fits in your stack

TenantCore sits between Microsoft 365 and your sending tool. It does not connect directly to Smartlead, Instantly, or any sequencer. Its job is to provision clean infrastructure and enforce send limits before emails leave the mailbox.

```
Microsoft 365 tenant
  └── TenantCore (provisioning + enforcement)
        └── Your sending tool (Smartlead, Instantly, etc.)
```

Your sending tool connects to mailboxes via Microsoft 365 OAuth or SMTP credentials. Both are supported by Exchange Online and configured at the mailbox level during provisioning.

## What TenantCore does not manage

* **DNS records** — TenantCore automatically configures the domains in your tenant and generates them. You copy them to your registrar manually.
* **Microsoft licenses** — You purchase these directly from Microsoft. TenantCore does not resell licenses.
* **Sequences or campaigns** — TenantCore is infrastructure only. Campaign logic stays in your sending tool.
* **Lead data** — No contact or CRM functionality.

## Next steps

<CardGroup cols={2}>
  <Card title="Prerequisites" icon="list-check" href="/getting-started/prerequisites">
    What you need before connecting your first tenant
  </Card>

  <Card title="Quickstart" icon="bolt" href="/getting-started/quickstart">
    Provision your first tenant in under 10 minutes
  </Card>
</CardGroup>
