Custom domains

Every workspace starts with a working your-team.knobs.io subdomain — mail in and out, zero setup. Connecting a custom domain puts your team’s addresses on your own name: you@yourcompany.com instead of you@yourcompany.knobs.io.

Domain management lives in Settings → Domains (owners and admins). A workspace has its subdomain plus one custom domain.

Add your domain

1. Open Settings → Domains and choose Add domain.
2. Enter the domain (e.g. yourcompany.com).
3. Knobs shows the DNS records to create at your DNS provider. Each has a copy button and a live verified / pending status:

Record	Purpose
_knobs-verify TXT	Proves you own the domain
MX	Routes the domain’s inbound mail to Knobs
DKIM (3 CNAMEs)	Cryptographically signs your outbound mail
SPF (TXT)	Authorizes Knobs to send for your domain — see If you already have an SPF record
DMARC (TXT)	Tells receivers how to treat mail that fails checks, and asks them to send you reports

4. Add the records at your DNS provider, then click Verify. Knobs also keeps re-checking automatically in the background, so you can close the dialog and come back — statuses flip to verified as your DNS propagates.

Host names are relative to your domain

Knobs shows each record’s Host / Name the way DNS providers want it — relative to your domain, without the domain on the end — because the provider adds the domain itself. @ means the domain with nothing in front of it.

Knobs shows	At your provider this becomes
_knobs-verify	_knobs-verify.yourcompany.com
abc123._domainkey	abc123._domainkey.yourcompany.com
@	yourcompany.com

Copy buttons copy exactly what’s shown. If your provider asks for the full name instead, hover over a host to see it.

The domain is verified once the ownership TXT, DKIM, and MX records pass. SPF and DMARC don’t block verification, but they are checked: if something is wrong with them, the record shows Update needed and Knobs explains exactly what to change. They decide whether your mail reaches inboxes, so fix anything flagged.

Note

DNS propagation can take anywhere from minutes to a few hours depending on your provider and TTLs. Partial progress is normal — records verify independently.

If you already have an SPF record

A domain may have only one SPF record. This is the single most common way domain setup goes wrong, and it breaks more than Knobs.

If yourcompany.com already sends mail through Google Workspace, Microsoft 365, a helpdesk, or a marketing tool, it already has a v=spf1 … TXT record at the apex. Adding ours as a second record does not add us to the list — it makes the domain have two, which under RFC 7208 is a permanent error. Receivers respond by ignoring SPF for your domain entirely, so mail from your other senders starts failing too, not just mail from Knobs.

Edit the record you have; don’t add another. Take the include: (or ip4:) term Knobs shows you and put it into the existing record, before the all term at the end:

You already have	Add ours by editing it to
v=spf1 include:_spf.google.com ~all	v=spf1 include:_spf.google.com include:amazonses.com ~all
v=spf1 include:spf.protection.outlook.com -all	v=spf1 include:spf.protection.outlook.com include:amazonses.com -all
(no SPF record at all)	v=spf1 include:amazonses.com ~all — publish exactly what Knobs shows

Two things to keep right when you merge:

• Order matters. Everything after the all term is ignored, so include: terms must come before it. Leave the trailing ~all or -all where it is.
• Don’t qualify our term. include:amazonses.com with a -, ~, or ? in front of it means “reject mail from Knobs”, which is the opposite of the intent.

Knobs checks all of this. If it finds two records, a missing term, or a term receivers can never reach, the SPF row shows Update needed with the specific fix — including the current value of your record, so you can see what to edit.

Caution

SPF has a limit of 10 DNS lookups per record. Each include: counts toward it. If you are near the limit, remove include: terms for services you no longer use rather than dropping ours — past the limit, receivers treat the whole record as an error.

DMARC reports come back to you

The DMARC record Knobs generates ends with rua=mailto:dmarc@yourcompany.com. That address is on your own domain, which Knobs already hosts, so it needs no extra setup — and dmarc@ is reserved: you can’t assign it to a person or a group, and reports never land in anyone’s inbox.

The rua= part is not decoration. Without it, receivers are required not to send aggregate reports at all, so a DMARC record without one tells you nothing about who is sending mail as your domain. If your domain currently publishes a DMARC record with no rua=, the DMARC row shows Update needed — replace the published value with the one Knobs shows.

The record starts at p=none, which means “monitor, don’t act”. That is deliberate: tightening to quarantine or reject before you know who sends mail as your domain is how legitimate mail gets thrown away.

Publish exactly one DMARC record, for the same reason as SPF: a receiver that finds several at _dmarc.yourcompany.com treats your domain as having no DMARC policy at all.

Re-checking a domain that’s already verified

A verified domain keeps a Re-check DNS button. Use it whenever you change your DNS, or if you set the domain up a while ago — SPF and DMARC checking is newer than some domains, and re-checking is what surfaces anything that needs fixing.

Re-checking a verified domain only re-reads SPF and DMARC. It never un-verifies the domain, never re-sends the “domain verified” notification, and never touches your addresses. If it finds a problem, the DNS record table reappears with the specific fix.

Note

Knobs does not currently re-check a verified domain on its own. If your DNS changes after verification — someone edits the SPF record, or a provider is removed — nothing notices until you press Re-check DNS.

What happens when it verifies

• Every address follows. Addresses are workspace-wide, not per-domain: the moment a domain verifies, every existing address starts working there — members’ primaries, their personal aliases, and group addresses alike (jesse@acme.knobs.io → also jesse@acme.com). A verified domain is never empty, and there is nothing to set up per domain. Manage addresses in Settings → Aliases.
• You can make it the default. Switch the workspace’s default domain to the custom domain so new members and workspace addresses use it first. Existing subdomain addresses keep working.
• Sign-in accepts addresses on any verified domain — see Create your account.

During onboarding, or later

The same flow appears inside onboarding when you choose a custom domain at sign-up — with an explicit skip, so sign-up always completes on the subdomain and the domain can be finished later. Nothing is lost by skipping.

Undelivered mail

The Domains section also carries the admin-only Undelivered view: mail sent to an address on your domain that doesn’t exist yet (a typo, or a person who hasn’t been invited) is held rather than lost. From Undelivered you can create the missing address or deliver a held message anyway. The list loads the most recent messages first; if there are more than fit on one page, Load more brings in the next batch. See Mailboxes & aliases.

Removing a domain

Removing the custom domain disables its mailbox rows (mail history is preserved; every address keeps working at your remaining domains) and frees the domain. The your-team.knobs.io subdomain is permanent and can’t be removed.