White label & custom domains
Share an email or a whole sandbox with a client under your own name: no Mailclutch branding, on a domain of yours such as sandbox.acme.com.
What your client sees
A share link opens a page anyone can read without an account: one email, rendered as it will arrive, or a whole sandbox. With white label on, nothing on that page names us:
- The page shows your organization's name and logo, and no “captured with Mailclutch” footer.
- The browser tab carries your name and your icon.
- The address is your own, for example
sandbox.acme.com/en/j4KxN2pQ…, once a domain is connected. - The email announcing the share is sent with your organization as the sender name and your logo instead of ours. The sending address itself stays a Mailclutch one, so that it keeps being delivered.
Password protection, expiry and revocation work exactly as on any other share link.
Connecting your domain
An administrator opens the organization's settings, finds the White label section and enters the hostname. Use a subdomain you do not use for anything else — sandbox.acme.com, share.acme.com, preview.acme.com. A root domain (acme.com) cannot be connected.
Then create one record at your DNS provider:
| Type | Name | Target |
|---|---|---|
CNAME | sandbox (for sandbox.acme.com) | cname.mailclutch.com |
# Check it from your terminal dig +short CNAME sandbox.acme.com cname.mailclutch.com.
The settings page checks the record on its own while it waits, asking your domain's own name servers rather than a cache, so it tells you straight away whether the record is missing, points elsewhere, or has been found. Once it is found, the HTTPS certificate is issued automatically, usually within a minute or two, and renewed without you doing anything.
DNS at Cloudflare? Create the record as DNS only (grey cloud), not Proxied. A second proxy in front of ours can keep the domain from validating, and once it is live, your zone's firewall, cache and redirect rules would apply to your share pages — one of them can block the certificate's renewal. The settings page warns you if it detects one.
Choosing when links are unbranded
Once the domain is active, administrators pick one of two policies for the organization:
| Policy | Behaviour |
|---|---|
| On by default | New links are unbranded and live on your domain. Whoever shares can switch white label off for one link; that link then keeps the Mailclutch branding and address. This is where every organization starts. |
| Always on | Every link is unbranded, including the ones already sent, and the switch disappears from the share dialog. |
Two more settings sit beside the policy:
- Also for the API and agents. Links created through the public API or by an agent over MCP have no white label parameter: under On by default they are unbranded only when this is on. Under Always on they always are.
- Replies go to the person who shared. Off, a reply to the announcement email reaches Mailclutch support. On, it reaches the sharer — whose address the recipients then see.
Good to know
- Links created before the domain was connected keep working on the Mailclutch address. Links are only moved to your domain when they are created.
- Removing the domain breaks the links already sent on it. New links go back to the Mailclutch address.
- The plan is checked every time a page is served. If the organization moves to a plan without white label, the branding comes back and the domain stops serving; upgrading again brings them back, with the same settings.
- The custom domain serves share pages only. Signing in, the inbox and the API stay on the Mailclutch application, and capture still goes through the regular SMTP credentials.