Additional services · Additional services
Domains, websites and business email: how everything connects
From the outside, your domain, website and business email often appear to form a single digital presence. Technically, however, they are separate services connected through configuration settings. Understanding who is responsible for each makes changes easier to plan and helps you identify the access you need.
The domain is the readable address. Your website provides content, while an email service receives and sends messages. The Domain Name System, or DNS, contains records that help locate the appropriate service. A change in one place can therefore affect other functions.
Three services with different roles
A domain such as beispiel.ch is a registered name on the internet. It does not automatically point to a finished website or necessarily include a mailbox. Registration is managed through a registrar. Crucially, your business should be recorded as the registering organisation and have its own access to the customer account. This keeps renewals, contact details and technical changes traceable.
Your website consists of content and a technical platform. Hosting provides storage and delivery; a website provider may combine hosting, a website builder and administration, or offer individual elements separately. Business email is another service, with mailboxes, user administration and rules for transporting messages. Your website and email can use the same provider, but they do not have to.
| Component | Role | Possible provider | Access required |
|---|---|---|---|
| Domain | Readable internet address and administration | Registrar | Domain account and ownership |
| Website | Content and delivery | Website platform or hosting provider | Administration account and hosting access |
| Business email | Mailboxes and message traffic | Email provider | Administrator access and user accounts |
| DNS | Connects names to services | Registrar or DNS provider | DNS administration access |
DNS: connecting addresses to services
In simple terms, DNS works like a publicly searchable directory. Different records are maintained for a domain. Nameservers identify which DNS infrastructure is responsible for that domain. Changing the nameservers effectively transfers management of the DNS zone to another service. All necessary records must already be present there; otherwise, your website or email may temporarily stop working as expected.
An A record maps a name to an IPv4 address. An AAAA record performs a similar role for IPv6. A CNAME points one name to another hostname. This is often used, for example, to map www beispiel.ch to a technically specified destination name. Provider requirements differ, so do not copy an example from a general guide without checking it.
MX records specify which mail servers receive incoming messages for a domain. They contain destinations and priorities. If a specialist provider handles your email, the DNS zone must correctly reflect its requirements. Simply changing the website destination should not normally require changes to MX records. Nevertheless, the risk depends on where the zone is managed and how the change is made.
SPF, DKIM and DMARC help coordinate how messages under your domain are sent and handled. SPF describes which sending services should be authorised. DKIM enables a cryptographic signature on outgoing messages. DMARC builds on authentication results and tells receiving systems how to handle failed checks. The precise configuration must accommodate all legitimate sending services.
Your main domain and www
The domain without www and the version with www are technically different names. A website provider may require you to choose one as the main address and redirect the other to it. The connection is often established using an A, AAAA or CNAME record. The permitted combination depends on your DNS provider and platform. Check both versions and HTTPS after making a change.
Even in an existing installation, the visible web address is not necessarily identical to the DNS destination. A platform may use several technical systems. Your DNS records should therefore follow the website provider's current requirements. When a domain points to a new platform, URL structure, redirects and the certificate remain separate matters that also need checking.
Separate providers, clear responsibilities
It is common to use different providers for your domain, website and email. This may be deliberate and allows you to choose services independently. However, it means you need to know who manages DNS. The registrar may provide nameservers while an external DNS service manages the zone. Your website agency can prepare changes without owning the domain.
Keep a simple record of responsibilities: who registers the domain, where nameservers are changed, who runs the website and email, and who may administer accounts. Store login details securely and assign individual accounts rather than sharing a password, where the provider supports this. Decide who revokes access and updates contact details when someone leaves or changes roles.
A domain change can affect your website and email if it replaces nameservers or the entire DNS zone. If only one web record is adjusted, email often remains unaffected, provided the other records stay in place. This is not a guarantee for every configuration. Before implementation, check MX, SPF, DKIM, DMARC, verification records, subdomains and any records for third-party providers in particular.
Plan changes with a clear understanding of the systems involved. A website relaunch might mean a new platform, a new main address or simply a change of hosting. These situations do not require the same DNS steps. First ask which specific names and records will change and whether the provider requires verification. Subdomains for accounting, support or campaigns may also be used independently of the main website.
Request domain support before changing important DNS settings.
Send a non - binding enquiryCommon mistakes and careful preparation
A common mistake is switching nameservers to a new provider without first recording the entire existing zone. Deleting TXT records that seem unnecessary is equally risky. They may be needed for email authentication, proof of ownership or external services. Multiple SPF records can also have unintended consequences; do not adjust an existing policy by blindly adding another.
Check before changing DNS
- Establish domain ownership and the relevant account access.
- Document the current nameservers and DNS records.
- Compare the website and email providers' requirements.
- Do not remove MX, SPF, DKIM, DMARC or verification records without checking.
- Test the website and email sending and receiving after the change.
Before every change, document the current configuration: nameservers, A and AAAA, CNAME, MX and relevant TXT records. Store these details in an access-controlled location and compare them with all providers' current requirements. Where possible, change one clearly defined area, then test the website and email sending and receiving. Depending on caching and TTL, DNS changes may not become visible everywhere immediately.
If you are unsure, coordinate the planned change with your registrar, email provider or technical support contact. Explain the objective, the names affected and the existing services. This helps prevent a change intended for the website from accidentally disrupting email or verification. You can request domain support for assistance.
An inventory is particularly important if several people or agencies have been involved. Record not only technical values but also each record's purpose and where its meaning was confirmed. When a service changes, the responsible party can explain whether a record is still needed. Avoid parallel changes by several people until responsibility for the zone is clear.
A connection overview as a conceptual guide
The following local overview helps you distinguish between the different roles. It does not show real DNS values, query providers or save your selection. For an actual configuration, the specific documentation for the services involved is authoritative. When providers are separate, DNS administration remains the connection point where the appropriate details come together.
- Website: your domain points via an A or CNAME record to the provider «Website builder platform».
- Business email: MX records point to «With the domain provider»; SPF, DKIM and DMARC support email delivery.
- Nameservers: remain with the domain provider; the platform supplies the required records.
Before implementation, check whether the demo reflects your actual situation. A domain can serve several subdomains and additional services. An email provider may likewise use several sending routes. A simple overview does not replace a complete DNS inventory or testing after a change.
Summary
- A domain is the address, not automatically a website or mailbox.
- DNS connects domain names to website and email services.
- Nameservers determine where the DNS zone is managed.
- A, CNAME and MX records perform different roles.
- SPF, DKIM and DMARC help verify email senders.
- Document records and check provider requirements before making changes.
Frequently asked questions
Do my website and business email need to use the same provider?
No. You can use separate providers. What matters is managing the DNS zone correctly and documenting responsibilities and access.
What happens if I change the A record?
This can change the website's destination. MX and other records remain in place only if they are not also changed or omitted when switching zones.
What are nameservers responsible for?
They point to the DNS infrastructure that provides authoritative answers for the domain. Changing them can therefore move management of the entire zone.
Can I delete old TXT records?
Not without checking. TXT records can support email authentication or verification, among other purposes. First establish their purpose and the services responsible.
What is the difference between SPF, DKIM and DMARC?
SPF describes permitted sending sources, DKIM signs messages, and DMARC sets rules for handling failed authentication.
How should I prepare for a change?
Record existing entries, check all providers' requirements, back up the zone and test your website and email after the adjustment.
Sources
- What is a domain name?ICANN · checked on 2026 - 11 - 05
- DNS documentationCloudflare · checked on 2026 - 11 - 05
- Set up SPFGoogle Workspace · checked on 2026 - 11 - 05
- Set up DKIMGoogle Workspace · checked on 2026 - 11 - 05
Back to the top of the article
