Sending Domains

After Brand Kit setup, every brand permanently reserves one protected address: hello@<brand-slug>.nitrosend.net. The slug comes from the confirmed company name, never the account owner's name or a placeholder. Reservation creates no Domain or sending-identity row for a dormant account. Activation—or the first eligible API/MCP send—materializes those local rows synchronously under one already-verified shared SES root. There is no per-brand DNS, DKIM, provider identity, tenant resource, background job, polling state, or .com fallback.

You can instead add a sending domain you own. Your email then goes out from your address on Nitrosend's infrastructure, and the reputation you build is portable with your domain. There's no separate email provider to wire up.

Activate the Nitrosend sender

1. Go to Brand → Domains.
2. Review the reserved <brand-slug>.nitrosend.net address and choose Activate sender.
3. Nitrosend creates the local logical identity immediately. If the brand has no selected sender, that same transaction selects it; an existing custom sender remains selected until you explicitly replace it.
4. Choose the visible local part, such as hello, whenever you select this hosted identity.

Activation never queues or sends email and never calls a DNS or email provider. The reserved FQDN cannot be renamed in this release. A Nitrosend brand-subdomain sender also does not consume your customer-domain allowance.

Add a sending subdomain

1. Go to Brand → Domains.
2. Under Add a sending domain, enter a subdomain you own — for example send.yourdomain.com.
3. Nitrosend generates the DNS records for that subdomain and shows them on screen.
4. Add those records at your DNS provider (see below). Nitrosend verifies them automatically — once they resolve, the domain flips to Verified and becomes available as a send-from address.

Use a subdomain, not your primary domain

A subdomain isolates your marketing and product sending — its DNS records and its sending reputation — from the domain that runs your everyday inbox (for example Google Workspace or Gmail on yourdomain.com).

That matters for two reasons:

• It keeps your corporate mail untouched. Your primary domain already has mail authentication set up for your team's inboxes. Sending bulk email from it can interfere with that setup — a subdomain leaves it alone.
• It protects your reputation. Sending volume builds a reputation with inbox providers. Keeping it on a dedicated subdomain means a bad send never drags down the domain your team emails from.

This is the setup inbox providers like Gmail expect from senders.

Add the DNS records

The Domains screen lists the exact records for your subdomain — typically a verification record, SPF, DKIM, and a return-path / tracking record. Add each one at your DNS provider (Cloudflare, GoDaddy, Namecheap, Route 53, and so on) exactly as shown.

Route different mail through different subdomains

You can verify more than one subdomain and push different email through each by changing the send-from address:

• hello@news.yourdomain.com — marketing campaigns
• hello@txn.yourdomain.com — transactional / product email

Splitting sending this way isolates reputation between mail types, so a large promotional send can't drag down your receipts and password resets. This is mostly useful for large-volume senders — most brands are perfectly fine with a single subdomain.

Set a reply-to address

Your send-from address doesn't have to be where replies land. Set a Reply-To under Brand → Sender and replies go to whatever inbox you like — independent of the subdomain you send from.

For example, send from news@send.yourdomain.com but have replies arrive at hello@yourdomain.com. The Reply-To can be any mailbox you actually monitor, on any domain.

How sending capacity grows

Each effective sending identity has its own capacity history. Headroom grows only from matured, clean delivered volume on that exact identity—not from account age, subscription age, payment, list imports, validation, or time passing. A new customer domain therefore begins with its own observed history; volume from another hosted or customer-domain identity is never transferred to it. Existing legacy .com history also remains bound to that exact identity.

Commercial plan capacity, identity capacity, provider limits, and delivery pacing are separate inputs to one admission decision. The API, MCP status, and review responses report the binding result; clients should not calculate a private limit from plan names.