Email problems fall into three groups, and identifying which one you have takes about a minute. Mail not arriving at all, mail arriving in spam, and mail you send being rejected are different failures with different causes, and treating them as one problem is why they take so long to fix.
Check these three first
Is the account over its disk quota? A full account cannot write anything, so incoming mail is rejected. The client experiences this as several unrelated failures at once (email stopped, uploads fail, forms break) and none of it mentions disk.
Is the individual mailbox full? Separate from the account quota. cPanel sets a per-mailbox limit, and a mailbox collecting everything since 2019 reaches it.
Do the MX records point where you think?
dig MX yourdomain.com
These three explain a large share of email problems and take under a minute to rule out. Everything below assumes they are fine.
Mail is not arriving
With quota and MX ruled out, check the spam folder: both in the mail client and in webmail, because a server-side filter may have moved it somewhere the client never sees.
Then check filters. A rule created years ago and forgotten deletes matching mail silently, and cPanel holds both account-level and user-level filters, look at both.
Test delivery directly: send a message from an external address and watch what happens. If the sender gets a bounce, read it. Bounce messages name the reason precisely, and reading one saves more time than any amount of guessing.
A bounce saying the mailbox does not exist means exactly that: usually a typo in the address, or a mailbox deleted while a forwarder still points at it.
Mail arrives in spam
Almost always authentication. Without SPF, DKIM and DMARC, major providers treat your mail as suspect regardless of content.
Set all three up (understanding SPF, DKIM and DMARC walks through it) then verify by sending to a major provider and reading the received headers, which report each check's result.
If all three pass and mail still lands in spam, the problem is reputation rather than configuration. A new IP address, or one with history, takes time to build trust. Content matters too: a message that is one large image with a link looks like the things filters are built to catch.
Check whether the sending IP is listed on a blocklist. If it is, the listing usually explains why and how to request removal, and if the cause was a compromised account on the server, fixing that comes first or the listing returns.
Cannot send
If receiving works and sending does not, the problem is between the mail client and the server.
Check that outgoing authentication is enabled in the client. Many clients default to off for the outgoing server, which produces a relay-denied error that reads as a permissions problem.
Check the port. Port 25 is blocked by a great many home and mobile networks to limit spam, and a client configured to use it will simply time out. Use 587 with STARTTLS, or 465 with SSL.
Try the same account in webmail. If sending works there and not in the client, the server is fine and the client configuration is wrong, which narrows the search considerably.
The website cannot send
Contact forms, order confirmations and password resets are a separate case, and they fail independently of mailbox settings.
The classic cause: MX records were pointed at an external mail provider, but the server still believes it handles mail for the domain. Mail sent by a script on that server is delivered locally instead of going out, so it lands in a mailbox nobody reads, or nowhere.
Setting the domain's mail routing to remote fixes it. This step is missed almost every time a client moves mail to an external provider, and the symptom is confusing: external mail works perfectly, and the contact form's messages vanish.
The other common cause is that the application uses the server's basic mail function, which many receiving servers distrust. Configuring the application to send through authenticated SMTP using a real mailbox is more reliable and passes authentication properly.
Sudden failure after a change
If mail worked yesterday, something changed. In order of likelihood:
The account filled up. The domain expired. DNS was edited and MX records changed or were lost. A certificate expired, breaking the encrypted connection the client insists on. Or the account was suspended.
Check those before investigating anything subtle. Mail is more often broken by something adjacent than by mail configuration itself.
After a migration
Two things break predictably when a site moves.
SPF and DKIM records referenced the old host and are now wrong; they need regenerating for the new server. This is why mail from a freshly migrated site so often goes to spam.
And mail sent during DNS propagation may have been delivered to the old server. Keep the old account alive for a week and check it, or messages sent in that window are simply lost.
What to gather before opening a ticket
If you need help, these five things turn a long exchange into a short one: the exact bounce message, the sending and receiving addresses, whether it fails in webmail as well as the client, when it last worked, and what changed around then.
The bounce message is the single most useful of these, and the one most often omitted.
When a bounce did arrive, it usually contains the diagnosis already. For reading it, see Understanding Email Bounces and Delivery Codes.
If the account is sending mail nobody wrote, this is not a delivery problem. What to Do When an Email Account Is Compromised deals with the order of the response, including the step people skip.