WordPress sends mail by handing it to PHP's mail() function, which passes it to the server's local mail program. It works, and mail sent that way is increasingly treated as suspicious by receiving servers, because that is also how a compromised script sends spam.
The result is the most misleading failure in WordPress: nothing reports an error, and the mail never arrives.
Establish which failure you have
There are two, and they need different fixes.
WordPress is not sending at all. A plugin is intercepting mail, or the function is disabled.
WordPress is sending and the recipient is discarding it. Far more common, and invisible from your side.
Install a mail-logging plugin, or use the test-mail feature in an SMTP plugin, and send yourself a message. If the log records a successful send and nothing arrives, it is the second case, and no amount of reconfiguring WordPress will fix it.
Why the mail gets discarded
Mail from mail() typically arrives with a sender address the server is not authorised to send for.
The default sender is [email protected], an address that usually does not exist. Receiving servers check whether the sending server is permitted to send for that domain (that is what SPF records are for) and a mismatch is a strong spam signal.
Worse, on shared hosting the sending server is shared. If another account has been sending spam, its reputation is attached to your mail too.
Understanding SPF, DKIM and DMARC walks through the records that decide this.
The fix: send through SMTP
Instead of handing mail to the local program, WordPress authenticates to a real mailbox and sends through it, exactly as an email client does.
The mail then comes from an address that exists, from a server authorised to send for the domain, and it is signed. That is the whole difference, and it resolves most deliverability problems on its own.
Install an SMTP plugin. Several good ones exist and they all do the same job; the configuration below is what matters.
Settings that work
First create a real mailbox for the purpose, [email protected] or similar, in cPanel. Creating email accounts goes into it.
Then in the plugin:
Host, your mail server, usually mail.yourdomain.com.
Port and encryption, 465 with SSL, or 587 with TLS. Use one of these two pairs. Port 25 is blocked on most networks and produces a timeout rather than an error message.
Username. The full email address, not just the part before the @. This is the most common configuration mistake.
Password. The mailbox password.
From address. The same mailbox. A From address that does not match the authenticated account is rejected by many servers, and it defeats the point.
Keep the password out of the database
Most SMTP plugins store the password in the database in plain text. A database backup then contains a working mailbox credential, and backups get emailed, downloaded and left in accessible places.
Better plugins allow the password to be defined in wp-config.php as a constant instead. Use that if it is offered; the file is outside the web root's reach in a normal setup and is not included in a database export.
When to use an external sending service
For a site sending a handful of contact-form and password-reset messages a day, your own mailbox is fine.
Above that; a shop sending order confirmations, or anything with a mailing list. A dedicated sending service is the right answer. They maintain sending reputation as their entire business, they report bounces and complaints, and they do not put your account's outbound quota at risk.
They also tell you when mail fails, which is the thing you have been missing all along.
Transactional and bulk mail are different problems
Order confirmations and password resets must arrive within seconds and go to one person who asked for them.
Newsletters go to thousands of people at once, and sending those through your hosting account will hit sending limits and can get the account suspended for what looks like spam.
Never send bulk mail through your hosting mailbox. Use a mailing service for that, and keep the site's own mailbox for transactional messages only.
Checking what actually happened
cPanel's mail delivery report shows every message the server attempted, with the result. A message that left successfully and was rejected by the recipient appears here with the reason, and the reason is usually specific enough to act on.
That report is the difference between guessing and knowing, and it is the first place to look rather than the last. For reading it, see email routing and track delivery.
If mail arrives in spam rather than not at all
That is progress and a different problem. Three things move it.
SPF and DKIM correctly configured for the sending domain.
A From address on your own domain instead of a free provider's. Sending as [email protected] from your server fails authentication by design.
Content that does not look like marketing when it is not. A password reset in a heavy HTML template with tracking pixels is treated as a campaign.
If nothing sends at all
Deactivate other plugins one at a time. Security and anti-spam plugins sometimes take over mail and drop it silently.
Check whether mail() is disabled on the account, some hosts do this to stop compromised scripts. If it is, SMTP is not merely an improvement, it is the only route available.
Contact forms are where this fails most visibly, and they have two settings of their own. How to Set Up Forms and Handle Submissions has the detail.
The durable fix is not to send from the web server at all. How to Send Application Email Through a Relay Service walks through routing it somewhere that reports what happened to each message.