Put your own domain on every link you share

There's a moment in every deal where you paste a link into an email to someone who has never heard of the tool you used to make it. They see a domain they don't recognise, wrapping a document you say is important.

Shortener domains have a reputation problem, and it isn't unearned — they're what phishing uses, because hiding the destination is the point. Corporate mail filters know this. Some of them rewrite short links, some flag them, and some recipients simply don't click.

docs.yourcompany.com/q3-proposal has none of those problems. Same tracking, same controls, none of the hesitation.

Setting it up

Three steps, and DNS is the slow part.

Add the domain. In Dashboard → Domains, enter the hostname you want to use — a subdomain like docs.acme.com or share.acme.com is the usual choice. Using a subdomain rather than your apex keeps your main site completely untouched.
Point a CNAME at us. The domains page shows the exact record to create. Add it at your DNS provider.
Verify. Click verify on the domains page. Once the record has propagated — usually minutes, occasionally an hour — the domain goes live and we issue and renew the TLS certificate automatically. There is nothing for you to install or rotate.

From then on, new links can be created on that domain, and it's an option on every link you make.

Custom domains are a Pro and Team feature — see pricing.

Making it look like yours

The domain is the biggest signal, but the page the recipient lands on matters too. Per link, you can set:

Your logo on the viewer, replacing ours.
A brand colour, which drives the accents on the viewing page.
No slim.to badge — remove the attribution entirely.

There's also a sender display name for notification emails, in Settings, so the mail your recipients get about a document reads as coming from your company rather than ours.

The result is a document viewer at your domain, in your colours, with your logo, that a recipient has no particular reason to identify as third-party software.

Link previews

When someone drops the link in Slack, or posts it, or sends it in an email that renders previews, the unfurl is generated from the link's own Open Graph metadata — title, description and image, derived from the destination page or the uploaded file, and overridable per link.

That's worth checking before you send anything important. A branded domain with a broken preview card is worse than no preview at all.

Picking a hostname

A few things learned the hard way:

Use a subdomain you don't otherwise need. docs., share., go., read. are all fine. Don't reuse a hostname that already serves something.
Short is better, but clarity beats brevity. go.acme.com is elegant; docs.acme.com tells the recipient what they're about to open.
Keep it stable. Links you've already sent live at the domain they were created on. Changing your mind later means old links pointing at a hostname you've stopped using.
One domain is usually enough. Multiple domains make sense for genuinely separate brands, not for separating internal and external sharing — that's what access control is for.

From an assistant or a script

Once a domain is verified, domain is just an argument. From an AI assistant connected over MCP:

"Publish that on docs.acme.com and give me the link."

Or from the API:

curl -s -X POST https://slim.to/api/v1/links \
  -H "X-API-Key: $SLIMTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"target_url": "https://example.com/pitch",
       "title": "Pitch deck",
       "domain": "docs.acme.com",
       "slug": "pitch"}'

The domain must already be verified in the dashboard — the API won't create one for you, which is deliberate, since it requires a DNS change you have to make anyway.