Employee mailbox domains need correct MX and authentication records before you scale hiring. This guide explains MX, SPF, DKIM, and DMARC for employee email—including a safe publish order and validation steps—focused on mailbox domains rather than marketing-sending setup. For SmtpMan product UI steps, use Help: domain and DNS.
Four record families cover delivery and authentication for frontline mailbox domains.
Tells the internet where to deliver mail for worker@team.example.com. Without correct MX, new hires never receive schedules or safety notices.
Lists which servers may send mail on behalf of the employee domain. Helps receivers reject spoofed messages that claim to come from your frontline addresses.
Cryptographic signatures prove a message was not altered in transit and came through an authorized signing path for the employee domain.
Tells receivers what to do when SPF or DKIM fail, and where to send aggregate reports so you can monitor authentication before tightening policy.
This guide covers employee mailbox domains—not bulk marketing or newsletter sending. For the safety model behind a separate frontline domain, see Separate frontline employee email from your primary domain.
MX (Mail Exchange) records point inbound mail to your employee mail host. For a subdomain such as team.example.com, publish MX only on that subdomain zone—not on the primary corporate domain unless you intend to move all company mail.
Product record values and verification: Help: domain and DNS.
| Type | Host | Priority | Value |
|---|---|---|---|
| MX | @ | 10 | mx1.mailhost.example |
| MX | @ | 20 | mx2.mailhost.example |
Example only—use values from your mail provider, not this table.
SPF tells receiving servers which IP addresses and senders may deliver outbound mail for your employee domain.
Publish a TXT record at the root of the employee mail domain (for example team.example.com). Include only the services that actually send on behalf of that domain—your employee mail host, any approved relay, and nothing else.
Common employee-mail scenarios:
SPF alone does not sign message bodies. Pair it with DKIM and DMARC for a complete authentication stack on employee domains.
DKIM adds a digital signature receivers can verify using a public key published in DNS.
Your mail provider generates a selector (for example smtpman2024) and a public key. You add a TXT record at selector._domainkey.team.example.com.
Never share the private signing key—only the DNS TXT value belongs in your zone.
Shift schedules, HR notices, and store alerts often come from automated systems. DKIM helps receivers trust that those messages were not tampered with in transit.
If you rotate keys, publish the new TXT record before retiring the old selector to avoid a signing gap.
Employee mail vs marketing: Marketing platforms often use their own DKIM selectors on a dedicated sending subdomain. Employee mailbox domains should sign through the mailbox provider's selectors—not a bulk ESP's marketing keys.
DMARC builds on SPF and DKIM alignment and gives you visibility through aggregate reports.
Publish a TXT record at _dmarc.team.example.com. A conservative starting policy for a new employee domain:
p=none
Monitor only. Receivers report failures but do not reject mail based on DMARC alone.
p=quarantine
Intermediate step after reports show consistent alignment for legitimate employee senders.
p=reject
Strongest policy—use only when SPF and DKIM pass reliably for every approved sending path.
DMARC protects the domain identity of employee addresses. It complements—but does not replace—an Employee email approved-sender allowlist policy for inbound security.
Publish in this sequence to avoid delivery gaps during employee domain rollout.
MX + client CNAMEs
Establish inbound delivery and client endpoints first. Test with a pilot mailbox before bulk provisioning.
SPF
Authorize your mail host to send for the employee domain. Verify outbound test messages pass SPF.
DKIM
Enable signing in your mail provider, then publish the selector TXT record. Confirm signatures on sent mail.
DMARC (p=none)
Add monitoring policy and a report mailbox. Review aggregates before tightening to quarantine or reject.
Rollout on a subdomain without touching primary MX: Employee email subdomain deployment without changing your primary domain.
Confirm every record before you onboard the next hiring wave.
Use your provider's in-product verification (SmtpMan shows Verified / Pending / Failed per row) or query public DNS with dig MX team.example.com and confirm targets and priorities match.
Send a test message to a pilot mailbox and confirm it arrives in the inbox—not only that DNS resolves.
Query dig TXT team.example.com and confirm exactly one SPF record. Send outbound mail from an employee account and inspect headers for spf=pass at major receivers.
Confirm the selector TXT exists at selector._domainkey.team.example.com. Sent messages should include a DKIM-Signature header with dkim=pass in Authentication-Results.
Query dig TXT _dmarc.team.example.com. After mail flows, check that aggregate reports arrive at your rua address and show expected sending sources.
SmtpMan verification UI: Help: domain and DNS.
These patterns cause the most employee-mail DNS incidents during rollout.
Publishing MX on example.com when employee mail lives on team.example.com—or the reverse. Always match the zone to the mailbox domain.
Two SPF records on one name invalidates SPF evaluation. Merge includes into a single record.
Publishing p=reject on day one can block legitimate employee mail from unlisted senders. Start with p=none and read reports first.
TTL and propagation delays cause false failures. Wait for the TTL window—or use the provider's retry—before declaring a record broken.
Bulk ESP includes do not belong on a mailbox domain unless that ESP actually sends employee mail. Keep records scoped to the employee mail host.
Frontline rollout should not repoint corporate MX. Use a separate employee subdomain so HQ mail stays untouched.
Run this list once per employee mail domain before scaling provisioning.
Record-by-record checklist
Employee mailbox domain · Verified: 2026-07-22
| Record | Publish at | Purpose | Validate |
|---|---|---|---|
| MX (×2) | employee domain @ | Inbound delivery to mail host | Provider verify + test inbound message |
| CNAME imap / smtp | imap, smtp | Client access endpoints | Provider verify + client login test |
| SPF (TXT) | employee domain @ | Authorize sending servers | dig TXT + outbound header check |
| DKIM (TXT) | selector._domainkey | Message signing public key | dig TXT + dkim=pass on sent mail |
| DMARC (TXT) | _dmarc | Policy + aggregate reporting | dig TXT + rua report received |
Primary source references
Correct DNS authentication reduces spoofing risk and supports consistent evaluation by receiving servers. It does not guarantee inbox placement at every provider—monitor reports and adjust policy based on observed results.
Employee mail DNS
Yes for most deployments. MX delivers inbound mail; SPF, DKIM, and DMARC help receiving servers evaluate outbound mail from your employee domain and reduce spoofing risk. Requirements vary by provider and policy—confirm with your mail host and security team.
Usually no. SPF is evaluated against the domain in the From address and the envelope sender. An employee subdomain such as team.example.com typically needs its own SPF record listing only the services that send mail for that subdomain.
No. Start with p=none and monitor aggregate reports until SPF and DKIM alignment is consistent for legitimate employee mail. Tighten policy only after you understand what is sending from the domain.
No when using an auxiliary employee subdomain. Publish MX, SPF, DKIM, and DMARC on the employee subdomain only. Keep existing primary-domain MX for HQ and corporate mail. See Separate frontline employee email from your primary domain.
Next step
Choose the auxiliary-domain safety model—or follow the subdomain deployment guide for rollout steps.
Employee email subdomain deployment without changing your primary domain