Email sender, custom domain & member accounts
Everything your workspace sends — payslips, letters, leave notifications, careers-site invites — goes out under an email identity, and your people sign in to a web address. By default both carry Operentra's platform branding. On Workspace Settings you can personalize the sender identity, move the whole workspace onto a domain you own (on eligible plans), and set the sign-in policy for your members' accounts.
Open Workspace Settings from the admin sidebar (route /admin/settings/workspace).
Alongside the Overview, the page has four tabs — Language, Email sender,
Custom domain, and Member accounts. You need the Workspace settings
permission to see it.
Language
The Language tab holds the workspace's two language settings:
| Setting | What it controls |
|---|---|
| Default email language | Emails to employees who have not chosen their own language, and to recipients who are not employees. Each employee can pick their own from the portal (My Profile) or the prompt shown after switching the interface language. |
| Document language | The language contracts, HR letters, salary slips and tax certificates are issued in — workspace-wide, because documents of record are archived and produced to authorities. |
See Languages & localization for the full model, including how per-recipient email language is resolved and what happens when a template has no variant in the chosen language.
Email sender
The Email sender tab controls the "From" identity on emails your workspace sends. There are three things you can set:
| Field | What it does |
|---|---|
| Sending address | The part before the @ in the from address (the "local part"). |
| Sender name | The display name recipients see next to the address. |
| Reply-to address | Where replies are delivered when someone hits Reply. |
At the top of the tab, an Emails will be sent from card previews the exact From header that will be used, plus the reply-to if you set one — so you can see the result before saving.
What the operator controls vs. what you control
The email transport (the SMTP server) and the sending domain are owned by the platform operator, not by your workspace. You personalize only the local part, the display name, and the reply-to.
- Before the operator enables custom sending addresses, the Sending address and Sender name fields are disabled and email goes out from the platform default identity. An amber notice on the tab explains this. You can still set a reply-to — replies will go there regardless.
- Once the operator has configured a sending domain (and the matching SPF/DKIM DNS —
see Operator responsibility below), the
fields unlock and your From address becomes
you@the-operators-domain.
To set your sender identity
- Go to Workspace Settings → Email sender.
- In Sending address, type the local part you want (the text before the
@). Use letters, numbers, dots, and hyphens. Leave it blank to use an automatic slug derived from your workspace name. - In Sender name, type the display name recipients should see (for example your company name). Blank falls back to the platform default name.
- In Reply-to address, enter the mailbox that should receive replies (for example
[email protected]). Blank means no reply-to header is added. - Check the Emails will be sent from preview, then click Save.
Saved changes apply to new emails; messages already sent are unaffected.
Because every workspace shares the operator's single sending domain, each Sending address (local part) must be unique across the platform. If the one you pick is already taken by another workspace, the save is rejected and you'll be asked to choose a different one. A blank local part with an odd workspace name that has no usable characters is also rejected.
Custom domain
The Custom domain tab lets you serve the entire workspace from a domain you own —
for example hr.yourcompany.com. When active, your people sign in there, email links
point there, and your careers site lives there, all under your own brand with SSL
included.
A subdomain such as hr. is recommended. Your root domain (yourcompany.com) usually
already hosts your public website, and pointing the whole root at the workspace would
take that site offline.
Custom domains are a plan feature. If your plan doesn't include a custom branded domain, the request is declined with a prompt to upgrade.
Step 1 — Connect the domain
- Go to Workspace Settings → Custom domain.
- Enter the domain (for example
hr.yourcompany.com) — lowercase, nohttps://, no trailing path. - Click Connect.
The status moves to Waiting for DNS and the page shows the two records you need to add. You'll need access to your domain's DNS settings (at Cloudflare, GoDaddy, Namecheap, or wherever your domain is managed).
Step 2 — Add the two DNS records
The tab lists exactly what to add, each with a Copy button and a live Status chip showing what the platform currently sees for that record.
CNAME <your domain> → <the target shown on the page>
TXT _operentra-challenge.<your domain> → operentra-verify-… (your token)
- The CNAME record routes traffic for your domain to the platform ingress. Its target is shown on the page (a platform-owned host).
- The TXT record at
_operentra-challenge.<your domain>proves you own the domain. Its value is a one-time token unique to your workspace.
The Status column updates on its own as DNS propagates. Possible states are Found, Not found yet, Wrong target, and Proxied. DNS changes can take a few minutes to appear.
Set the CNAME record to DNS only (grey cloud, proxy off) until the domain shows as Active. The Cloudflare orange-cloud proxy hides the CNAME and blocks SSL certificate issuance. The tab flags this automatically with a Proxied status if it detects it. You can re-enable the proxy after the domain is active.
Step 3 — Verify & attach
Once the records are in place, click Verify & attach. The platform re-checks both records, and when they pass it attaches the domain and begins issuing the SSL certificate — the status changes to Issuing certificate.
You don't have to wait on the page. Clicking Verify & attach also arms an automatic hourly re-check for the next 3 days: if DNS hasn't finished propagating yet, the platform keeps trying on your behalf and attaches the domain by itself once the records are live. You can safely close the page.
Domain statuses
| Status | Meaning |
|---|---|
| Waiting for DNS | The records aren't verified yet — add them, then verify. |
| Issuing certificate | Verified and attaching; the SSL certificate is being issued (usually a few minutes). |
| Active | Live on your domain with SSL. The tab links to https://your-domain. |
| Error | Something went wrong (for example a record was removed); the message explains what to fix, and you can verify again. |
When the certificate lands, the status flips to Active automatically — the page refreshes itself while it's issuing, so you don't need to reload.
Keeping it running, and removing it
Leave both DNS records in place while the domain is active. Removing them takes the domain offline and can invalidate the certificate.
To detach, click Remove domain and confirm. Your workspace goes back to the standard platform address. You can connect a domain again later.
Member accounts
The Member accounts tab sets your workspace's employee sign-in policy — which email address new employees are invited with. The invited address becomes the person's sign-in email, so this choice decides whether your people sign in with a personal or a company-owned address.
| Policy | What it does |
|---|---|
| Flexible — personal email preferred (default) | Invitations go to the employee's Personal Email, falling back to the Official Email, falling back to an admin-entered Invitation Email (a field that appears on the Add Employee form only when both email fields are empty). |
| Official email only — locked | Invitations always go to the Official Email, and members cannot change their sign-in address while they are an active member of your company. The lock lifts at separation, so the offboarding grace period can be used to move the sign-in to a personal address. An admin can exempt an individual member with the Allow sign-in email change checkbox on their user row (see Users, roles & permissions). |
When to use which
- Flexible treats the account as belonging to the person. A personal-email account survives offboarding, and using the same personal address across group companies is what links those memberships into one account with a company switcher.
- Official-locked suits companies that require all access to run through a company mailbox. Bear in mind that when a person signs in with a company-owned address and later leaves, their whole account goes dormant at closure unless they move to a personal address during the grace period (see Onboarding & offboarding).
The policy applies to invitations sent from then on. Existing accounts and pending invitations are unaffected by a change.
Operator responsibility (behind the scenes)
Two pieces of the setup live with the platform operator, not the workspace:
- The base sending domain for email. The operator configures the shared sending domain and must have the matching SPF and DKIM DNS records in place so that mail from your personalized address is authenticated and lands in inboxes. Until the operator does this, your workspace's sending address/name fields stay disabled.
- The custom-domain ingress and SSL. The operator owns the CNAME target your records point at, and the platform issues and renews the SSL certificate automatically. In a local or self-hosted environment where the hosting API isn't configured, verification still runs but automatic attachment may be unavailable.
If your Email sender fields are locked, or a domain you've added and verified won't attach, it's an operator-side configuration step — reach out to your platform operator.