Why your own domain serves your links and never a sign-in page

A link that reads share.yourcompany.com tells the person receiving it who sent it before they click. That is worth having, and it creates a question most people never think about: once a hostname you control points at our service, what should that hostname be allowed to show?

Nemi's answer is short. Your domain serves the public links your workspace sends, and nothing else. Not the app, not your settings, and above all never a page that asks anybody to sign in. This post explains why, and how each part of that is enforced.

What does a custom domain for file sharing serve?

Everything a person outside your workspace is meant to open: share links, upload links, published documents, forms, embeds and rooms. The front door, the bare hostname with no path, opens the workspace owner's folio if they have published one. Every other address on your hostname is answered with a permanent redirect to the same address on nemilab.com.

That is an allowlist, not a blocklist, and the difference is the whole design. A blocklist would name the dangerous pages and let everything else through, so every page we add in the future would appear on every customer's domain until somebody remembered to block it. An allowlist starts from no. A new page is invisible on custom domains until it is added on purpose, and the list says, next to each entry, why that page is safe to serve from a hostname we do not control.

Is a custom domain a phishing risk?

It would be if it could show a sign-in page, because a sign-in form on a hostname we do not control is a password prompt on somebody else's domain. Think about what that would teach people. If a Nemi sign-in screen could legitimately appear on share.anycompany.com, then a Nemi sign-in screen on share.anycompany-invoices.com would look just as legitimate, and the one habit that protects people from phishing, checking the address before typing a password, would stop working for everybody who uses Nemi.

So the rule is one a person can check without knowing anything about how we work: you only ever sign in to Nemi on nemilab.com. Any request on a custom domain that has anything to do with signing in is sent to the sign-in page on nemilab.com. The session itself cannot follow you there either: the cookie that keeps you signed in belongs to nemilab.com, so a custom domain never carries a signed-in session at all. The folio editor is a good example of the line. Your public folio page can be served on your domain; the editor for it cannot, because the editor needs you signed in.

Can another company's links appear on my domain?

No. The allowlist decides what kind of page a custom domain may serve; it cannot know whose link a particular address is, because the proxy that applies it runs before the database is consulted. So every link page makes a second check of its own: it looks up which workspace the link belongs to and compares it with the workspace that owns the hostname. If they differ, the page is not served under your name. It redirects to the same link on nemilab.com.

Without that check, anybody could take a link from their own workspace, swap the hostname for yours, and have their file appear under your brand. A domain serves its own workspace's links, and only those. The same rule covers the front door: a custom domain serves exactly one folio, the workspace owner's.

Your domain is a front door to your links. It is never a way into the app.

Who issues the HTTPS certificate?

A domain needs a certificate before a browser will open it over HTTPS, and you never have to get one yourself. The first time somebody opens your hostname, our web server asks Nemi whether this hostname belongs to a verified domain whose workspace owner is still on a plan that includes it. Only if the answer is yes does it request a certificate from Let's Encrypt, on the spot.

That check fails closed. Pointing DNS at us achieves nothing on its own: a hostname nobody verified gets no certificate, and without one a browser shows no page at all. Verification itself needs two DNS records, one that proves you control the name and one that sends its traffic to us, and both have to be right.

Two honest details. A certificate is public by design: every certificate issued on the web is written to Certificate Transparency logs, so a domain you connect becomes a public fact. All Let's Encrypt receives from us is the hostname. And the check does not stop once the domain is live. Every night, Nemi re-checks each live domain, and one whose records have gone or whose owner's plan no longer includes domains is switched off, and its links go back to nemilab.com.

What happens if the plan changes?

A custom domain is part of Creator, Pro, Max and Business. A workspace runs on the plan of the person who owns it, so the domain comes from the owner's plan, whoever in the workspace sends the link. That plan is not stored on the domain. It is looked up again every time it matters, so nothing can be left behind in a stale state.

If the owner moves to a plan without domains, or you disconnect one, every link falls back to nemilab.com and none of them break. Connecting a domain is just as quiet: links created before it keep their nemilab.com address and keep working, and new links use your domain from the moment it goes live.

How do I send links from my own domain?

You need to be the workspace owner, on Creator or above (only the owner may connect a domain, one of the few things no other role can do), and able to add records at your DNS provider. Use a subdomain you are not using for anything else, such as share.yourcompany.com or files.yourcompany.com. A bare domain cannot be pointed at Nemi with the record this needs, and pointing it here would take your website down.

1. 1

   Open the workspace switcher and manage the workspace

   At the top of the sidebar. The Domain tab is next to General, Limits and Members, and only the workspace owner sees it.
2. 2

   Type the subdomain and press Add domain

   Nemi shows you the two DNS records to create.
3. 3

   Create both records at your DNS provider

   A TXT record that proves the domain is yours, and a CNAME record that sends visitors to Nemi. Copy the values exactly.
4. 4

   Press Check DNS

   If a record is not visible yet, wait and press it again: DNS changes usually spread within minutes but can take up to an hour. As soon as this passes, new links use your domain.
5. 5

   Wait a few seconds for Live

   Nemi opens your domain once in the background to set up the HTTPS certificate, and the tab then reads Live.

The full guide is in the help centre, the plans are compared on the pricing page, and everything a link can do is on the Files page. What a visitor to a link on your domain has recorded about them is set out in the privacy policy: the same as on any other link, which download statistics without tracking explains in full.