Two services, two different jobs
When someone opens your website, their browser requests pages, images and application responses from a web service. When a customer emails your company, sending and receiving mail systems exchange messages and place accepted mail in a mailbox. These are separate workloads even when one supplier sells them together. A working website does not prove that an address can receive mail, and a functioning mailbox does not prove that a website is published. Start by listing the outcomes you need rather than treating the word hosting as one product.
Four components behind one business domain
A typical business arrangement involves a domain registration, authoritative DNS, a web service and a mail service. Registration establishes control of the name under the registry rules; DNS publishes instructions that other systems look up; the web service answers HTTP requests; and the mail service receives or sends messages. One company may administer all four, or several companies may divide the work. Record the actual operator and administrator for each component. A supplier invoice mentioning a domain and hosting is not sufficient evidence that mailbox accounts, mail backups or application maintenance are included.
What web hosting must provide
For a brochure website, hosting usually needs to deliver HTML, style sheets, scripts and images through a web server with an appropriate certificate. A content management system may also need a database, a compatible runtime, scheduled tasks, storage and an administrator able to apply updates. An online store can add checkout integrations, sessions, order processing and higher operational risk. Ask which software versions are supported and who is responsible for patches. A package advertised with generous disk space may still be unsuitable if the application requires a feature or runtime the service does not provide.
What email hosting must provide
Email hosting must accept incoming messages for the domain, maintain accessible mailboxes, support authenticated sending and offer supported access methods such as webmail or compatible mail clients. Businesses also need account administration, password recovery, mailbox capacity, spam controls and an understandable retention or backup arrangement. These features are not created merely by pointing the website to a server. Confirm the exact number of mailboxes and whether aliases, shared access, forwarding, archiving or migration are supported. Different providers implement these features differently, so the contract and current service documentation matter more than the package label.
DNS directs traffic without hosting content
A and AAAA records commonly resolve website hostnames to server addresses; CNAME records point one hostname to another. MX records identify where mail for a domain should be delivered. TXT records may hold domain verification or email-authentication policies. These records are instructions, not storage for pages or messages. For a hypothetical company, the root domain and www name could lead to its web provider while MX leads to a separate mail platform. Changing one record need not change the others, provided the administrator preserves the complete zone and any provider-specific requirements.
A website move should not casually move mail
Suppose a company replaces its website host but keeps the same email provider. The migration plan should identify the existing A, AAAA or CNAME records used by the site, then change only the records needed for the new web destination. Preserve MX, SPF, DKIM, DMARC and any client-configuration records unless an authorized mail change requires them. Test the new site using a controlled preview before public cutover where possible. After the DNS change, verify both the website and real inbound and outbound mail. A domain-wide nameserver replacement without a complete record inventory can accidentally interrupt email.
An email move should not casually move the website
If the company moves from one mailbox platform to another, the website may remain exactly where it is. Prepare new user accounts, decide which historical messages must be migrated, and document any aliases, shared addresses, mobile clients and automated senders. The mail cutover normally involves the provider's required MX and authentication records, not replacing the website's hosting records. Keep the old environment available during the agreed validation period when practical. Test delivery in both directions and confirm users can access required old messages. Do not promise that DNS changes alone transfer existing mailbox contents.
The hidden cPanel email-routing decision
A server that runs cPanel may also have a local mail exchanger, but its internal routing setting can differ from public DNS. cPanel documents local, backup and remote exchanger modes, and warns that incorrect routing can disrupt delivery. Its automatic detection uses the local zone file rather than performing a live external DNS lookup. Therefore a domain using an external mail provider can still fail locally if the web server incorrectly accepts mail for that domain. The administrator should check routing against the real mail architecture with the hosting provider; this is a planning check, not permission to change a live server.
Contact forms are not the same as a mailbox
A website contact form collects visitor input through application code or a third-party form service. It may send a notification email, save a submission, or both. A business mailbox is the destination where staff read and respond to messages. A working contact form interface does not guarantee that its notifications arrive, and a mailbox subscription does not automatically supply a secure form. Determine where submitted personal information is stored, who can access it, how abuse is limited and what happens when delivery fails. Form processing and privacy controls deserve separate acceptance tests.
Website-generated messages need their own plan
An appointment website or shop may send receipts, password resets or booking confirmations. These application-generated messages are not necessarily sent through an employee's ordinary mailbox. Some platforms require a supported authenticated SMTP relay or an email-delivery service, and the sending domain may need additional authentication records. Identify each system that sends mail before replacing a provider; otherwise an unchanged website could continue displaying pages while transactional messages silently fail. Check the actual application's supported configuration, sender identity, error logging and test messages without publishing credentials or assuming that ordinary mailbox quotas cover bulk application traffic.
Mailbox count is different from email addresses
Six people needing individual access usually implies a different requirement from six public-facing address labels. An alias may deliver mail into an existing account without creating a separate login; a forwarder may redirect messages; a shared mailbox can support team workflows when the platform offers it. None should be treated as equivalent without checking sending identity, access logging, storage ownership and staff turnover. Map each address to its business purpose and accountable user. This avoids paying for unused seats while also preventing a team from sharing one password merely to reduce a subscription count.
Calculate website and mailbox storage separately
Website storage may contain media, application files, databases and temporary files; mailbox storage grows with attachments, sent messages and retention practices. A small one-page site can coexist with several busy mailboxes, while a media-heavy site can have little email activity. Estimate each workload from actual files, message volumes and growth, not a combined marketing number. Ask whether backups, logs and database files count against the quoted quota and what happens when limits are reached. A generous web-storage allocation does not automatically increase the capacity of an external email account.
Performance and availability are measured differently
Website performance concerns page loading, application responsiveness and whether visitors can complete tasks. Mail reliability concerns accepting messages, routing them to the correct mailbox, and users being able to read and send them. An uptime claim may apply only to a particular service or infrastructure layer. Ask what the provider actually monitors, which incidents qualify for service credits and how support escalates a fault. A fast website cannot compensate for missed enquiries; equally, dependable email does not make a broken checkout usable. Define separate test cases and incident owners for both services.
Separate the security responsibilities
Web hosting security may involve application updates, access permissions, TLS, backups and protection against vulnerable plugins. Email security involves account authentication, least-privilege access, recovery methods, anti-spoofing records and controls against malicious attachments or phishing. Both depend on secure administration, but their risks and operators can differ. Establish who manages the website application, DNS zone, mailbox accounts and staff departures. Multi-factor authentication is useful where supported, yet it does not replace patching or tested recovery. Do not assume that a provider's generic security claim covers every customer-managed application and mailbox configuration.
Backups must be scoped and restorable
A web backup may include site files and databases, while an email backup may require mailbox data and account settings. cPanel's Backup documentation distinguishes full account backups from partial backups and notes that restoring a full account archive through the ordinary cPanel interface is not automatic. External email platforms have their own retention and export procedures. Ask for the recovery point, retention period, location, access rights and a tested restoration method for each service. A downloadable archive is useful only if the business knows what it contains and who can actually restore the required information.
A migration inventory prevents expensive assumptions
Before changing suppliers, write down the registrar, DNS host, current web origin, certificate method, mailbox platform, MX target and any services that send on behalf of the domain. Inventory website forms, scheduled jobs, databases, forwarding rules and mobile mail clients. Identify which credentials and backups the authorized administrator already controls; never include passwords in the published checklist. Agree on a maintenance window and rollback decision points. If an old provider manages DNS as well as web hosting, cancelling that account too early may remove records needed by an unrelated email service.
Understand the difference between HTTPS and email authentication
HTTPS protects connections between a browser and the website when correctly configured, but it does not authenticate the sender of a business email. SPF identifies permitted sending infrastructure, DKIM signs mail, and DMARC expresses a domain-level policy and reporting framework for aligned authentication. These controls help recipients evaluate mail but do not guarantee inbox placement or eliminate phishing. A business using separate web and email suppliers must maintain the appropriate controls for each. Copy provider-specific DNS values from current account instructions rather than reusing a generic example that may be wrong for the tenant.
Cloudflare proxy settings require service awareness
Cloudflare's standard proxy is designed for supported web traffic. Its documentation explains that MX records are not proxied and mail-specific A or AAAA hostnames should normally remain DNS-only. If mail.example.com points to a proxied web address, SMTP or mail-client connections may fail even though the homepage works. The administrator should distinguish the public website hostname from the hostname used by mail clients or MX records. A DNS dashboard showing an orange cloud is not proof that every protocol is protected. Do not change proxy status without checking the existing application and mail dependencies.
Compare renewals and operational support, not headline prices
A combined package can simplify billing, but it may couple renewal dates and make future separation harder. Separate suppliers can provide specialist features, yet require clearer coordination during outages. Compare the actual recurring charge, mailbox seats, web resources, backup coverage, domain renewal, taxes where applicable and fees for migration or restoration. Do not infer OnHypp's current selling price from a general article. Ask who answers when the website works but mail fails, whether support can inspect the relevant system, and how the business obtains its data when the agreement ends.
Hypothetical case: email-heavy service business
Imagine a local engineering consultant with six employees, regular large drawings sent by email and a five-page informational website. The critical questions are mailbox quotas, permitted attachment workflows, staff access, search and retention, rather than a powerful website server. A simple web plan and a suitable business mail platform may meet the need better than a large bundled package. If sensitive files are shared, controlled file links may be more appropriate than repeated attachments. The company should still test the website enquiry form and document who handles its notification failures. This example is illustrative, not a sizing recommendation.
Hypothetical case: online booking or commerce
Consider a small business taking online appointments or orders. The website may need a supported application stack, secure updates, database recovery, payment-provider integration and performance monitoring. Its email requirement may be only a few staff mailboxes, but the application also sends confirmations that must be tested separately. The business should map the complete transaction: visitor submits an order, the application stores it, staff receive the alert, and the customer gets a confirmation. A failure at any stage is material. Choose hosting against this workflow rather than selecting the most expensive web or mail tier by default.
Questions to put to every prospective provider
Request written answers to specific questions: Is web hosting included, and which runtime or content system is supported? How many real mailboxes are included and what are their quotas? Who hosts authoritative DNS and who may edit it? Which backups cover the site, database and mail, and how are restores performed? Are mail migration and sender-authentication setup included? Which features depend on a separate licence? Ask for service boundaries, renewal conditions, cancellation export steps and escalation contacts. An answer such as everything is included should be broken down into named deliverables before purchase.
Verify both services after any approved change
For the website, test the expected domain and www variant, HTTPS, important pages, images, forms and the primary customer journey. For email, confirm authoritative MX records, send and receive from external accounts, check message headers when troubleshooting, and test a real staff client. If a contact form sends notifications, test the entire path rather than only the on-screen success message. Record timestamps and expected outcomes so support can distinguish a DNS problem from a web application error or mailbox rejection. These checks describe a future acceptance process; no live OnHypp environment was changed.
Ownership and handover reduce supplier lock-in
Keep a business-controlled record of the domain registrant, DNS administrator, web hosting owner, email tenant administrator, renewal dates and recovery contacts. Grant suppliers only the access required for their work and document how access is removed at the end of an engagement. Preserve approved exports and configuration inventories in a secure business location, not in a public website repository. When an employee leaves or a supplier changes, verify that account recovery and billing contacts still belong to the business. The goal is continuity: each component can be supported or replaced without guessing who controls the others.
A decision that matches the actual business need
Choose a web service for the website's content, software and visitor workload; choose an email service for the number of users, mailbox workflow, capacity and delivery requirements. A combined supplier is reasonable when its written inclusions and support responsibilities satisfy both. Separate providers are reasonable when specialist needs or clearer separation justify coordination overhead. Before committing, draw a four-row map for domain, DNS, website and email, then attach a named owner, provider, renewal date and verification test to each row. That map is more useful than assuming one hosting purchase automatically solves everything.
Why more website resources do not mean more mailbox storage
For a business whose problem is full inboxes, increasing website resources alone is not a reliable fix. Separate the email account inventory and storage quota from the web application's CPU, RAM and database requirements. Preserve the existing MX, SPF, DKIM and DMARC records whenever an application website changes hosting.
OnHypp keeps its Biz and Power email-and-website bundles as the normal choice for businesses primarily buying company mailboxes. A buyer can therefore request email and managed web hosting as separately scoped services under the same domain without silently migrating existing mail.
Sources & further reading
- Cloudflare DNS record types: A, CNAME, MX, TXT, SPF, DKIM and DMARC
- Cloudflare DNS proxy use cases for web and email
- Cloudflare email DNS troubleshooting
- cPanel Email Routing: local, backup and remote mail exchangers
- cPanel Backup: account and partial backup limitations
- Microsoft 365 external DNS records and SPF guidance