A Custom Domain for Your Mess, in Two DNS Records

Every workspace gets an address the day it is created: acme.eazymanage.app. It works, it is memorable enough, and for most messes that is the end of the story. But if you already own a domain — the one on your signboard, or one bought for exactly this — your workspace can answer there too. Same workspace, same data, a hostname you chose.

An extra door, not a replacement

This is the part worth getting straight before you touch DNS: a custom domain is an alias. Your eazymanage.app address does not go away, does not redirect, and does not stop working. It stays the canonical one, and every email link, every notification link and every invite still points at it.

That is deliberate, and it is a safety property rather than an oversight. DNS breaks: a registrar lapses, a record gets edited by someone tidying up, a zone gets moved. If the custom domain were the only way in, a mistake in someone else's control panel would lock a workspace away from its own bills. With the subdomain still live, the worst case is that one address stops resolving while everything else carries on.

Two records, and what each one is actually for

Open Settings → Workspace → Domain, type the domain you own, and the panel hands you two records with copy buttons next to each:

• A TXT record on _eazymanage-challenge.yourdomain.com, carrying a verification token. This one proves control: only somebody who can publish inside your zone can put that value there, which is what stops another workspace from claiming a domain that isn't theirs.
• A CNAME on the domain itself, pointing at the target shown in the panel. This one carries the traffic.

Add both at your DNS provider, come back, and press Verify. The panel checks both and tells you which record it could not find yet, naming the exact host — not a generic failure.

Why only one of them gates activation

The domain goes active when the TXT check passes. The routing check runs, and its result is reported, but a routing check that comes back unhappy does not block you. Three reasons, and the third is the practical one:

1. Ownership is the security-relevant check. Routing proves nothing about who owns a domain.
2. Routing proves itself. If DNS doesn't point at us, the site simply doesn't load — there is no failure that waiting would have prevented.
3. Routing is often invisible from our side. If your domain sits behind a proxy like Cloudflare, it resolves to the proxy's addresses, not ours, and a perfectly working setup looks identical to a broken one. Blocking on that would lock out every CDN-fronted mess permanently, so "couldn't tell" is reported as exactly that, not as an error.

DNS also takes its time. A record you added two minutes ago genuinely may not be visible yet, and the message says so rather than implying you typed it wrong.

HTTPS you don't have to think about

Once the domain verifies, its certificate is issued automatically. There is nothing to buy, upload or renew, and no key material for you to keep anywhere.

A working domain is never switched off by a bad check

If you re-verify an already-active domain and the lookup fails, the result is recorded — and the domain keeps serving. It is not downgraded, and members see nothing.

"A failed check should turn it off" sounds like the careful choice, and it is the opposite. DNS lookups fail transiently all the time, from one vantage point, for a minute. Treating that as proof of a broken domain would take a live workspace's address offline over a blip. Removing a domain is something you do on purpose, from the same panel.

What this doesn't include

We don't sell or register domains — bring one you already own. It's one domain per workspace, and it hosts the workspace, not your email; your mail stays wherever it is today. And connecting one needs no new role: anyone who can already edit workspace settings — the same permission as renaming the workspace — can do this too.

Read more about running the workspace on your own domain, or see what it costs — free while in beta.