KoltrixAdding Your Domain to Koltrix: The Five DNS Records
Koltrix asks for five DNS records: ownership, MX, SPF, DKIM and DMARC. What each one does, what its value looks like, and the order to publish them in.
On this page(9 sections)
When you add a domain to Koltrix, the setup screen asks you to publish five DNS records. Five sounds like a lot for one domain, but each record has its own job, and once you know what that job is, the whole setup takes about as long as logging in to your registrar.
This post walks through all five: what each one does, roughly what its value looks like, and the order that keeps your existing email working while you set things up.
The five records at a glance
| Record | Type | Host | Value (shape) | What it does |
|---|---|---|---|---|
| Ownership | TXT | _koltrix |
koltrix-verify=<your token> |
Proves this workspace controls the domain |
| MX | @ |
10 mail.koltrix.com |
Routes incoming mail to Koltrix | |
| SPF | TXT | @ |
v=spf1 include:_spf.koltrix.com -all |
Lists the servers allowed to send as your domain |
| DKIM | TXT | kx1._domainkey |
v=DKIM1; k=rsa; p=<your public key> |
Publishes the key that verifies your signatures |
| DMARC | TXT | _dmarc |
v=DMARC1; p=quarantine |
Tells receivers what to do with mail that fails |
The setup screen shows the exact values for your domain, with a copy button next to each one. It checks every record live and tells you when it resolves, so you don't have to guess whether DNS has caught up yet.
1. Ownership: proving the domain is yours
The ownership record is a TXT record at _koltrix.yourdomain.com containing a token unique to your workspace. It exists for one reason: so that only the people who control the domain's DNS can attach it to a workspace.
Without it, anyone could type your domain into a signup form and claim it. With it, a claim only becomes real when the matching token appears in your DNS, and only someone with access to your registrar can put it there. If the screen says a different koltrix-verify value is published, someone (possibly a teammate in another workspace) added their own token. Each workspace gets its own, so publish the one your screen shows.
This record doesn't affect mail flow at all. It's safe to publish first, at any time.
2. MX: where incoming mail goes
The MX record tells the rest of the internet which server accepts mail for your domain. Koltrix's is mail.koltrix.com at priority 10.
This is the only one of the five that changes where your mail actually goes. The moment it propagates, new messages to [email protected] start arriving in Koltrix instead of at your old provider. That's why it belongs at the end of the sequence, after everything else is verified and your addresses exist.
If you're moving from another provider, lower the TTL on your current MX records a day ahead so the switch takes effect quickly, and be ready to change it back if something looks wrong. Our Google Workspace cut-over checklist covers that sequence step by step, and most of it applies to any provider. You can check what your domain's MX records currently point to with the MX lookup tool.
3. SPF: who is allowed to send as you
SPF is a TXT record on the domain itself listing the servers allowed to send mail using your domain in the envelope sender. Koltrix's part of it is include:_spf.koltrix.com.
The most common SPF mistake is publishing a second SPF record. A domain must have exactly one, and if a receiver finds two, SPF fails for all of them. So if you already have an SPF record for Google, Microsoft, a helpdesk or a billing tool, the Koltrix include gets merged into it rather than added alongside:
# Before: one existing record
v=spf1 include:_spf.google.com ~all
# After: the same record, with Koltrix added
v=spf1 include:_spf.google.com include:_spf.koltrix.com ~all
The setup screen does this merge for you and shows the combined value to publish. For a domain with no SPF record yet, the suggested record ends in -all, which tells receivers that nothing outside the listed servers should be sending as you.
Keep in mind that SPF allows at most ten DNS lookups when it's evaluated, and every include: uses at least one. If your record is already long, it's worth checking whether every service in it still sends for you.
4. DKIM: the signature on every message
DKIM lets receivers verify that a message really came from your domain and wasn't changed in transit. Koltrix generates a 2048-bit key pair for your domain alone. The private half stays on our mail server; the public half goes in a TXT record at kx1._domainkey.yourdomain.com.
Two details matter here. First, the key is per domain, not shared with other customers, so your signing reputation is your own. Second, signing happens at the mail server itself. Every message leaves signed, whether it was written in the composer, sent through the API or relayed over SMTP. Your application never handles a private key, and there's no per-message signing step for a developer to forget.
DKIM values are long, and some registrars split or mangle long TXT strings. If the check stays red after propagation, look at the record in your registrar's interface for stray quotes, spaces or a doubled domain name. That last one happens when you paste the full host name into a field that already appends your domain.
5. DMARC: what to do with failures
DMARC ties SPF and DKIM to the domain your recipients actually see in the From line, and tells receivers what to do when a message fails. The suggested record is v=DMARC1; p=quarantine, which asks receivers to send mail that fails authentication to spam rather than the inbox.
That's a sensible default for a domain whose legitimate mail is all authenticated. If you have other services sending as your domain that you haven't set up SPF or DKIM for yet, fix those first, or start at p=none while you find them and then tighten it. Our plain-English guide to SPF, DKIM and DMARC explains the policies and reports in more depth, and the DMARC checker shows what your domain publishes today.
The order that keeps mail flowing
If your domain already receives mail somewhere else, publish in this order:
- Ownership TXT. No effect on mail; verifies the claim.
- DKIM TXT. New selector, so it can't collide with anything you have.
- SPF. Merged into your existing record, so your current provider keeps passing.
- DMARC. If you already have one, check it before replacing it.
- Create your addresses in Koltrix and send a test message.
- MX, last. Lower the TTL in advance and switch on a quiet morning.
Steps one through four can all be done while your old provider is still handling mail, and none of them interrupts it. Only step six moves your inbox.
A note on domains added earlier
Domains that were verified before the ownership and kx1 records existed were set up with a shared key behind a CNAME and an older SPF include, include:koltrix.com. Those keep working. The setup screen shows the newer records to those domains as a recommended upgrade, never a requirement, and verification is never taken away from them.
Key takeaways
- Ownership proves the domain is yours, MX moves your mail, and SPF, DKIM and DMARC prove your outgoing mail is genuine.
- Merge the SPF include into your existing record. Never publish a second SPF record.
- DKIM uses a 2048-bit key for your domain alone, and every message is signed at the server, whatever sent it.
- Publish everything else first and switch MX last, with a low TTL and a quiet morning.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
