Why AzuraCast Mail Breaks on a Hosting Account

AzuraCast was designed as a Docker-based appliance that ships with its own mail transport and expects to control the outbound mail path end to end. When you run it inside a managed shared hosting environment, that assumption no longer holds. There is no local MTA you are permitted to configure at the system level, no ability to open arbitrary outbound ports, and no root to adjust a Postfix or Exim relay. The application still tries to send password resets, listener-report digests, and account notifications, but those messages silently fail or land in spam because nothing is telling AzuraCast how to hand mail off to an authenticated SMTP service.

The outbound port situation is the first thing worth understanding. Most managed platforms block direct connections on port 25 to curb abuse, and they frequently restrict unauthenticated SMTP entirely. That means any AzuraCast configuration relying on a sendmail binary or a bare localhost relay will time out or be refused. The messages queue internally, retry, and eventually disappear from view with nothing more than a cryptic connection error in the logs. The fix is not to fight the platform but to point AzuraCast at an authenticated SMTP account that the hosting environment already permits: a mailbox you create inside cPanel or DirectAdmin, or an external transactional provider over the submission ports 587 or 465.

The second issue is identity. Even when a message leaves successfully, receiving servers judge it against the sending domain's DNS records. If AzuraCast sends as noreply@yourdomain.com but the message physically originates from an SMTP host that is not authorized in your SPF record, or is not signed with a DKIM key your domain publishes, inbox providers downgrade or reject it. On shared hosting you cannot touch the server's global mail identity, but you can absolutely manage the DNS zone and the sender address AzuraCast presents. Getting those two layers aligned is what turns a failing notification into a delivered one.

Configuring Authenticated SMTP Inside AzuraCast

Start by creating a dedicated mailbox you will send from. In cPanel open Email Accounts under the Email section and add something like radio@yourdomain.com with a strong password. In DirectAdmin the equivalent lives under E-Mail Manager > E-Mail Accounts. Creating a real mailbox matters because the credentials you generate here are what AzuraCast will authenticate with, and because a mailbox backed by your own domain aligns cleanly with the DNS records you control. Note the incoming/outgoing server hostname cPanel shows on the Connect Devices screen, typically mail.yourdomain.com or the server's own hostname.

Inside AzuraCast, mail settings are managed from the AdminCP rather than any file you would edit by hand. Log in as an administrator and navigate to System Administration > Settings > Services, then open the Email Delivery (sometimes labeled Mail Delivery Service) panel. Switch the delivery method from the default internal transport to SMTP. Fill in the fields as follows:

Mail Delivery Service: SMTP
SMTP Host: mail.yourdomain.com
SMTP Port: 587
SMTP Secure (TLS): Enabled
SMTP Username: radio@yourdomain.com
SMTP Password: (the mailbox password you created)
Sender Address: radio@yourdomain.com
Sender Name: Your Station Name

Port 587 with STARTTLS is the most widely accepted submission combination. If your host rejects 587, try 465 with implicit SSL/TLS enabled instead. Avoid port 25 entirely on shared hosting; it is almost always blocked outbound. The Sender Address must be a mailbox on a domain whose DNS you control, because that address is what SPF and DKIM will be checked against. Do not set the sender to a Gmail or Outlook address while authenticating through your own host, since the mismatch between the From domain and the authenticated sending infrastructure is exactly what triggers spam filtering.

Save the settings and use the Send Test Message button AzuraCast provides on the same panel. If it reports success but nothing arrives, the transport worked and the problem has moved downstream to DNS and reputation, covered next. If it reports a connection or authentication failure, the problem is still at the transport layer.

DNS Records: SPF, DKIM, and Sender Alignment

Authenticated delivery gets the message out; DNS gets it into the inbox. Because you manage your domain's zone through the control panel, you can publish the records receiving servers expect. In cPanel open Zone Editor; in DirectAdmin use DNS Management. If your domain already sends mail through the hosting account, cPanel likely created an SPF and DKIM record automatically under Email Deliverability, and you should confirm they are marked valid there before doing anything manual.

An SPF record authorizes the hosts allowed to send for your domain. If you send through your own cPanel mail server, a record like the one below is typical. Adjust the include to match whatever your host documents, and keep it to a single SPF TXT record at the zone apex:

Type: TXT
Name: yourdomain.com
Value: v=spf1 +mx +a include:yourhost.com ~all

DKIM signs outgoing mail with a private key so receivers can verify the message was not tampered with and genuinely came from your domain. cPanel's Email Deliverability page generates the key pair and shows the exact TXT record for the default._domainkey selector; click Manage and then Install the suggested record if it is not already present. If you authenticate AzuraCast through an external transactional provider instead of your own mailbox, use that provider's selector and SPF include values rather than the host's. A DMARC record ties the two together and tells receivers what to do with failures:

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

Start DMARC at p=none so you can monitor reports without blocking legitimate mail, then tighten to quarantine once SPF and DKIM consistently pass. Remember that TXT changes take time to propagate, so wait before concluding a change did not work.

Queue Handling, Logs, and Verifying Delivery

AzuraCast relies on its own background worker to process and send queued mail rather than sending synchronously during the web request. On a constrained hosting account that worker may not run on the schedule the appliance assumes, which is why notifications sometimes sit unsent even with correct SMTP settings. The broader background-task behavior is covered in our companion piece, on running queue workers without Supervisor or SSH daemons, and the same principles apply: mail will only flow as fast as the queue is actually drained. After changing SMTP settings, trigger an action that forces an immediate send, such as a password reset, to confirm the live path rather than relying on queued items.

When a test fails, read the error before changing settings blindly. AzuraCast surfaces mail errors in the AdminCP under System Administration > System Logs, and the underlying PHP messages land in the account's error_log which you can open through cPanel's File Manager in the application directory. A message containing Connection timed out points to a blocked port, so switch between 587 and 465. An authentication failed or 535 response means the username or password is wrong, so re-copy the mailbox credentials. A certificate or TLS error usually means the hostname you entered does not match the certificate on the mail server, so use the exact hostname from the Connect Devices page rather than a bare domain.

Once a test message arrives, verify it passed authentication. In Gmail, open the message, choose Show original, and confirm SPF, DKIM, and DMARC all read PASS. If SPF passes but DKIM fails, the signing key in DNS does not match what the sending host uses, so regenerate it from Email Deliverability. Keeping the sender address, the authenticated mailbox, and the DNS records all pointed at one domain you control is the combination that produces consistent, inbox-level delivery from AzuraCast on shared hosting.