Why phpFox Email Stalls on Shared Hosting

phpFox generates a large volume of transactional mail: registration confirmations, password resets, friend requests, notification digests, and admin alerts. On a managed shared account the most common failure is that phpFox defaults to PHP's built-in mail() function, which hands messages to the local mail transport with no authentication. Messages sent this way frequently land in spam or are silently discarded by receivers like Gmail, Outlook, and Yahoo, because the sending address does not align with an authenticated envelope and the message lacks a valid DKIM signature.

The second recurring problem is the sender identity itself. Many installations are configured to send from an address that does not exist as a real mailbox on the account, or from a free-provider address such as a Gmail account. Receiving servers check that the domain in the From header authorizes your hosting server to send on its behalf. When the domain has no SPF record, or the SPF record does not include the sending host, the message fails authentication and delivery becomes unpredictable.

A third issue is unique to community software: phpFox batches notification and bulk mail into a database queue that only drains when a scheduled task runs. If cron is not firing, or the mail cache is stuck, individual actions may send instantly while digest and mass emails never leave the server. Because you are working as an unprivileged hosting user, every fix here happens inside the phpFox AdminCP, the control panel email and DNS tools, and account-level files like .user.ini. You will not touch server daemons, my.cnf, or anything under /etc/.

Configure Authenticated SMTP in the phpFox AdminCP

Routing phpFox through authenticated SMTP on your own domain is the single change that resolves most deliverability complaints. Start by creating a dedicated mailbox for outbound application mail. In cPanel open Email Accounts, click Create, and add something like no-reply@yourdomain.com with a strong password. In DirectAdmin the equivalent path is E-Mail Manager » E-Mail Accounts » Create Account. Using a real mailbox matters because SMTP authentication requires valid credentials that map to an actual account on the server.

Log in to the phpFox AdminCP and navigate to Settings » Mail Settings (in newer releases this appears under Admin CP » Settings » Server » Mail Server). Change the transport method from PHP mail() to SMTP and enter the credentials that match your control panel account:

Mailer:            smtp
SMTP Host:         mail.yourdomain.com
SMTP Port:         465
Encryption:        SSL
SMTP Auth:         Yes
SMTP Username:     no-reply@yourdomain.com
SMTP Password:     (the mailbox password)

If port 465 with SSL does not connect, use port 587 with STARTTLS instead, which many LiteSpeed-based accounts prefer for submission. Because the certificate on mail.yourdomain.com must match the hostname, always use the fully qualified mail hostname rather than localhost or a raw IP; mismatched hostnames trigger TLS verification errors that phpFox logs but users never see. Save the settings, then use the built-in Send Test Email button. If phpFox lacks that control in your version, trigger a password reset for a test user and watch for arrival.

When the test fails, the fastest diagnostic path is the application log. In File Manager browse to your phpFox root and open PF.Base/file/log/ (or PF.Base/log/ depending on version) and read the most recent entry, alongside the account error_log that cPanel or DirectAdmin drops in the site's document root. Authentication rejections, TLS handshake failures, and connection timeouts each produce a distinct message that tells you whether the credentials, the port, or the encryption mode is wrong.

Sender Settings and DNS Alignment (SPF, DKIM, DMARC)

Authenticated SMTP gets the message off the server, but receiving providers still validate the sending domain against DNS. Set the phpFox outbound identity to match the mailbox you authenticate with. In Mail Settings set both the site email and the default From name and address to no-reply@yourdomain.com. A mismatch between the SMTP login domain and the visible From address is a classic trigger for spam filtering, so keep them on the same domain.

Next confirm the three DNS records that govern authentication. On a managed account these are edited through the control panel, never by hand in a zone file on the server. In cPanel the relevant tools are Email Deliverability and, for manual entries, the Zone Editor. DirectAdmin exposes the same under DNS Management. The Email Deliverability page is the quickest option because it shows a red or green status for SPF and DKIM and offers a one-click Repair that inserts the correct records for your server.

A working SPF record authorizes your hosting platform to send. It should resemble the following TXT record on the root domain, with the include value matching what your control panel recommends:

Type:  TXT
Name:  @
Value: v=spf1 +mx +a +ip4:YOUR.SERVER.IP ~all

DKIM adds a cryptographic signature so receivers can verify the message was not altered and truly came from your domain. Let cPanel's Email Deliverability » Manage » Install the suggested record generate and publish the DKIM key rather than composing it manually, since the private half lives on the server side. Finally, publish a light DMARC policy so major providers report and honor your alignment. A safe starting policy that monitors without rejecting legitimate mail looks like this:

Type:  TXT
Name:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com; adkim=r; aspf=r

Allow up to a few hours for DNS propagation, then send a fresh test to an external address and inspect the received headers for spf=pass, dkim=pass, and dmarc=pass. If any show fail or none, revisit the record that failed before moving on.

Queue Processing, Send Limits, and PHP Timeouts

phpFox queues bulk and notification mail rather than sending it inline, and that queue only empties when the scheduled task runs. The phpFox cron entry that drives this is documented in the companion piece on setting up cron jobs for phpFox in DirectAdmin; make sure that job is present and firing at least every five minutes. Without it, individual resets may send while digests and mass mailings pile up in the phpfox_mail_queue table.

You can confirm the backlog directly. In phpMyAdmin select your phpFox database and run a read-only count against the queue table using your actual table prefix:

SELECT COUNT(*) FROM phpfox_mail_queue WHERE is_sent = 0;

A number that keeps climbing means the cron worker is not draining the queue; a number that stays near zero means delivery is healthy. Avoid manually deleting rows unless you intend to discard those messages permanently.

Shared hosting also caps how many messages an account may send per hour to protect the server's reputation. Sending thousands of digest emails in one burst will hit that ceiling and cause deferrals. In the phpFox AdminCP look under Mail Settings for the per-run send batch size and lower it so each cron pass sends a modest chunk, letting the queue drain steadily within your account limits. This throttling keeps you well under the hourly relay cap while still clearing the backlog over successive runs.

PHP execution limits can also cut off a long-running mail batch. Because you cannot edit server config, apply overrides at the account level. Create or edit .user.ini in your phpFox document root with values that give the queue worker room to complete without exhausting memory:

max_execution_time = 120
memory_limit = 256M
SMTP = mail.yourdomain.com
smtp_port = 587

Confirm the active PHP version and that .user.ini overrides are permitted through cPanel's MultiPHP INI Editor or the DirectAdmin PHP Selector; phpFox performs best on a currently supported PHP branch. After any change, wait for the file's refresh interval, run the cron worker again, and recheck the queue count. When authenticated SMTP, aligned DNS, and a steadily draining queue all line up, phpFox mail reaches inboxes reliably.