KoltrixHow to set up a support@ shared mailbox on your own domain
A step-by-step runbook for a support@ shared mailbox on your own domain: verify the domain, authenticate, grant access, add labels, auto-reply and test it.
On this page(12 sections)
- Before you start
- Step 1: Decide on the address
- Step 2: Add and verify your domain
- Step 3: Point mail at your provider and authenticate it
- Step 4: Create the shared mailbox
- Step 5: Grant access to the right people
- Step 6: Set up a few labels
- Step 7: Write the auto-acknowledgment
- Step 8: Test before you publish
- Step 9: Publish the address
- How this maps to Koltrix
- Key takeaways
Setting up support@ properly takes an afternoon, and most of that afternoon is waiting for DNS. The steps themselves are straightforward; the mistakes happen when teams skip testing or publish the address before replies actually work.
This runbook walks through the whole setup in order. It's written generically so it applies to most providers, with a note on how it maps to Koltrix at the end.
Before you start
Have these ready:
- Admin access to your domain's DNS, usually at your registrar or DNS host.
- A list of who will answer support@, and who should not see it.
- An outside email account for testing, such as a personal address on a different provider.
- About an hour of hands-on time, spread over a day to allow for DNS changes to take effect.
Step 1: Decide on the address
Most teams use support@, but confirm it fits:
- support@ for existing customers with problems or questions.
- help@ reads friendlier to some audiences; it works the same way.
- hello@ if you want one address for everything in the early days.
Pick one primary address. You can add aliases later (for example help@ delivering to the support@ mailbox), but publish only one so customers aren't split across addresses.
Step 2: Add and verify your domain
Your email provider needs proof that you control the domain before it will accept mail for it. Typically:
- Add the domain in your provider's admin settings.
- The provider gives you a DNS record to create, usually a TXT record with a unique value.
- Create that record at your DNS host.
- Return to the provider and click verify. If it fails, wait a little; DNS changes can take time to propagate.
Don't skip ahead until verification succeeds. Everything else depends on it.
Step 3: Point mail at your provider and authenticate it
Two kinds of DNS records make your domain's email work and be trusted:
- MX records tell the world where to deliver mail for your domain.
- Authentication records (SPF, DKIM and DMARC) let receiving servers confirm that mail claiming to be from your domain really is. Without them, your replies are far more likely to land in spam.
Your provider will list the exact records to add. Copy them carefully, and if you already send email from the domain through other services (a newsletter tool, your app's transactional email), make sure your SPF record includes all of them rather than replacing one with another. Deeper DNS details are outside this runbook; follow your provider's documentation and use its built-in checker if it has one.
If the domain already receives mail elsewhere, changing MX records switches delivery. Plan that cutover deliberately, ideally at a quiet time, and keep the old mailbox accessible for a while in case anything arrives late.
Step 4: Create the shared mailbox
Create support@ as a shared mailbox, not as a regular user account with a shared password. The difference matters:
- Everyone uses their own login and their own two-factor authentication.
- You can see who replied to what.
- Removing someone's access doesn't require changing a password for everyone else.
Give it a display name customers will recognize, such as "Acme Support," so the From line reads clearly in their inbox.
Step 5: Grant access to the right people
Add only the people who will actually reply. A typical first setup:
| Person | Access to support@ |
|---|---|
| Support lead | Full access |
| Support teammates | Full access |
| Founder | Full access, or read-only if they want visibility without replying |
| Engineers | Usually none; bring them in on specific threads |
| Contractors | Only if they answer support, and only for the engagement period |
Resist adding everyone "just in case." More people with access means more chances of duplicate replies and more people to offboard later.
Step 6: Set up a few labels
Start small. Three to five labels cover most needs in month one:
- Bug
- Billing
- Feature request
- Waiting on customer
- Urgent
Add auto-label rules only for patterns you're sure about, such as mail from your payment processor getting Billing. You'll learn what else you need within a few weeks.
Step 7: Write the auto-acknowledgment
An automatic reply sets expectations. Keep it short and honest:
Subject: We got your message
Thanks for writing to Acme Support. A person on our team will reply,
usually within one business day (Mon–Fri, 9:00–18:00 US Eastern).
If you can't sign in or your account is down, reply with URGENT in the
subject and we'll prioritize it.
Many common questions are answered at [help center link].
Avoid pretending the auto-reply is personal, and avoid sending it from a no-reply address. Customers should be able to reply to it.
Step 8: Test before you publish
Run each of these from your outside test account:
- Send a new email to support@. Does it arrive in the shared mailbox?
- Does the auto-acknowledgment arrive, and does it look right?
- Reply from the shared mailbox. Does the reply come from support@, with the right display name?
- Does the reply land in the test account's inbox, not spam?
- In the test account, view the message headers or "show original" and check that SPF, DKIM and DMARC pass.
- Reply back from the test account. Does it thread correctly in the shared mailbox?
- Have a second teammate check they can see the whole thread.
Fix anything that fails before moving on. Spam placement and authentication failures are much easier to fix before customers start writing.
Step 9: Publish the address
Put support@ everywhere customers look for help:
- Website footer and contact page.
- Inside your product (help menu, settings).
- Help center or docs.
- Transactional emails and invoices, as the reply-to or the "questions?" line.
Then turn off any old forwarding that sent support mail to personal inboxes, so there's only one place it lands.
How this maps to Koltrix
In Koltrix, you add a custom domain and verify ownership with a DNS record, then add the SPF, DKIM and DMARC records it lists; each domain gets its own 2048-bit DKIM key. From there you create support@ as a shared mailbox and choose, per mailbox, who has access. Labels and auto-label rules work on top, and AI sorting keeps cold pitches and newsletters out of the way. The docs at https://docs.koltrix.com walk through each screen, and you can try it on a 7-day trial without a card at https://app.koltrix.com/sign-up.
Key takeaways
- Verify the domain and add authentication records before anything else; replies without them often land in spam.
- Create support@ as a real shared mailbox with individual logins, never a shared password.
- Grant access narrowly and start with only a handful of labels.
- Test the full round trip from an outside account, including headers, before publishing.
- Publish one address everywhere and switch off old forwarding.
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.
