Custom domain and email
Org Management → Overall Settings → Custom Branding holds two things that both make the platform look like yours rather than like ours: the address people visit, and the address your mail comes from.
Both are administrator-only.
Custom domain
Out of the box your organisation is at yourorg.rukialabs.com. You can move it
to a hostname you own — learn.example.com, say.
How it works
Three states, and the middle one is where most of the time is spent:
| State | Meaning |
|---|---|
| None | No custom domain |
| Pending | Claimed, not yet verified. Routes nothing |
| Verified | Live. This is the address people use |
A claimed domain routes nothing until it is verified. That is the point of the process: the platform will not answer for a hostname before somebody has demonstrated they control it.
The steps
- Claim the hostname. Type it and save. The panel then shows you the DNS records to publish.
- Publish the records with whoever runs your DNS. There are three: one that routes traffic, one that proves you own the name, and one for the SSL certificate.
- Verify. The platform looks the records up in public DNS. If they are all there, the domain goes live.
Verification checks public DNS, deliberately. It means "the world can see this", not "our server can".
Timing
DNS changes take time to propagate — usually minutes, sometimes hours. If verify fails immediately after publishing, wait and try again rather than re-editing the records.
Some DNS providers flatten or proxy records in ways that change how they resolve. The verifier handles the common cases, but if you are behind a proxying provider and verification keeps failing on a record you can see in your own dashboard, that is the direction to look.
Once it is live
Everything moves: the consoles, the sign-in page, the documentation, share links.
The old yourorg.rukialabs.com address continues to work.
Tell your members. A bookmark to the old address still works; a bookmark saved mid-move may not.
Removing it
Detaching returns you to the platform subdomain and releases the hostname. Existing share links pointing at the custom domain stop resolving, so this is worth thinking about before publishing anything externally on a domain you are not sure of.
Outgoing email
By default the platform sends your transactional mail — invitations, password resets, notifications — from its own address. You can send from your own instead.
Two options, either of which can be switched on:
SMTP. Your own mail server. Host, port, username, password and the address to send from.
Resend. An API key from Resend, and the address to send from.
Send a test first
The panel has a send a test email control. Use it before you rely on the configuration, because the failure mode here is silence — an invitation that is never delivered looks identical, from the admin console, to one the recipient simply has not opened yet.
Why this is worth doing
Three reasons, in the order they will bite you:
Deliverability. Mail from an address at your own domain, correctly authenticated, lands in inboxes. Mail from a platform nobody recognises lands in spam, and every "I never got my invitation" is this.
Recognition. People act on mail from an organisation they know.
Replies. Somebody replying to an invitation should reach you.
If you do configure your own sending, set up SPF and DKIM for the sending domain with whoever runs your DNS. Without them, sending from your own domain can be worse for deliverability than the default, because the mail now claims to be from a domain that has not vouched for it.
Sign-in with Google and GitHub
Social sign-in is a platform capability and your organisation inherits it. If it is available, the buttons are on your sign-in page already; there is nothing to configure.
An organisation that wants to use its own Google or GitHub application can register one, which takes over for that provider and leaves the others inherited. That is a configuration conversation with whoever operates the platform for you rather than a setting on this screen.