KoltrixWhy Koltrix signs each domain with its own DKIM key
Every domain you add to Koltrix gets its own 2048-bit DKIM key. Here is why we chose that over one shared key, what it means for you and what you publish.
On this page(9 sections)
When you add a domain to Koltrix, one of the five DNS records we ask for is a long TXT value at kx1._domainkey. That value is the public half of a DKIM key that was generated for your domain and for no one else.
It would have been simpler for us to sign everyone's mail with one shared key. Many mail services started that way. We changed course, and this post explains why, in plain terms.
What DKIM does, in one paragraph
DKIM lets a sending system sign a message with a private key. The receiving server looks up the matching public key in the sender's DNS, checks the signature, and learns two things: the message was not altered on the way, and the domain named in the signature authorised it. That domain is the d= value in the signature. If you want the background, start with SPF, DKIM and DMARC in plain English.
The shared-key way, and its limits
With a shared key, the service signs all customers' mail with one key and one signing domain, usually its own. That works for getting mail delivered, but it has costs for the customer:
- The signature does not say your name. The
d=domain is the provider's, not yours. Receivers can see the mail is genuinely from the provider but not that your domain vouched for it. - DMARC can fail on alignment. DMARC passes when SPF or DKIM passes for a domain that matches the From address. A signature from the provider's domain does not match yours, so it does not count toward your DMARC result. See DMARC alignment, relaxed and strict.
- Reputation is pooled. Mailbox providers build trust on the signing domain. If thousands of customers share one, a few bad senders affect everyone.
- One key is one blast radius. If a shared private key were ever exposed or had to be retired, every customer would need to change something at the same moment.
What a key per domain gives you
Koltrix generates a separate 2048-bit key pair for each domain, used by that domain alone. The mail server signs your messages with your key, with your domain in the d= field. In practice that means:
- Your signature, your domain. The signing domain matches your From address, so DKIM counts toward your DMARC result with no special setup.
- Reputation that is yours. What mailbox providers learn about your mail attaches to your domain, not to a crowd. Good habits help you, and someone else's mistakes do not hurt you.
- A small blast radius. A problem with one domain's key affects that domain only, and rotating it is a one-domain job. See DKIM key rotation without breaking mail.
- A key size that still holds. 2048 bits is the length providers recommend today. The cost is a long DNS value; see why 2048-bit keys need split TXT strings.
What you actually do
You do not generate or handle the key. When you add a domain, Koltrix shows you five records:
| Record | Purpose |
|---|---|
TXT at _koltrix |
Proves you own the domain |
| MX | Delivers incoming mail to Koltrix |
| TXT (SPF) | Authorises Koltrix to send for the domain |
TXT at kx1._domainkey |
Your domain's own DKIM public key |
TXT at _dmarc |
Tells receivers what to do with mail that fails authentication |
Copy each value with its copy button and paste it into your DNS provider. The DKIM value is about 400 characters long. Some providers split it into several quoted pieces when you save it, which is fine as long as nothing is missing or added in between. The domains documentation has the exact names and a troubleshooting section.
If your domain was added before this
Domains verified earlier keep working. They were signed with a shared key, and Koltrix shows the new records as a recommended upgrade. Once your kx1._domainkey record checks out, your mail is signed with your own key automatically. Nothing is cut off while you do it.
How to check that it works
Send a message from your Koltrix address to a Gmail account you control, open it, and choose "Show original". Look for DKIM: PASS and for a signing domain that is your own. In the raw headers you will see dkim=pass with header.d= set to your domain. If the result is not a pass, or the signing domain is not yours, check the kx1._domainkey record first. The Authentication-Results header post explains how to read the rest.
If the record does not verify
Most failures are small and have the same few causes:
- A doubled domain name. If the record ended up at
kx1._domainkey.example.com.example.com, your DNS provider added the domain for you. Enter only the short name,kx1._domainkey. - A broken value. Characters missing from the middle, or a space or line break pasted in, will fail the check. Use the copy button and paste in one go.
- Not published yet. DNS changes can take a while to spread. Wait a little and run the check again.
You never see or handle the private key, so there is nothing on your side to lose or leak. Your only job is to keep the public record in DNS.
A note on trust
A signature proves that a domain authorised a message. It does not prove the message is wanted. Authentication is one input to how mailbox providers treat your mail, next to your sending habits and complaint rate. A per-domain key makes sure the authentication evidence points at you; it does not replace being a sender people want to hear from.
Key takeaways
- A shared signing key makes mail deliverable but not aligned with your own domain.
- A per-domain key puts your name in the signature, keeps DMARC alignment simple and isolates your reputation and risk.
- You publish one extra TXT record at
kx1._domainkey; Koltrix handles the keys. - Older domains are not forced to change, and move to their own key when you add the record.
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.
