Every domain.
A clear home.
Manage domains, mailboxes, aliases, and quotas in a dedicated administration workspace. See who has access before opening an inbox.
Understand domain setupA WORKSPACE FOR YOUR DOMAINS
Business email.
Under your
control.
Your domains, conversations, and website sending belong together. Meet a clear, carefully managed workspace built around the way you work.
Local implementation available.
Public email hosting is not yet open.
your-brand.example01
A little more clarity.
YOUR WORKSPACEIllustration
InboxDraftsSent3 sample messages
Inbox access follows explicit permissions.
Your website has its own key.Scoped access. Visible sending limits.
Illustrative preview · fictional addresses · no live mail
YOUR IDENTITY, ACROSS EVERY DOMAIN
Multi-domain control
A focused inbox
Private Email API
BUILT AROUND YOUR WORK
One place for the email
behind your business.
For owners managing several brands, small teams sharing a conversation, and developers connecting their websites. Keep the everyday work close, with the controls that matter.
Every domain.
Less searching.
More context.
Compose, save drafts, reply, organize folders, and search locally stored messages. Shared inboxes add assignment, status, and notes.
See the interfaceYour websites.
Their own identities.
Issue scoped API keys, set recipient limits, schedule sends, and inspect per-recipient outcomes. Keep every credential on your backend.
Explore website sendingThese features are implemented in the local workspace. Production transport, public mailboxes, and client connections have separate readiness gates.
A CLOSER LOOK
Room to focus.
Nothing important hidden.
A familiar inbox and a considered control center. Message access, domain administration, and website credentials each have their own place.
Actual local application screenshot
01 / ORGANIZE
A familiar daily rhythm
Inbox, Sent, Drafts, Archive, Spam, and Trash. Read flags, search, and bulk actions keep stored conversations manageable.
02 / COORDINATE
Shared, with intention
Assign conversations and record internal notes. Explicit grants define who may read, change, or send from a mailbox.
03 / UNDERSTAND
Evidence over assumptions
Local capture, relay acceptance, failures, and uncertain outcomes stay distinct. A submitted message is never called a confirmed inbox delivery.
A DELIBERATE START
Connect with confidence.
Move when you're ready.
Your existing mail deserves a careful transition. The setup path makes each dependency visible before a live change.
- 01
Map your domains
Identify the domains, mailboxes, aliases, and websites that already send email. Preserve the current provider and records.
- 02
Verify your identity
For API sending, publish the exact ownership TXT and DKIM values. Check observed DNS before enabling production sending.
- 03
Set clear permissions
Create local mailboxes and individual users. Grant inbox and sending access explicitly, then set quotas and application limits.
- 04
Prove the full journey
Verify transport, durable receiving, backup recovery, and the clients you need before changing live MX or moving historical mail.
A domain connection is not a mail migration. Live receiving, historical import, and external delivery remain separate acceptance steps.
View readinessFOR THE WEBSITES YOU BUILD
A private API.
A visible journey.
Connect website notifications through a backend credential scoped to the right sender. Keep the business logic on your site, and the delivery trail in one workspace.
- Separate accounts and restricted keys
- Daily, monthly, and per-minute recipient quotas
- Idempotent requests, scheduling, and cancellation
- Suppression controls and observable events
A request from your backendExample
POST /api/v1/emails
Authorization: Bearer [server-side key]
Idempotency-Key: [saved request ID]
{
"from": "hello@your-domain.example",
"to": ["recipient@example.com"],
"subject": "A little update",
"text": "Your message starts here."
}QueuedTransport resultRecorded
Illustrative request, not a live API endpoint. Local capture does not send to the Internet. Production sending needs a verified domain and a configured, tested transport.
ACCESS, WITH BOUNDARIES
Private work.
Explicit permissions.
Security is a set of controls you can inspect. These safeguards are implemented locally; they do not replace deployment review or ongoing operation.
Website data & privacyIndividual sign-in and MFA
Password hashing, HTTP-only sessions, CSRF checks, sign-in throttling, and optional authenticator-based two-factor authentication.
Administration is not inbox access
Mailbox reading and sending require explicit grants. Application keys are scoped, revocable, and shown only when created.
Untrusted mail stays untrusted
HTML is sanitized and rendered in a restricted frame. Remote message content is blocked by default; attachment downloads require authorization.
KNOW WHAT YOU'RE CONNECTING
Clear capabilities.
Clear limits.
Webmail, API sending, and full mailbox hosting are different capabilities. Here is where the current implementation stands.
| Capability | Current status | What to expect |
|---|---|---|
| Browser workspace | Implemented locally | Responsive webmail, administration, folders, drafts, contacts, and shared workflows. |
| Website sending API | Implemented locally | Restricted backend keys and local capture. Internet sending requires transport and DNS acceptance. |
| Public incoming mail | Production pending | Live MX routing and durable cloud mailbox storage must be verified before migration. |
| Outlook, Apple Mail & other clients | Not yet supported | Production IMAP, POP3, and authenticated TLS SMTP submission are not currently available. |
| Message size & storage | Explicit limits | Local rendered messages: up to 10 MiB. Attachments: up to 7 MiB total before MIME encoding. Configured storage quotas apply. Production providers may impose lower limits. |
| Migration & recovery | Separate checks | Local backup/restore tooling exists. Historical provider migration and production recovery need environment-specific verification. |
No unlimited usage, public signup, payment plan, or guaranteed inbox placement is offered. Spam and malware scanning require an actual connected scanning service.
A FEW USEFUL ANSWERS
Before you connect.
Practical questions deserve straightforward answers.
Can I use email addresses on my own domain?
That is the product's purpose. The private sending service generates domain ownership and DKIM records. Local mailbox development uses isolated test domains. A public mailbox on your domain still requires a verified production receiving and storage setup.
Will connecting a domain change my existing email?
Adding a domain in the workspace does not change live DNS. Any MX change must follow a separate migration plan, capacity check, backup, and tested rollback. Keep your current provider until the receiving and sending checks pass.
Can I send emails from my website?
The private Email API supports scoped server-side credentials, quotas, scheduling, and delivery records. The local default captures messages without Internet delivery. Production sending requires a verified sender domain and configured transport; a submitted request alone does not confirm receipt.
Does EGETY E-mail work with Outlook or Apple Mail?
The current local product offers browser webmail. Production IMAP, POP3, and TLS SMTP submission are not yet available, so desktop and mobile mail-client compatibility is not currently claimed. Do not replace an existing client setup before these protocols are supported and tested.
Can I move my historical messages?
Historical migration requires access to the source provider, capacity planning, a supported import path, and reconciliation of folders, timestamps, flags, and attachments. An MX switch does not import old messages. No historical migration is implied by this website.
How are access and recovery handled?
The owner creates individual accounts and explicit mailbox grants. Optional authenticator MFA protects sign-in. Local backup and recovery tooling is included; production backups, recovery access, and restoration must be configured and verified for the actual deployment.
How do I get access or ask about setup?
Start with the setup planner below. Its current mode is displayed before you provide information. When protected intake is enabled, a confirmed submission goes to the project owner for review; it does not create an account. Otherwise, you can save a local brief. Public self-service signup is not open.
START WITH A CLEAR PLAN
Your next domain.
Your next step.
Tell the planner what you need. Review your setup brief, understand the dependencies, and keep the next move deliberate.
Local brief mode
Nothing is submitted. Your entries stay in this page until you copy or download the brief. No account is created.
Do not include passwords, API keys, private messages, or mailbox exports.