↗ MailGuyOpen workspace
WEBMAIL BETA · SETUP

Your domain.
Your inbox.

Connect a domain you own. Read, send and reply from your browser.

Open your workspace

Invitation only. Use your workspace ID and password. The service owner manages the mail infrastructure.

VerifyOne ownership record
ConnectService owner setup
Try itA real round trip

Open a step when you need it.

01 · Add your domain and address
  1. Sign in and choose Connect an address. Add your domain, such as yourdomain.com.
  2. At your DNS provider, add the exact TXT name and value shown in the workspace. Return and choose Verify ownership.
  3. After ownership is verified, create an address such as hello@yourdomain.com. A display name is optional.

TXT verification proves control of the domain. It does not change your existing mail records or connect receiving and sending.

02 · Complete the service connection

The service owner configures mail receiving, storage and the sending provider. Managed Webmail does not require you to deploy a server, supply a provider key or install a Chrome extension.

Use the channel that supplied your invitation to arrange this step. Follow the domain-specific DNS instructions you receive; existing MX and sender authentication records need review before any change.

An address saved in the workspace is not evidence that its mail route works. After configuration, complete the round-trip check below.

03 · Check your first real round trip
  1. From another inbox you control, send a unique message to your new address. Confirm it appears in Inbox.
  2. Open it and choose Reply. Check the From address and recipients, write a short response, and send once.
  3. Check the other inbox for the response and its actual From, Reply-To and SPF/DKIM/DMARC results. Check reply references when assessing threading.
  4. Use New message for a separate outgoing test. For Reply all, use test addresses you control and review the To and Cc fields before sending.

Sent means the sending provider accepted the request. Confirming that it arrived requires checking the recipient's inbox. This beta does not claim that your live mail path has already passed these checks.

Read, write and find your mail
  • Inbox: received mail for connected addresses. Opening a message marks it as read.
  • New message: select an owned From address and write plain text. To, Cc and Bcc are supported.
  • Reply / Reply all: the server prepares recipients and the original domain identity from the stored message. Review them before sending.
  • Sent: outgoing mail with a confirmed provider acceptance receipt.
  • Outbox: pending, unknown and failed sends that need review.

The reader displays plain text, including a text representation of HTML mail. It does not render the email's HTML or load its remote images. Download received attachments individually, or choose Download original for the received message's complete .eml. Shortened views are labeled; original downloads retain the source message.

Sending is unconfirmed? Review the original request

Pending is an unfinished request; Unknown has no confirmed outcome; Failed records an unsuccessful attempt. None is a delivery receipt.

  1. Keep the original request. Its draft remains locked while unresolved. Choose Check send status; checking does not send another copy.
  2. If you have left the composer, open the message in Outbox and choose Review pending send. This reads the saved request and restores its recoverable content.
  3. If it remains unconfirmed, ask the service owner to inspect provider activity before discarding it or composing another copy. Discarding only clears the local unresolved request; it cannot cancel delivery.

The current tab saves unresolved message content and its request key for recovery. Closing it may remove that local copy; a server-saved request can still be reviewed in Outbox. Ordinary unsent drafts are not a synchronized Drafts folder.

Beta limits
  • Received message: up to 2 MiB for the entire original email, including headers and encoded attachments; up to 20 attachments.
  • Workspace storage: 5,000 messages or 512 MiB, whichever is reached first. Stored message data and pending or failed records count toward the limit.
  • Sending: 100 attempts per rolling 24 hours per workspace. Provider limits may also apply.

Outgoing mail is plain text. Sending attachments, IMAP access and Gmail mailbox synchronization are not available. Read the service scope before relying on this beta.

Advanced · Legacy Gmail setup

For existing users who intentionally keep the earlier Gmail forwarding and bring-your-own-provider flow. These steps are separate from managed Webmail and are not required for the browser inbox.

Legacy · Receive domain mail in Gmail
  1. Your domain must already use Cloudflare DNS. Review existing MX before enabling Email Routing; changing them can affect an existing mailbox.
  2. Enable Email Routing in Cloudflare, add your Gmail destination, and complete its verification email. Use the records Cloudflare provides; review existing SPF before changing it.
  3. In the workspace, save that Gmail address, add the domain, and add an identity such as hello@yourdomain.com.
  4. If Cloudflare credentials are connected, choose Create routing. Otherwise choose Manual routing ↗ and create the rule in Cloudflare.
  5. Send to the domain address from another inbox you control. Confirm it reaches Gmail before registering your sending account.

Cloudflare setup ↗

Legacy · Connect your own SMTP2GO account
  1. Use an SMTP2GO account approved for your domain. Follow its current signup and verification requirements; eligibility is decided by the provider.
  2. Add and verify your sending domain in SMTP2GO. Use its exact SPF/DKIM records and review your DMARC policy. Do not add a second SPF record or overwrite existing records blindly.
  3. In Domains, enter the provider's DKIM selector and run Check DNS. Replace a provisional s1 with the real selector. DNS presence does not prove verification or delivery.
  4. In Account & access, save your SMTP2GO API key and refresh the connection status. Invited-workspace credentials are encrypted server-side. Never enter the provider key into Gmail or the extension.

This legacy flow uses your own SMTP2GO account through its HTTPS API. Check that account's current quotas and fees, including extra recipients and optional Gmail Bcc copies. A Bcc copy appears in Gmail's inbox; it does not create a Gmail Sent item or synchronize a thread.

SMTP2GO setup ↗ · Provider limits ↗

Legacy · Install the Chrome companion

Use a separate compose window alongside desktop Gmail. The extension does not intercept Gmail Send, Reply, shortcuts or drafts, import attachments, or create Gmail Sent items.

Download pilot extension
  1. Extract the ZIP. Open chrome://extensions, enable Developer mode, choose Load unpacked, and select the extracted extension directory.
  2. Copy its actual ID. In Account & access, save chrome-extension://YOUR_ID, rotate an extension token, and privately save its one-time display.
  3. Open the extension. Enter the deployed workspace's origin and extension token, grant access to that origin, and load your identities. The token authorizes sending; do not use your SMTP2GO key here.
  4. Open the persistent compose window. Confirm From, recipient, subject and message before selecting Send independently.

Prepare a reply

On Gmail, use the extension's Enable Gmail reply button action. Expand exactly one message's recipient details, choose Reply with domain, then confirm Use this visible reply in the separate composer. Layout or language changes may prevent a match.

For original Message-ID and References, copy only the raw headers from Gmail's Show original into Prepare reply. Visible To details cannot reliably supply those headers. One clear To identity may be selected; Bcc, missing or ambiguous identities require your choice. Review the recipient and From yourself. This is a simple reply, not Reply all, and never sends automatically.

Legacy · Service owner setup

For owners maintaining the legacy Gmail flow only. The owner deploys the service and creates invitations using the repository README. The settings below do not provision the managed Webmail receiving or storage service.

Required Worker secrets
ADMIN_PASSWORD    At least 16 characters
SESSION_SECRET    At least 32 characters
TENANT_KEK        Independent 32-byte base64url key

Owner sending
SMTP2GO_API_KEY

Optional routing controls
CLOUDFLARE_API_TOKEN
CF_ACCOUNT_ID

Owner extension
EXTENSION_ORIGIN
EXTENSION_TOKEN

For selected zones, the Cloudflare token needs Zone Read, Zone Settings Read and Email Routing Rules Edit, plus account Email Routing Addresses Read. DNS Edit is not required. The owner configures Worker secrets; invited users save their own credentials in Account & access. Never paste provider keys into Gmail or the extension.

Use the actual chrome-extension://YOUR_ID for the owner's extension origin and a private token of at least 32 characters. The owner can reset passwords, revoke sessions or disable workspaces. These actions do not cancel external billing or forwarding.

For a legacy round-trip check, confirm the incoming message in Gmail, send independently to another inbox you control, then verify that its reply returns to Gmail. The extension prepares a simple reply; it does not provide Webmail's Reply all.

If a legacy send is unconfirmed, keep the original workspace and request key, use Check stored receipt, and inspect your own provider activity before discarding it. The extension keeps recovery data in its own local storage. Neither recovery nor discarding recalls a message already accepted by the provider.

Service scope and billing ↗