Custom domains

A custom domain lets a public Sharedrop page arrive on a subdomain you own instead of sharedrop.cloud. The recipient opens https://share.yourcompany.com/yourhandle/abc123, and the sandboxed document behind it loads from https://view.yourcompany.com. Nothing else about the page changes: same content, same sharing controls, same sandbox.

Custom domains are self-serve at A$8 per domain per month, with one included on Team. You agree to the charge when you add the domain, and billing starts then, not when the domain goes live. It stops when you remove the domain. Some domains are fee waived by the operator, in which case nothing is charged for that domain.

Personal and Team workspace domains

A custom domain belongs to the account you are working in when you add it.

In your personal account, the domain is yours. It serves the pages you own, and any charge goes on your own subscription.
In a Team workspace, the domain belongs to the workspace. It serves the workspace's pages and uses the workspace's plan, including the one domain Team includes. Any charge goes on the workspace's subscription, never on a member's personal plan, and the domain stays with the workspace when people join or leave.
Only the workspace owner can add, remove, refresh or brand a workspace's domain. Other members see a note saying so instead of the setup form.

To manage a workspace's domain, switch to that workspace first, then open the custom domain settings.

What v1 covers

Read this list before you set anything up. It is deliberately narrow.

Public and shared pages only. A private page and an archive stay on sharedrop.cloud. A public page opens on your domain for anyone. A shared page opens on your domain too, but only after the visitor signs in on sharedrop.cloud and Sharedrop confirms they are allowed to see it: the page owner, a member of the workspace that owns it, or someone the page was shared with by email. Everyone else gets nothing, and access is rechecked on every request, so removing a person cuts them off straight away.
Subdomains only. You bring share.yourcompany.com and view.yourcompany.com. A root domain (yourcompany.com) is not supported.
Two hostnames, always as a pair. The share hostname serves the page, the view hostname serves the sandboxed document. Both are required. One without the other does not go live.
Exactly two records. Add one CNAME for share and one CNAME for view. Sharedrop uses those CNAMEs to validate the hostnames and issue certificates over HTTP.
Cloudflare-proxied zones must set both CNAMEs to DNS only. In the Cloudflare dashboard that is the grey cloud, not the orange one. A proxied record is the single most common reason setup fails.
The recipient never changes hostname. Once a page is delivered from your domain, every link, asset and redirect in that visit stays on your domain.

Set it up

In the account or workspace that should own the domain, open Dashboard > Settings > Custom domains and enter your base domain, for example yourcompany.com.
Sharedrop shows you what this domain costs and asks you to agree before it creates anything. Choose Agree and add domain to continue, or Cancel to go back.
Sharedrop shows you exactly two records: a CNAME for share and a CNAME for view. Add both at your DNS provider exactly as shown.
Leave the records in place. Sharedrop rechecks them every few seconds and moves the pair through Waiting for DNS, Validating, Pending review, and finally Live.
Pending review is a Sharedrop-side check. There is nothing for you to do, and the pair goes live on its own once the review is done.

If a pair ends up Failed, the usual cause is a proxied CNAME. Switch both records to DNS only and refresh.

Where the branded URL shows up

Once a pair is live, the branded address is what every surface hands you for an eligible page.

Dashboard. The page detail view shows a "Served from" badge next to the address, and the page list and table label each branded row. The copy button copies the branded URL.
CLI. sharedrop upload, sharedrop list and sharedrop get print the branded URL, and --json puts it in data.full_url.
API. Page, reservation and share responses return the branded address in full_url. The relative url field is unchanged.
MCP. finalize_upload, get_page, list_pages and update_page return the branded address in url.

A page that is not eligible, for example a private page or an archive, keeps its sharedrop.cloud address on every one of those surfaces. Nothing you have already shared breaks.

Authenticated traffic stays on Sharedrop

Your API keys, the CLI and the MCP server keep talking to sharedrop.cloud. Your domain carries recipient traffic only. There is no separate endpoint to configure and no key to move.

Brand the verification page

When you share a page by email, the recipient has to prove they own that address before the page opens. That one step happens on sharedrop.cloud, not on your domain. It is deliberate: a sign-in form on a hostname whose DNS you control could be repointed, and anyone who did that would collect your recipients' sessions. So the check stays with us, and you brand it instead.

Open Dashboard > Settings > Custom domains and use the Branding card:

Logo: PNG, JPEG or WebP, up to 512 KB. SVG files are not accepted because an SVG can carry script. Without a logo we show your display name instead.
Accent colour: a six-digit hex value, used for the button and your name. It has to stand out on both the light and the dark page, so a colour that is nearly white or nearly black is refused with a message rather than shipped unreadable.
Display name: up to 60 characters, defaulting to your account or workspace name.

The preview beside the form is the real page header, so what you see is what a recipient gets.

The page tells the recipient who shared the file, that Sharedrop only checks they control the email address, and that you see their address and nothing else. It asks for an email code rather than offering a signup, and Google stays available as a shortcut. A "Secured by Sharedrop" footer is always present and cannot be removed.

Branding belongs to whoever owns the domain, your account or the workspace, and applies to every page shared from that domain. Nothing about the page or the recipient is exposed by it: the verification screen shows your public identity only.

Remove a domain

Removing a pair from Dashboard > Settings > Custom domains deletes both hostnames. Pages served from them fall back to their sharedrop.cloud address immediately, so any branded link you sent earlier stops resolving. Send the standard link instead, or set the domain up again.

On this page