A separate employee-mail subdomain can isolate frontline mailboxes from the primary corporate domain—if ownership, DNS, and rollback are planned first. This guide covers employee mailbox architecture, not marketing sending-subdomain setup. Do not use it as a deliverability warmup checklist.
A dedicated mail subdomain keeps high-turnover frontline accounts off the primary corporate domain.
Employee-mail subdomain ownership diagram
example.com
Existing M365 / Google Workspace
team.example.com
SmtpMan frontline mailboxes
IT / DNS
Subdomain MX, SPF, DKIM
Security
Allowlist & auth policy
Ops / HR
User groups & rollout cohorts
SmtpMan first-party architecture · Verified: 2026-07-22
High-turnover accounts live on the employee subdomain—not on the primary domain where CEO and HQ mail must stay stable.
Add frontline seats without migrating M365 or Google Workspace. Only the subdomain gets new MX and authentication records.
If you pause the deployment, primary-domain MX never depended on the pilot. Revert subdomain changes without touching HQ mail flow.
For the full safety model and when separation helps, see Separate frontline employee email from your primary domain.
Employee mailbox separation solves a specific ops problem—not every mail need.
Decide the subdomain name, who publishes DNS, and how ops will request accounts before you publish any records.
Use a clear employee-facing name—team.example.com, stores.example.com, or similar. Avoid names that imply marketing or transactional bulk send.
Document how store managers request access, how IT provisions accounts, and who approves expansion beyond the pilot. Tie inbound policy to the Employee email approved-sender allowlist policy.
Ownership model · Verified: 2026-07-22
Publish authentication on the employee subdomain only. Record values and verification steps live in the DNS guide—not here.
Subdomain DNS scope
What IT publishes on the employee subdomain · Verified: 2026-07-22
| Record | Scope | Owner |
|---|---|---|
| MX | Employee subdomain only (e.g. team.example.com) | IT / DNS |
| SPF | TXT on the subdomain; do not merge into root SPF without review | IT / DNS |
| DKIM | Selector records on the subdomain | IT / DNS |
| DMARC | As policy requires—security reviews alignment with allowlist | Security + IT |
Exact values and verification: Employee email DNS setup: SPF, DKIM & DMARC. Product UI reference: Help: domain and DNS.
Change only what the employee subdomain owns. HQ mail on the primary domain must stay untouched.
Primary-domain impact table
SmtpMan first-party safety model · Verified: 2026-07-22
| Area | What changes | What must not change |
|---|---|---|
| Root MX | Nothing on the primary domain | Primary MX stays on your existing provider |
| Subdomain MX / SPF / DKIM | Records for the employee subdomain only | Root SPF/DKIM/DMARC for HQ mail |
| HQ mailboxes | No migration required | Existing M365/Google users and tenants |
| Frontline risk | High-turnover accounts live on the employee subdomain | Primary domain reputation and CEO/HQ delivery path |
Allowed during rollout
Blocked during rollout
Prove delivery, allowlist behavior, and support workflows on one site before you expand.
Pilot
One site or role group. Publish subdomain DNS, create a small cohort, verify schedules and safety notices deliver inbound and outbound.
Launch
Expand by store, shift, or region. Keep HQ mail on the primary domain untouched. Document who approves each expansion wave.
Rollback ready
Define pause criteria before launch. If triggered, archive pilot accounts and revert subdomain DNS—primary MX never depended on the pilot.
Pilot steps · Verified: 2026-07-22
After a successful pilot, treat employee mail as a managed service—not a one-time DNS change.
Add store, shift, or regional groups on a schedule ops and IT agree on. Avoid provisioning hundreds of accounts before DNS and allowlist are stable.
Track failed inbound to pilot groups, unexpected bounces, and allowlist blocks. Escalate DNS or policy gaps—not ad-hoc exceptions per store.
Record subdomain name, DNS owner, allowlist approver, provisioning steps, and support contacts. Link the DNS guide and product help for record values.
Plan pause and revert steps before launch so incidents do not force primary-domain changes under pressure.
Rollback stays local because the primary domain never depended on the employee subdomain. Document incident contacts for IT, security, and ops—and who can approve DNS reverts.
Architecture reference: Separate frontline employee email from your primary domain.
Pilot → launch → rollback checklist with owners by phase.
Employee email subdomain deployment checklist
Product steps: SmtpMan capabilities · Verified: 2026-07-22 · HR/legal notes are general guidance only
| Phase | Task | Owner |
|---|---|---|
| Plan | Choose employee subdomain name and document operating model | IT + ops |
| Plan | Confirm primary MX will not change; security reviews allowlist | IT + security |
| DNS | Publish subdomain MX, SPF, DKIM (and DMARC as required)—see DNS guide | IT / DNS |
| DNS | Verify records in product per Help: domain and DNS | IT |
| Pilot | Select one site/role cohort; create accounts from roster | Ops + IT |
| Pilot | Test inbound/outbound delivery and allowlist behavior | IT + store manager |
| Launch | Expand by approved waves; document runbook and support contacts | Ops + IT |
| Launch | Monitor delivery failures and allowlist blocks weekly | IT |
| Rollback | Define pause criteria before each expansion wave | IT + security |
| Rollback | If paused: archive accounts, revert subdomain DNS, confirm root MX unchanged | IT / DNS |
Deployment
No. Employee mail on a subdomain uses MX, SPF, and DKIM records on the subdomain only. Your primary domain MX stays on your existing M365 or Google Workspace provider.
This guide covers employee mailbox architecture—not marketing sending subdomains. Mixing bulk campaign traffic with operational frontline mailboxes increases risk and complicates ownership. Keep employee mail on a dedicated employee subdomain.
IT or a designated DNS owner publishes subdomain records. Security reviews allowlist and authentication policy. SmtpMan provides the values to publish but does not replace your DNS ownership.
Rollout
Run the pilot until one controlled site or role group has verified inbound delivery, outbound send, and allowlist behavior for at least one full operational cycle—typically two to four weeks for shift-based teams.
Rollback stays local to the employee subdomain: archive or remove pilot accounts, revert subdomain DNS if required, and confirm primary-domain MX was never changed. HQ mail on the primary domain continues unaffected.
Next step
Review the auxiliary-domain safety model—or continue to DNS record setup.