Hosting includes email, so most people use it without deciding to. It is a reasonable default and it couples three things that otherwise fail independently.
For the mechanics of creating a mailbox, creating email accounts in cPanel goes over the panel. This is about whether they belong there.
The disk is shared
Mail counts against the same allowance as the website. Years of attachments in one mailbox consume space the site also needs.
What makes this more than an accounting detail is what happens at the limit: a full account cannot write, so incoming mail is refused and the website stops working at the same moment. Uploads fail, database writes are refused, sessions break, and none of the resulting errors mentions disk.
Several unconnected faults appearing together is very often just a full account. Managing mailbox quotas sets out finding what filled it.
Use forwarders wherever you can
A forwarder passes mail to an existing mailbox and stores nothing. It uses no disk and cannot fill up.
Most role addresses: info@, sales@, support@, do not need their own mailbox at all. One person reads them; a forwarder is the correct shape.
Create mailboxes for people, forwarders for roles. That one rule keeps most accounts well under their allowance permanently. See setting up email forwarders.
The sending reputation is shared
Mail leaving a shared server leaves from the server's address, which is shared with every other account on it.
If a neighbouring account is compromised and sends spam, the address can be blocklisted, and your mail is affected by something you had no part in. Good hosts limit per-account sending rates precisely to contain this. For the setting, see Exim configuration and mail routing.
It is not a reason to avoid hosted mail. It is a reason to know that your mail's standing is partly outside your control.
Availability is shared too
A website that is down for an hour is an inconvenience. Mail that is refused for an hour may be lost, because the sender's server eventually gives up.
This is the coupling that matters most: moving the site to a new host, or an outage on the server, takes the mail with it. Anyone who has migrated a site and forgotten the mailboxes has discovered this. Planning a DNS cutover walks through keeping mail intact through a move.
When hosted mail is the right choice
A handful of addresses, modest volume, a business where email is correspondence rather than the product. It is included, it works, and separating it would be effort spent on a risk that is not real for you.
When to separate them
When mail matters more than the website does, which is true of most businesses that take enquiries or orders by email.
Separating means the site can be migrated, broken or moved between hosts without touching the mail, and the mail's reputation is nobody else's to damage. Using an external mail provider with your domain goes over arranging it, and the single change that makes it work is the MX record.
The mistake to avoid is a half-move: mail delivered elsewhere while the hosting account still accepts mail for the domain locally. Messages sent from a site on the same server are then delivered to a mailbox nobody reads, which is how enquiries vanish with no error anywhere.
Website email is a third path
Mail sent by the site (contact forms, order confirmations, password resets) does not go through your mailbox and is not affected by where the mailboxes live.
It is generated by the application, and it is the most commonly broken of the three because nobody notices when it stops. Fixing WordPress email not sending walks through it, and sending that mail through an authenticated service rather than directly from the server is what makes it reliable.
Two things that must be right either way
The domain's DNS has to authorise whoever sends for it, or the mail is treated as forged wherever it arrives. There is more on the records in SPF, DKIM and DMARC.
And the hosting account's contact address must not be a mailbox on that same account, or the warning that it is full is refused by the account it is warning. See contact information and notifications.
Check what the mailboxes are actually costing
Mail grows silently and shares the account's disk with the website, so the two compete without anybody deciding.
du -sh ~/mail 2>/dev/null du -sh ~/mail/*/* 2>/dev/null | sort -h | tail -8 find ~/mail -type f 2>/dev/null | wc -l
The file count matters as much as the size, since a mailbox is many small files and the file allowance is a separate limit from the disk one.
An account that cannot write because of mail is a website outage caused by a mailbox nobody opens, which is a common and avoidable failure. Managing mailbox quotas covers the limits.
Set a quota on every mailbox
An unlimited mailbox is one that consumes the account when something goes wrong, and something eventually does.
The usual causes are not people. An address receiving automated alerts, a mailbox catching bounces from a mailing, or an autoresponder answering a loop will each fill an account without anybody sending a message deliberately.
A quota converts that from an account wide failure into one mailbox that stops accepting mail, which is recoverable and visible. Set one on every address including the ones that seem unimportant, since those are the ones that fill.
Test both directions after any change
Mail configuration is the area where a change appears to work and half of it does not.
echo test | mail -s "giden test" [email protected] curl -sI https://webmail.example.com/ | head -1 dig example.com MX +short
Send from the account to an external address and send from an external address back. A configuration that delivers outbound and refuses inbound is a common intermediate state after a routing change.
Check where it landed as well as whether it arrived. Mail delivered to the spam folder has technically worked and practically has not.