Adding a mailbox to an iPhone or iPad takes a couple of minutes, and the part that catches people is that iOS offers a shortcut which does not fit a cPanel mailbox. Choosing Other rather than a named provider is the whole trick.
Get the settings first
In cPanel, open Email Accounts and use Connect Devices for the mailbox. You need four things:
Host mail.yourdomain.com IMAP 993, SSL SMTP 465 SSL, or 587 STARTTLS Username the full address, [email protected]
The username being the whole address matters here as much as anywhere. Entering just the part before the @ produces a password error on a correct password.
Adding the account
Open Settings, then Apps and Mail, then Mail Accounts, then Add Account. Choose Other, then Add Mail Account.
Enter your name, the full email address, the password and a description. Tap Next and iOS will try to work the rest out.
It usually cannot, and it will ask for the server details. Select IMAP at the top, then fill in both the incoming and outgoing sections with the same hostname, username and password.
The outgoing section is where accounts fail. iOS labels the username and password fields there as Optional. They are not optional, leave them blank and receiving works while sending fails.
Fill them in with the same full address and password as the incoming server.
Push, fetch, and why mail seems slow
iOS defaults new accounts to Fetch, which checks on a schedule rather than delivering as mail arrives. On a cPanel mailbox that is the usual behaviour, and it is why someone reports their new phone getting mail later than their laptop.
Under Settings, Apps and Mail, Mail Accounts, Fetch New Data, you can set how often. Every 15 minutes is a reasonable compromise; setting it to Manual means mail only arrives when the app is opened, which people forget they chose.
More frequent fetching costs battery. Fetching every 15 minutes and accepting a short delay is usually the better arrangement than chasing instant delivery.
Mail app settings worth changing
Under the account's Advanced settings, check where deleted messages go. iOS sometimes uses a local Trash in place of the server's, so mail deleted on the phone stays visible in webmail and on other devices, and vice versa.
Setting the mailbox behaviours to the server's own Trash, Sent and Drafts folders makes every device agree, which is the point of IMAP.
Also check the signature. The default advertises the phone, which on a business address usually reads as unconsidered.
Deleting and re-adding is safe
Because IMAP keeps mail on the server, removing the account from the phone deletes nothing. Re-adding it downloads everything again.
That makes remove-and-re-add a reasonable first fix for an account behaving strangely, and it resolves a good share of iOS mail problems that resist any other explanation.
The exception is a POP3 account, where the phone may hold the only copy. If the account was ever set up as POP3, check before deleting anything.
Common failures
Cannot verify account details during setup. Usually the hostname or the username. Check both against Connect Devices, and confirm you selected IMAP rather than accepting a default.
Receives but cannot send. The outgoing username and password were left blank because iOS called them optional.
Cannot connect using SSL, and iOS offers to try without. Decline. Sending credentials unencrypted is worse than a broken account. Fix the port or hostname instead.
Certificate warning. The hostname does not match the certificate. Use the exact hostname cPanel provides rather than a shortened form.
Sending fails only on mobile data. The mobile network blocks the port. Use 587 rather than 465, or the reverse. One of the two usually passes.
Mail is in webmail but not on the phone. The mailbox is fine and the phone is not syncing that folder. Check the folder list in the account settings. Accessing webmail goes over using it to isolate exactly this.
Confirm the account is using the secure settings
A mail account added years ago may still be configured without encryption, and nothing prompts a review.
openssl s_client -connect mail.example.com:993 -servername mail.example.com </dev/null 2>/dev/null | tail -4 nc -zv -w 3 mail.example.com 143 2>&1 | tail -1
Where the unencrypted ports still answer, an old configuration keeps working and sends the password in the clear on every check.
Read the account's settings rather than assuming they were set correctly at the start. The two encrypted ports are the ones to use, and a configuration on the plain ports should be changed rather than left because it works.
Understand what the device is storing locally
A phone keeps a copy of the mailbox, and how much it keeps decides both the storage used and what is available offline.
The default is usually a recent period rather than everything, which is why searching for an old message on a phone returns nothing while the same search in webmail finds it immediately.
That is not mail being lost. It is the device holding a window, and the setting controlling that window is worth knowing before anybody concludes that messages have disappeared.
Removing the account does not delete the mail
People hesitate to remove and re-add an account because they believe it will delete their mail, and with the usual protocol it does not.
curl -sI https://webmail.example.com/ | head -1
The messages live on the server and the device holds a copy. Removing the account removes the copy, and re-adding it downloads the mail again.
The exception is the older protocol, which can be configured to remove messages from the server after download. On an account set up that way the device holds the only copy, and confirming which protocol is in use before removing anything is the check that matters. Accessing webmail confirms what the server still holds.