Pointing a subdomain at a private-link host so the URL says your brand, not the vendor's. Steps, DNS gotchas, and when the apex vs subdomain choice matters.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.
The client opens the link from Friday's email. The page loads. They notice the work, then notice the URL bar at the top of the browser. The URL has a host they don't recognize and a random-looking string after the slash.
Sometimes this is fine. For an internal review document with no external audience, the URL hardly matters. For a client-facing deliverable that's part of the studio's professional surface — the case study they'll reference for the next twelve months, the portfolio piece they show prospects — the URL is part of what they're paying for.
The fix is one DNS record and ten minutes of configuration.
Three things, in the order they hit the client:
First impression of the link. A URL at previews.studio.com reads as the studio's own infrastructure. A URL at someservice.io reads as a third-party tool the studio uses. The work is the same; the framing around the work is different.
Trust on hover. Some clients hover over a link before clicking, especially in corporate environments where security training has made everyone slightly suspicious of unfamiliar domains. A URL at the studio's known domain clears that check; an unknown host adds a half-second of doubt.
Forwarding within the client's org. The client forwards the link to a stakeholder. The stakeholder evaluates the link in their inbox before clicking. A familiar-looking domain (the studio they're already engaged with) is more likely to get clicked than an unknown vendor subdomain.
None of these are dramatic alone. Together they're the difference between the deliverable reading as finished work product and reading as output from a tool the studio uses.
Most private-link hosts that support custom domains use the same setup pattern. Specific UI varies by vendor; the underlying mechanism is consistent.
Common patterns, in rough order of preference:
previews.studio.com — for an agency or design studio shipping client previewsshare.studio.com — generic, works for most teams shipping deliverablesdeliverables.studio.com — explicit, reads as professional in a client's inboxreports.studio.com — for consulting shops shipping report deliverablespitch.studio.com — for fundraising-focused use (decks specifically)Avoid using the apex (studio.com itself) for a link host. The apex usually serves the main marketing site; pointing it at a link service requires moving the marketing site somewhere else or running both behind a complex routing layer. A subdomain is cheaper and reversible.
In the DNS provider's dashboard (Cloudflare, Namecheap, Google Domains, Route 53, wherever the domain is hosted):
previews (the subdomain part only — not the full domain)links.vendor.com or whatever the vendor's docs specify)For Cloudflare specifically, set the proxy status to DNS only (the gray cloud) during initial setup. The vendor's SSL provisioning works against the direct DNS resolution; the orange-cloud proxy interferes with the verification handshake. Once the link is working, the proxy can usually be turned back on, depending on the vendor.
After the DNS record is saved, the vendor's dashboard usually has a "Verify" or "Connect" button. Click it. The vendor's system queries DNS, confirms the CNAME points correctly, and starts the SSL certificate provisioning.
SSL provisioning typically takes 1–10 minutes; most vendors use Let's Encrypt under the hood, which is automatic. The dashboard updates from "Provisioning" to "Active" when the certificate is ready.
If verification fails, the usual culprits:
The link works for the studio first because the studio's DNS cache is warm. The real test is opening the link from a network the studio doesn't control — phone on cellular, a friend's laptop, an incognito window with a VPN to a different region.
If the link resolves and the SSL padlock shows in all three, the setup is complete. The next deliverable shipped goes to the new subdomain automatically.
Test the underlying flow first — drop a sample HTML at the default URL, walk through the client experience, decide whether the custom domain is worth the setup. Free, no card, the file self-destructs after 7 days.
Apex domain (studio.com directly pointing at the link host) sounds cleaner but creates two practical problems:
The exception: studios whose primary work is the deliverable itself (e.g. a consulting practice whose website is essentially a portfolio of reports) might genuinely want the apex pointing at the link host. For most use cases, a dedicated subdomain is the right shape.
For a private link with custom domain configured:
previews.studio.com/<unguessable-slug>.Behind the scenes, the link host is still serving the file — the custom domain is just a CNAME alias for the host. From the client's perspective, the studio runs the infrastructure.
The same framing question shows up in agency preview workflows and designer client handoffs — the URL is small, the custom domain is what makes it not feel small.
Custom domain ships on the Studio plan ($14.99/mo) — the link lives at your subdomain, the footer is removed, and per-document searchable opt-in lets specific deliverables (case studies, public portfolio pieces) become indexable while the rest of the account stays default-private.
Custom domain isn't full white-labeling. The link host's brand may still appear in some places:
For most client-facing flows, only the deliverable URL matters — which the custom domain handles. Full white-label setups (where every surface the studio touches reads as the studio) typically require enterprise tiers and aren't usually worth the cost for indie studios and small agencies.
The right framing: custom domain solves the deliverable URL specifically. That's usually the surface the client sees and judges. The rest of the host's surface is internal and unaffected.