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.

What v1 covers

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

Public pages only. A private page, a page shared by email, and an archive stay on sharedrop.cloud. Only a page whose visibility is public or shared is delivered from your domain.
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

Open Dashboard > Settings > Custom domains and enter your base domain, for example yourcompany.com.
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.

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.