An address like info@yourcompany.ch looks more trustworthy than an address with a free mail provider, and it belongs to the company, not to an individual. But anyone who wants to set up email mailboxes on their own domain faces questions that go beyond the technology: who reads which address? What happens to the old emails? And who may access a mailbox during an absence? This guide shows what SMEs should clarify beforehand so that the change goes ahead without lost messages.
Why your own domain for email
The address carries your company name and stays reachable even when an employee leaves: the company decides what happens to the mailbox. With a single domain for website and email, customers recognise your messages at a glance and fraudsters find it harder to imitate your company. In addition, you decide where the data is held and who has access, rather than leaving that to a private account.
A mailbox is also an operating resource that needs looking after, though: storage, access and forwarding have to be managed, someone is responsible, and there needs to be a rule for when people leave.
Personal and shared mailboxes
Distinguish two kinds of addresses:
| Kind | Example | Who reads | Typical purpose |
|---|---|---|---|
| Personal | first.last@... | One person, if needed an expressly named delegate | Day-to-day business, direct correspondence |
| Shared (role address) | info@..., quotes@..., accounts@... | Several people with clear roles | Enquiries, invoices, applications |
- Kind
- Personal
- Example
- first.last@...
- Who reads
- One person, if needed an expressly named delegate
- Typical purpose
- Day-to-day business, direct correspondence
- Kind
- Shared (role address)
- Example
- info@..., quotes@..., accounts@...
- Who reads
- Several people with clear roles
- Typical purpose
- Enquiries, invoices, applications
Personal mailboxes are confidential. Shared mailboxes need clear rules: who replies, who can see, and how do you tell that an enquiry is already being handled? Without these rules, enquiries are left lying or answered twice. How to organise customer enquiries by email reliably is shown in the guide Handling customer enquiries.
Aliases and forwarding
Not every address needs its own mailbox. An alias is an additional address that delivers into an existing mailbox. In this way contact@ can be routed to info@ without anyone having to read two mailboxes. Forwarding sends incoming messages to another address, including outside the domain. Both suit addresses that appear on printed matter, vehicles or old business cards and that you do not want to give up. For forwarding to external addresses, check data protection: the messages then leave your system.
Access, delegation and data protection
The Federal Act on Data Protection (DSG) requires in Art. 8, para. 1 that the controller ensures, through suitable technical and organisational measures, data security appropriate to the risk. For mailboxes this means in concrete terms:
- access only for authorised persons, documented
- delegates expressly named, not by passing on passwords
- strong, unique passwords and, where possible, separate access per device
- a rule for departures and absences: who may read the mailbox, and for how long?
- logging of access to shared mailboxes
Personnel mailboxes and mailboxes with applications are particularly sensitive. Keep the circle of authorised people especially narrow here. For the long-term retention of business-relevant emails, read the guide Archiving emails.
Phone, Outlook and device access
Many people read email not only at their desk. A mail program on a phone or computer usually needs an access with a user name and password. It makes sense to use a separate password for each device. That way a lost phone can be blocked without disturbing all the other devices, and no password ever has to be used more than once. Never pass on access data by email, and do not type it into an AI chat either.
The DNS entries: MX, SPF, DKIM, DMARC
For your emails to arrive and not be taken for forgeries, the domain needs several entries in the DNS:
- MX determines which mail server accepts your incoming messages. If this entry changes, receiving switches.
- SPF (RFC 7208) names the servers allowed to send for your domain.
- DKIM signs outgoing messages so that recipients notice changes.
- DMARC (RFC 7489) determines what recipients do with messages that fail SPF or DKIM, and provides reports.
Basic rule: there is exactly one SPF entry per domain. Anyone using several services combines them in this one entry. Note also that an entry that looks correct says nothing yet about delivery. Also check mail traffic with real test messages to several providers.
Moving old mailboxes
The most delicate part is moving the existing messages. A proven order:
- Inventory: list all mailboxes, aliases, forwarding rules and out-of-office messages, including forgotten ones such as scanner addresses.
- Create the new mailboxes before changing anything in the MX.
- Copy the old messages, do not move them, and compare the count and samples.
- Change MX and other entries as soon as everything is ready.
- Send test messages to every address and check the reply.
- Keep the old system for a while longer, until it is certain that nothing arrives there any more.
When the whole company moves, completeness matters: if a single mailbox stays with the old provider, the domain has to work with two systems, and responsibility for delivery problems becomes unclear. That is why a common rule is to keep all mailboxes of a domain in the same place, or none.
Practical example: Muster Gartenbau Waldmann AG
Muster Gartenbau Waldmann AG is a fictitious business with 14 employees. The inventory lists 8 personal mailboxes and 3 shared ones (info@, quotes@, accounts@), 11 mailboxes in total, plus 2 aliases that appear on the vehicle lettering. That makes 13 addresses.
The managing director decides: the accounts@ mailbox is read by the bookkeeper and by himself as an express delegate, and quotes@ is read by two people in the office. The aliases point to info@. All 11 mailboxes are created before the mail entries are changed. The employees copy their old messages and compare the count per folder. On the day of the switch, on a quiet morning, the office manager sends a test message to each of the 13 addresses and checks that all 13 arrive. Two days later she checks whether messages still arrive in the old system. They do not, and the old provider is cancelled afterwards. The field staff’s phones each receive a device access of their own.
Checklist
- All existing mailboxes, aliases, forwarding rules and out-of-office messages listed
- Personal and shared mailboxes distinguished, responsibilities set
- Delegates expressly named, no shared passwords
- Rule for departures and absences recorded in writing
- Forwarding to external addresses checked for data protection
- New mailboxes created before the mail entries are changed
- Old messages copied, count and samples compared
- SPF, DKIM and DMARC set, only one SPF entry per domain
- Test messages sent to every address and replies received
- Device access separated per phone or computer
- Old system switched off only after an observation period
How KMU | base helps
With Online | base you can run mailboxes for your domain and read them in KMU | base. A note on classification first: provisioning on your domain, that is the mail entries and the move of the old messages, is accompanied by our team in individual, controlled steps; ask us about the current status and your schedule before you start. The portal itself offers a planning function with which you can run through domain and mailboxes in advance.
1. All or none. For a domain you run either all mailboxes with us or none. That way the domain runs in one place, all addresses are set up in the same way, and there is no shared responsibility between two providers. You choose the number when ordering; the terms are under Prices.
2. Personal and shared mailboxes. Personal mailboxes can be seen only by the owner and an expressly named delegate. Shared mailboxes with roles re-check the rights on every access and keep an access log. Additional addresses such as info@ or quotes@ can be run as an alias or forwarding.
3. Reading in the mail centre. You read and answer your emails directly in KMU | base, in the mail centre and in the dossiers, with AI reply suggestions if you wish. You do not need a separate webmail. Enquiries from your website’s contact form appear as an enquiry in Sales | base.
4. Phone and Outlook. For a mail program you create a device access of its own. The password is shown only once; you can renew or revoke it without disturbing other devices. Access data does not belong in the AI chat; device management is deliberately excluded from it.
5. Accompanied move. You do not have to give us old passwords. You copy the existing messages from the old to the new mailbox in a guided procedure, and we compare the count. Before the mail entries are switched, all mailboxes have been created. We confirm actual delivery of emails only with real test messages, not on the basis of a correct DNS entry alone.
What Online | base does not replace: you set the responsibilities, delegates and rules for departures and retention. We give no guarantees about the delivery of each individual message. For the domain part, read the guide Moving a domain.
More about the product on the Online base page. Take a look at the demo or open a test account. If you have questions, we will help you via the contact page.
Sources
- Federal Act on Data Protection (DSG, SR 235.1), Art. 8, paras. 1–2, as at 7 July 2025: fedlex.admin.ch (German original), accessed on 04.11.2026.
- IETF: RFC 7208, Sender Policy Framework (SPF), April 2014: rfc-editor.org, accessed on 04.11.2026.
- IETF: RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC), March 2015: rfc-editor.org, accessed on 04.11.2026.
This guide does not replace legal or tax advice. Information as at 04.11.2026.