Akaunting is a Laravel-based accounting application, and its email behavior inherits every quirk of Laravel's mail and queue subsystems. When invoices refuse to send, payment reminders never arrive, or the "Send Invoice" button spins and then reports success while the recipient sees nothing, the problem is almost always one of four things: the wrong mail transport, missing or mismatched SMTP authentication, a queue that is configured but never processed, or a sender address your hosting server refuses to authenticate. None of these require root access to fix. All of them can be resolved through the Akaunting Settings panel, cPanel or DirectAdmin email tools, and a small amount of file editing through File Manager.

On a Managed Cloud Shared Hosting account running LiteSpeed and CloudLinux, outbound mail is handled by the local mail server, but you do not get to reconfigure it globally. You authenticate as a mailbox user over SMTP the same way any desktop mail client would. Understanding that distinction is what separates a working Akaunting install from one that quietly drops every message.

Why Akaunting Email Fails on Shared Hosting

Akaunting stores its mail configuration in two places, and this dual system is the source of most confusion. The first is the database, populated through Settings → Email in the AdminCP. The second is the environment file, .env, located in the Akaunting document root. Values set in the AdminCP override the .env defaults for the active company, but if the database rows are empty or the company was created before you configured mail, Akaunting falls back to .env. When the two disagree, you get intermittent behavior where one company sends and another does not.

The default installation often ships with MAIL_MAILER=mail or MAIL_MAILER=sendmail. The PHP mail() function and raw sendmail paths are unreliable on shared hosting because the message is injected without SMTP authentication. LiteSpeed and the mail server will accept it, but the envelope sender frequently does not match an authenticated domain, so remote providers like Gmail and Outlook drop it into spam or reject it outright at the SMTP conversation. Authenticated SMTP against your own mailbox produces a properly signed, traceable message that passes SPF and DKIM checks.

The second common failure is the queue. Akaunting queues email by default when QUEUE_CONNECTION is set to database or redis. Queued jobs sit in the jobs table and are never sent unless a worker processes them. On shared hosting there is no persistent daemon, so a queued message waits forever. The AdminCP reports the job as dispatched successfully, which is why the interface says the invoice was sent while nothing actually leaves the server. You either process the queue with a cron job or switch mail to synchronous sending.

Configuring Authenticated SMTP the Right Way

Start by creating a dedicated mailbox for the application. In cPanel Jupiter open Email Accounts and create something like billing@yourdomain.com with a strong password. In DirectAdmin Evolution the equivalent is E-Mail Manager → E-Mail Accounts. Using a real mailbox rather than a forwarder or alias is what lets the server authenticate the outgoing session.

Next, configure Akaunting itself. Log into the AdminCP, go to Settings → Email, and set the protocol to SMTP. Use these values, adjusting the host to your server's hostname:

Protocol:        SMTP
SMTP Host:       mail.yourdomain.com
SMTP Port:       465
SMTP Username:   billing@yourdomain.com
SMTP Password:   (the mailbox password)
SMTP Encryption: SSL

Port 465 with SSL is the most consistent choice on LiteSpeed-based hosting. If your server prefers STARTTLS, use port 587 with encryption set to TLS instead. Avoid port 25 for authenticated submission; it is frequently rate-limited or blocked for user traffic.

If you prefer to set these values in the environment file, edit .env through cPanel File Manager. Enable "Show Hidden Files (dotfiles)" in the File Manager settings first, then edit the file in the Akaunting root:

MAIL_MAILER=smtp
MAIL_HOST=mail.yourdomain.com
MAIL_PORT=465
MAIL_USERNAME=billing@yourdomain.com
MAIL_PASSWORD=your_mailbox_password
MAIL_ENCRYPTION=ssl
MAIL_FROM_ADDRESS=billing@yourdomain.com
MAIL_FROM_NAME="Your Company"

The MAIL_FROM_ADDRESS value matters more than people expect. It must be a mailbox on the same domain you are authenticating with. When the from-address domain matches the authenticated SMTP domain, the message aligns cleanly with SPF and DKIM, and inbox placement improves dramatically. A from-address of noreply@gmail.com sent through your own server will fail alignment and land in spam.

After changing .env, clear Akaunting's cached configuration. Laravel caches config aggressively, so a stale cache will keep serving old mail settings. Delete the cache files under bootstrap/cache/ (specifically config.php if present) and the compiled files under storage/framework/cache/ using File Manager. Akaunting will rebuild them on the next request.

Making the Queue Actually Send Mail

Decide whether you want synchronous or queued email. For a small business sending a handful of invoices a day, synchronous sending is simpler and eliminates the silent-failure problem entirely. Set the queue connection to sync in .env:

QUEUE_CONNECTION=sync

With sync, every email is dispatched immediately during the web request. The trade-off is that sending a large batch of reminders will make that page slower to load, since the request waits for each SMTP handshake.

If you send in volume and want to keep QUEUE_CONNECTION=database, you need a cron job to drain the queue. In cPanel open Cron Jobs, or in DirectAdmin open Cron Jobs under Advanced Features, and add a task that runs the Akaunting queue worker on a short cycle. Use the PHP binary matching the version selected in MultiPHP Manager or the CloudLinux Select PHP Version selector:

* * * * * /usr/local/bin/ea-php82 /home/username/public_html/artisan queue:work --stop-when-empty --tries=3 >/dev/null 2>&1

Replace the PHP path, username, and document root with your own. The --stop-when-empty flag is essential on shared hosting: it processes waiting jobs then exits, so you never leave a long-running daemon that CloudLinux would kill for exceeding process limits. Running once per minute keeps reminders timely without violating resource caps. If your workflow already uses a scheduler, the same principle applies to the approach described in our guide on running Laravel-style queue workers with a single cron line.

DNS Alignment and Verifying Delivery

Authenticated SMTP gets your message out, but DNS decides whether it lands in the inbox. Three records matter. Your SPF record must authorize the server sending on your behalf; on managed hosting this is usually a single include for the server, added automatically when the domain uses local mail, viewable under cPanel Zone Editor. A typical value looks like v=spf1 +a +mx +ip4:server.ip.here ~all. Confirm the sending server's IP is covered.

DKIM signs each message cryptographically. In cPanel go to Email Deliverability, find your domain, and if DKIM shows as anything other than valid, click Repair to publish the correct TXT record. DirectAdmin exposes the same under DNS Management with a _domainkey selector. Once DKIM is valid, messages from your authenticated mailbox carry a signature that Gmail and Outlook trust.

A DMARC record ties SPF and DKIM together and tells receivers what to do with failures. A gentle starting policy added as a TXT record for _dmarc.yourdomain.com is v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com. This monitors without blocking while you confirm alignment, then you can tighten to p=quarantine later.

When something still fails, read the application log rather than guessing. Akaunting writes to storage/logs/laravel.log inside the document root, viewable through File Manager. SMTP authentication failures, connection timeouts, and TLS negotiation errors appear there with the exact exception. A message like "Connection could not be established" points to a wrong host or blocked port; "Expected response code 235" means the username or password is wrong. Send a test message from Settings → Email if your Akaunting version offers the test button, or trigger a real invoice to a mailbox you control, then check the recipient's raw headers for spf=pass and dkim=pass. When both pass and the from-domain matches, delivery is stable.