If OpenCart order confirmations, password resets, or contact form emails aren't arriving, the fix is almost always the same: stop using the Mail engine set to PHP Mail and switch OpenCart to SMTP with real authenticated credentials. PHP's built-in mail() function gets filtered or dropped by most receiving mail servers because it doesn't authenticate and often doesn't match your domain's SPF record. SMTP with a real mailbox on your domain fixes that.
Flashcloud hosting includes email accounts on your domain (mail.yourdomain.com), and SPF and DKIM are configured automatically for hosted domains, so a mailbox you create for OpenCart will pass authentication checks that mail() can't.
Set OpenCart to use SMTP
In the OpenCart admin, go to System > Settings, open your store, and click the Mail tab. Change Mail Engine from Mail to SMTP, then fill in:
- SMTP Hostname:
mail.yourdomain.com(orssl://mail.yourdomain.comfor the encrypted variant, depending on your OpenCart version) - SMTP Username: the full email address, e.g.
orders@yourdomain.com - SMTP Password: that mailbox's password
- SMTP Port:
587for STARTTLS, or465if the field expects SSL directly - SMTP Timeout: 5-10 seconds is fine for most installs
Create the mailbox first if it doesn't exist: in the portal, go to the Email Accounts tile for your hosting service and add an account on the domain you're sending from. Don't use a mailbox on a different, unrelated domain than your storefront. Some receiving servers flag that mismatch as spoofing.
Why PHP mail() fails quietly
mail() hands the message to the server's local mail transport with no authentication and no guaranteed alignment between the "From" address and the sending server. Gmail, Outlook, and most spam filters increasingly reject or silently bin unauthenticated mail. OpenCart won't show an error for this: the order still saves, but the customer never gets the confirmation email. Switching to authenticated SMTP on a real mailbox fixes this across almost every PHP application, not OpenCart.
Test it
After saving the SMTP settings, place a test order or use OpenCart's password reset form to trigger an email. If nothing arrives within a minute or two:
- Double-check the mailbox password. A typo here is the most common cause of silent SMTP failures.
- Confirm the hostname resolves, run
ping mail.yourdomain.comfrom your own machine. - Log into that mailbox directly via webmail to confirm the account itself is working and isn't over quota.
- Check the spam folder on the receiving end before assuming OpenCart is broken.
If OpenCart throws a specific SMTP error (connection refused, authentication failed, timeout), that error tells you exactly which of the four fields above is wrong. A connection or timeout error points at hostname or port; an authentication failure points at username or password.
DNS notes
SPF and DKIM are set up automatically for domains hosted with us, which covers most deliverability issues once you're sending through an authenticated mailbox on that domain. If you change nameservers or DNS providers down the line, see changing nameservers at GoDaddy, Namecheap, and Cloudflare for what to check.
Stack notes for OpenCart on Flashcloud
OpenCart runs fine on our default stack: LiteSpeed Web Server, PHP 7.4 through 8.3 (set per domain from the PHP Version tile), and MySQL with phpMyAdmin for database access. If you installed OpenCart through Softaculous in cPanel, the app itself is otherwise unmanaged by us. Mail configuration, extensions, and updates are handled inside OpenCart's own admin. For general speed behavior on this stack (unrelated to the mail issue but worth knowing), see how we make your site fast.
If you'd rather manage the install from cPanel directly, you can reach it via the cPanel one-click login described in accessing cPanel.
When to contact support
If you've set SMTP correctly, confirmed the mailbox works in webmail, and mail still isn't sending or is landing entirely in spam across multiple providers, open a ticket from Support in the portal. Include the exact error OpenCart shows on send and the domain you're sending from. Our support team is made up of real people who can check whether anything on the mail server side (queue, rate limit, or a blocked port) is involved.