Skip to main content

​
Tenants, Domains & Mailboxes

TenantCore organizes outbound infrastructure around three core resources:
That hierarchy is the foundation for DNS automation, mailbox creation, sending limits, Outlook access, sending-tool connections, monitoring, Reports, and API automation.

​
Tenant

A tenant is a Microsoft 365 environment connected to TenantCore. For the current bring-your-own-tenant workflow, you already own or administer the Microsoft 365 tenant before connecting it. TenantCore does not treat a Microsoft tenant ID by itself as permission to manage that environment. The tenant must first be connected to and owned by your authenticated TenantCore account. A connected tenant becomes the parent resource for:
  • domains
  • mailboxes
  • mailbox sending limits
  • Outlook delegation
  • service status
  • sending-location monitoring
  • reputation monitoring
  • alerts and notifications
  • Reports
  • supported API operations

​
Tenant slots

A tenant slot is TenantCore capacity to connect and manage one customer-supplied Microsoft 365 tenant. A tenant slot is not an included Microsoft 365 tenant. Base, Plus, and Complete each include 3 tenant slots. Additional tenant slots can be added separately.

​
Domain

A domain is a sending domain you already own and add to a connected tenant. TenantCore does not register or create domains. Each connected tenant supports up to 12 domains. A domain belongs to exactly one TenantCore tenant resource for management purposes. That relationship is used to scope:
  • Microsoft domain verification
  • MX/SPF/DMARC/DKIM state
  • Automatic DNS
  • mailbox creation
  • Reports
  • public API authorization

​
Mailbox

A mailbox is a sending identity created under a TenantCore domain. Each domain supports up to 3 mailboxes, for up to 36 mailboxes per tenant. TenantCore can manage the mailbox lifecycle, including:
  • creation
  • deletion
  • password reset
  • protected credential access
  • MFA setup
  • sending limits
  • Outlook access
  • sending-tool connection status
  • usage and reputation state

​
Resource ownership

TenantCore keeps the resource chain intact:
That matters for both the application and the Complete API. A mailbox cannot be managed simply because someone knows its email address. A domain cannot be modified simply because someone knows its domain name. A tenant cannot be operated against simply because someone knows its Microsoft tenant GUID. TenantCore verifies that the resource belongs to your authenticated TenantCore account before performing the supported Microsoft, DNS-provider, or sending-tool action.

​
BYOT is the current customer model

The current public TenantCore workflow is bring your own tenant (BYOT). That means:
  • you provide the Microsoft 365 tenant
  • you remain responsible for being authorized to administer it
  • you add domains you already own
  • TenantCore automates and manages supported operations against those connected resources
TenantCore-managed tenant purchasing is not part of the current self-service product workflow.

​
Why TenantCore uses this hierarchy

Keeping the infrastructure attached to a clear resource hierarchy makes automation safer and easier to reason about. For example:
The same model applies to DNS automation, Outlook delegation, sending-tool integrations, and API operations. This keeps TenantCore from becoming a generic proxy for arbitrary Microsoft tenants, domains, or mailboxes.