Pick your sending subdomains.

Send from a subdomain, not the root. Root MX stays with the mailbox host. Each stream gets a host of its own. This lesson covers why, how to name them, and the records PostShiba asks you to publish.

Why a sending subdomain

Your root domain almost certainly already receives mail. People write to you@example.com. Google, Microsoft, or another mailbox host answers that MX. If you point root MX at a sending platform, inbound company mail stops arriving.

A sending subdomain such as mail.example.com keeps those records free. PostShiba never asks you to change root MX. You verify the subdomain, then send from any address on it: hello@mail.example.com, receipts@mail.example.com. There is nothing else to create. A sending subdomain keeps inbound mail working.

Reputation splits the same way. Mailbox providers score the From domain. A newsletter on news.example.com can have a bad day without teaching Gmail that mail.example.com is a bad sender. Password resets keep their own history.

DMARC reports get cleaner too. Aggregate rua mail shows which host sent as you. When transactional and bulk use different From hosts, you can see which stream failed alignment or showed up from an old vendor. One shared root From mixes those rows together.

Verifying the root still works. You then send from hello@example.com. Receiving on the root is allowed only when the root has no MX, which is rare for a domain that already has mailboxes. Prefer the subdomain.

Naming patterns

Use a short host per stream. Keep the names boring so the next person on the team can read them.

mail.example.com for transactional mail: receipts, password resets, 2FA codes. news.example.com for bulk: newsletters, campaigns, win-back. notify.example.com when notifications are a stream of their own and you do not want them on mail..

Platforms do the same on each customer's domain. Tenant acme-florist sends transactional as mail.acme.example and bulk as news.acme.example. Do not invent a new pattern per customer.

Enter a domain below and pick the streams you send. The planner shows a host per stream and the DNS records for each.

Once a host verifies, every address on it can send. You do not create receipts@ as a separate domain. The host is the sending domain. The local part is yours.

What is shared and what is separate

Subdomains limit spillover. They do not erase it.

Mailbox providers still group hosts under the organizational domain. mail.example.com and news.example.com both sit under example.com. A long, ugly complaint history on news. can still color how a provider sees the organization. The subdomain gives you a wall. It is not a vault.

What stays separate when you split hosts: DKIM signatures, return-path, the From domain people see, and the DMARC row for that host when it publishes its own record. A _dmarc record on example.com also covers mail.example.com unless the subdomain publishes its own.

What still links them: the organizational domain, the team, and any IP they share. Customer clusters start on shared IPs. Transactional and bulk clusters use different shared sending pools, which helps. Dedicated IPs and pools split the rest once volume is steady.

Do not treat a subdomain as a place to hide a bad list. A win-back blast on news.example.com still sits next to mail.example.com in the provider's org view. Send wanted mail. Import suppressions before the first send.

One domain per stream per tenant

A sending domain belongs to one tenant. An SMTP credential can only send as its tenant's domains.

If you send only as your own company, the default tenant is enough. Verify mail.example.com for transactional and news.example.com for bulk. That is two sending domains, one stream each.

If you send for customers, create one tenant per customer. Add that customer's sending domains under that tenant, one host per stream. mail.acme.example and news.acme.example live on tenant acme-florist. A complaint or an unsubscribe on acme.example stays on that tenant's suppression list. You can suspend one tenant, or one sending domain, and keep everyone else sending.

Do not put two customers on one sending domain. Do not put transactional and bulk on one host "for now". The cleanup is always harder than the extra CNAME.

The records PostShiba needs

PostShiba sends only from verified domains. Add the domain, publish two records, and send from any address on it once they verify. The values to copy are on the domain page.

Do this once per sending domain. mail.example.com gets its own DKIM CNAME and its own rp.mail.example.com. news.example.com gets a second pair. Most DNS hosts want the host without the zone. For mail.example.com in the example.com zone, enter rp.mail and {selector}._domainkey.mail.

Leave root SPF and MX alone. SPF is checked against the return-path host. PostShiba answers that check through the rp. CNAME. You do not add a PostShiba include to the root SPF. Set up SPF, DKIM, and DMARC walks each record.

The domain page can download a BIND file with the two CNAMEs. It adds DMARC unless a record is already there. In Cloudflare, leave proxy off.

Receiving on inbound

Sending and receiving are different hosts. Sending needs the two CNAMEs above. Receiving needs MX on a host that does not already have it.

The default receiving host is inbound.{domain}. For mail.example.com that is inbound.mail.example.com. PostShiba refuses a host that already has MX, so you cannot take over example.com by accident. Hosted inboxes on the PostShiba inbound zone need no MX at all.

Publish the MX shown on the inbox, on that inbound host only. Leave example.com with Google or Microsoft.

That is the shape. A subdomain per stream. Root MX untouched. One sending domain per stream per tenant. Two CNAMEs each, then send. When a stream misbehaves, you pause that host or that tenant, and the password resets on mail. keep going.