Multi-tenant apps

If your product sends email for many customers, a few decisions keep them from affecting each other.

#One organization, many domains

Everything in usend belongs to your organization: domains, keys, suppressions, webhooks. Add each customer's sending domain (or a subdomain you give them, such as mail.customer.com) as a domain in your organization and ask them to publish the DNS records from the domain's page. Offer Auto-configure when their DNS is on Cloudflare.

• Your plan has a domain limit (Pro 10, Scale 1,000): see Account quotas and limits. Ask for more if you need it.
• A domain can be verified by one usend organization at a time.
• Send from the customer's domain so mail is authenticated as them. Until it verifies, fall back to a subdomain of your own, such as customer.mail.yourapp.com.

#Keep reputations separate

Reputation attaches to the sending domain, so a customer who spams hurts only their own domain. But your organization is judged as a whole: bounce and complaint rates are measured per organization, and usend suspends the organization (all your customers) above 4% hard bounces or 0.08% complaints. Protect yourself:

• Make customers confirm their list and honor unsubscribes: Email consent.
• Validate recipients in your own app before sending.
• Watch rates, and have a way to pause one customer. Because suppression lists are per organization, a bounce from one customer's list also suppresses that address for the others.
• Put your terms in front of customers: no purchased lists.

#Per-tenant keys and tags

• Create a sending_access key limited to a domain if you give customers their own credentials (for example for SMTP). They can then send only from their own domain.
• Tag each email with the tenant so you can find it again:

{
  "from": "Acme <[email protected]>",
  "to": ["[email protected]"],
  "subject": "Your invoice",
  "html": "<p>...</p>",
  "tags": [{ "name": "tenant", "value": "cus_123" }]
}

Tags come back in webhook payloads, so you can route events to the right tenant. Use idempotency keys that include the tenant ID.

#Quotas are shared

The monthly and daily quotas apply to your organization, not to each customer, and the API allows 10 requests per second per key. Build a queue in your app, and rate-limit customers yourself so one cannot use the whole quota.

#Receiving

If customers can reply to mail, give each a receiving subdomain or route by the to address.

#Deleting a customer

Delete their domain with DELETE /domains/{id} and their keys. That removes the identity and stops sending from it.