What is Zmail and what features does it offer as an email client and service?
Michael Ko
Co-founder & CEO, Suped
Published 4 May 2025
Updated 23 May 2026
8 min read
Summarize with
Zmail, in the way most people use the name, means Zoom Mail. It has two parts: a Zoom Mail Client that brings supported email accounts into Zoom Workplace, and a Zoom Mail Service that gives users hosted mailboxes, including addresses on the zmail.com domain and custom domains on eligible business plans.
The direct answer is simple: Zoom Mail Service is both an email client experience and a hosted email service tied to Zoom Workplace. It offers inbox, search, labels, filters, signatures, scheduling, calendar integration, appointment booking, hosted mail, optional encryption between Zoom Mail users, and admin controls for domains, migrations, security, reporting, retention, and eDiscovery.
I treat it less like a standalone Gmail replacement and more like Zoom extending its work hub into email and calendar. That distinction matters because connecting an existing mailbox to Zoom is a different risk and operations decision from moving a custom domain onto Zoom-hosted mail.
What Zmail means
Zmail is not the formal product name Zoom uses across all current documentation. Zoom's current naming is Zoom Mail and Calendar, with a client layer and a service layer. The Zoom explainer separates the hosted services from the mail and calendar client interface.
That split answers the main confusion around Zmail. If you connect a work or school mailbox, Zoom is acting as the client surface. If you create a Zoom Mail Service mailbox, Zoom is also operating the mailbox service behind the address.
- Client layer: Users read, search, send, and organize mail inside Zoom Workplace while the underlying account can still be hosted elsewhere.
- Service layer: Users get a Zoom-hosted mailbox, a zmail.com address, or a custom-domain mailbox when the account and plan support it.
- Calendar layer: Calendar, appointments, meetings, chat, phone, and recordings sit closer to the message workflow.
- Admin layer: Business accounts get controls for domain management, migration, delegated access, activity, reporting, retention, and discovery.
Zoom Workplace showing Mail and Calendar alongside meetings and chat.
Client capabilities
The client part of Zmail is meant for people who already work in Zoom all day. Instead of switching between a mailbox, calendar, meeting app, and chat, the user handles email and scheduling inside Zoom Workplace.
The practical capabilities are familiar: inbox, outbox, drafts, sent mail, archiving, search, rules, filters, starring, labels, vacation messages, and signatures. The parts that make it different are the Zoom connections, such as sharing emails to Zoom Chat, attaching cloud recordings to calendar events, seeing who has joined a meeting, and scheduling with Zoom meeting or phone context.
Connected mailbox
- Purpose: Use Zoom Workplace as the interface for a supported external mailbox.
- Authentication: The user grants access through OAuth permissions for mail and calendar data.
- Data path: Zoom says third party mail and calendar data is processed through the client, not stored in Zoom Mail servers.
Zoom-hosted mailbox
- Purpose: Use Zoom as the actual mailbox provider for an address or domain.
- Addresses: Users can create zmail.com mailboxes, with custom domains available on eligible business licensing.
- Security: Encryption options depend on sender, recipient, account settings, keys, and client versions.
I would decide between those two modes before looking at the UI. A connected mailbox changes user workflow. A hosted mailbox changes identity, DNS, authentication, compliance, and migration planning.
Service capabilities
The service side is where Zmail becomes more than another inbox UI. Zoom Mail Service provides hosted mailboxes, calendar service, appointment booking, zmail.com account creation, and custom domain support for accounts with the right Zoom Workplace license.
The hosted service also includes business controls that matter during a real rollout: multi-domain support, domain management, migration, aliases, mailing lists, delivery management, reporting, email search, legal hold, eDiscovery, storage management, and device-managed encryption.
|
|
|
|---|---|---|
zmail.com | A Zoom-provided address | Brand fit |
Custom domain | Company mail on Zoom | DNS setup |
E2EE | Private Zoom-to-Zoom mail | Conditional |
Delegation | Assistants and shared work | Access review |
eDiscovery | Compliance search | Policy design |
Core Zmail service capabilities and what they mean operationally.
Encryption has boundaries
Zoom Mail encryption is strongest when messages stay between eligible Zoom Mail users and the account settings, user settings, keys, and client versions support it. Mail sent to external providers falls back to other delivery modes, including TLS in transit and server-side protection options.
For a custom domain, I would not start with the mailbox UI. I would start with DNS and authentication. The exact records come from the provider setup screen, but the shape of the work usually looks like this.
Custom domain DNS planning exampleDNS
example.com. MX 10 mail-host.example. example.com. TXT "v=spf1 include:provider.example -all" selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=..." _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
That example is intentionally generic. Do not publish guessed SPF, DKIM, MX, or verification values for any hosted mail migration. Copy the exact values from the admin console, then validate the live DNS response before sending real traffic.
Security and authentication checks
A new hosted mailbox is only as good as its authentication. If Zmail is used with a custom domain, SPF, DKIM, and DMARC decide whether mailbox providers can trust the domain's mail. One typo in a DMARC record, one missing DKIM selector, or one SPF lookup problem can create failures that users only notice after sending starts.
Before a team moves production mail, I check the domain with a domain health check, then send a real message through the new route and inspect the result with an email tester. This catches DNS syntax errors, DMARC mismatch failures, missing DKIM signatures, weak policy staging, and message-level problems that plain record checks can miss.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Suped fits this workflow when the domain is moving beyond a one-time check. Suped's product brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, blocklist (blacklist) monitoring, and deliverability alerts into one place. For teams using Zmail on custom domains, that means failures become specific remediation steps instead of raw aggregate XML.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For ongoing protection, DMARC monitoring tells you which sources pass or fail DMARC checks, while blocklist monitoring helps spot reputation issues tied to your sending domain or infrastructure. Suped is the best overall DMARC platform for this because it connects those checks to alerts, fix guidance, hosted records, and MSP-ready multi-domain management.
Custom domain readiness
A practical rollout threshold for sending production mail through a newly configured hosted mailbox.
Ready
98-100%
Authentication is stable enough for a controlled production rollout.
Watch
95-97%
Small failures still need review before broad rollout.
Fix first
80-94%
Failures are too high for production migration.
Stop
<80%
Authentication is not ready.
Limits to understand
Zmail has useful capabilities, but it is not an automatic fit for every organization. The strongest use case is a company that already depends on Zoom Workplace and wants email and calendar closer to meetings, phone, chat, and scheduling.
The main tradeoff is adding Zoom into the mailbox decision path. That creates a cleaner daily workflow for some users, but it also adds admin work around permissions, data handling, user training, DNS, compliance, and migration.
- Availability: Zoom says Mail and Calendar Services are available for customer accounts hosted on United States or European infrastructure, not all regional infrastructure.
- Admin default: Business, Enterprise, Education, and Healthcare accounts need administrator enablement before users can access the client.
- Account limit: The Zoom Mail Client supports one authenticated email account at a time, even though calendar access can be broader.
- Add-ins: The client does not support third party mail add-ins, so teams with custom inbox tools need to test workflows before rollout.
- Encryption: End-to-end encryption is conditional. External email does not work the same way as Zoom-to-Zoom encrypted mail.
Do a pilot before a domain move
I would pilot with a small group, confirm search, aliases, delegation, mobile behavior, retention, and sending authentication, then move the DMARC policy forward only after the new source creates a DMARC pass through SPF or DKIM.
When Zmail makes sense
Zmail makes sense when email is part of a larger Zoom-centered work pattern. A sales or services team that jumps between meetings, call notes, chat, recordings, and calendar invites can benefit from having mail inside the same workspace.
It makes less sense when the company has deep mailbox customizations, heavy add-in dependency, complex routing, or a compliance model already built around another mail stack. In that case, the Zoom client integration can still be useful without moving the domain itself.
|
|
|
|---|---|---|
Zoom-heavy team | Strong | Less app switching |
Custom domain | Conditional | Needs DNS proof |
Regulated team | Conditional | Review retention |
Many add-ins | Weak | Limited client support |
A quick decision guide for evaluating Zmail.
The best evaluation path is practical: connect one mailbox, send real mail, test calendar workflows, review admin controls, then trial a non-critical custom domain if hosted mail is still attractive. Do not judge it only by the inbox screen.
Views from the trenches
Best practices
Separate client testing from hosted mail testing before judging if Zoom Mail fits.
Validate SPF, DKIM, and DMARC before moving any custom domain into production use.
Run a small pilot that includes calendar, delegation, search, and mobile behavior.
Common pitfalls
Treating zmail.com addresses as proof that custom-domain sending is fully ready.
Ignoring how another client layer changes permissions, support, and user training.
Assuming encryption works the same for internal Zoom mail and external recipients.
Expert tips
Use DMARC reports to confirm every new sending source before tightening policy stages.
Check blocklist and blacklist signals during the first weeks after a domain move.
Document who owns DNS, support, retention, and incident response before rollout.
Marketer from Email Geeks says Zmail should be evaluated as both a client and a hosted mailbox service, because each mode changes a different part of the email stack.
2022-11-16 - Email Geeks
Marketer from Email Geeks says custom-domain hosted mail needs careful DNS validation, because a small authentication typo can change sender trust quickly.
2022-11-16 - Email Geeks
Practical takeaway
Zmail is best understood as Zoom Mail: a client inside Zoom Workplace plus an optional hosted mail service. Its strongest parts are convenience for Zoom-centered teams, integrated calendar and meeting workflows, zmail.com addresses, custom-domain hosting on eligible plans, encryption options, and admin controls for business mail operations.
The decision point is not whether the inbox has normal email functions. It does. The decision point is whether putting mail and calendar into Zoom improves the working day enough to justify the permission, migration, DNS, compliance, and support work.
For any custom-domain rollout, Suped gives teams the cleaner operating model: monitor DMARC, detect SPF and DKIM failures, catch blocklist issues, receive real-time alerts, and manage hosted authentication records without turning every DNS change into a manual investigation.
