Email delivery and deliverability issues

Diagnose outbound mail on TurboStack - mail that fails to send, stuck queues, and mail that lands in spam - and where to fix each cause.

Outbound (transactional) mail on TurboStack is handled by the local mail service on your host. Email problems fall into two very different categories - and it's important to know which one you have before you start fixing things:

  • Mail that never sends (send errors, or recipients never receive it) - diagnosed below.
  • Mail that sends but lands in spam - fix by authenticating your domain. See Mail deliverability for the full SPF, DKIM and DMARC and blocklist guide, and SMTP error codes for a 5.7.x bounce our support team may link you to.

Symptoms

  • The application reports a send error, or users never receive expected mail (password resets, order confirmations).

  • Mail is delivered but consistently lands in recipients' spam/junk folders.

  • Some providers (for example large mailbox providers) accept your mail while others bounce it.

Diagnose it on TurboStack

  1. Rule out a development mail-catcher. In the host's Advanced > Mail Settings, check that mail capturing/testing (Mailpit or Mailhog) is off. When it is on, outbound mail is captured, not delivered - it is a development tool and must never be left on in production (Configure mail).

  2. Inspect the mail log and queue over SSH. Connect to the host (SSH) and check the mail log and queue (see below).

  3. Test from the receiver's side. Send to a few different providers and look at whether mail is rejected, accepted-to-inbox, or accepted-to-spam - that tells you which category you're in.

Checking mail logs and the queue over SSH

The mail log records every delivery attempt with the result and any remote error message - this is the single most useful diagnostic for "not sending":

# Recent mail activity (Debian/Ubuntu)
tail -n 100 /var/log/mail.log

# On AlmaLinux/RHEL the log is usually:
tail -n 100 /var/log/maillog

# Inspect the outbound queue (stuck or deferred messages)
mailq

Look for status=sent (delivered), status=deferred (will retry - note the reason), or status=bounced (rejected - the remote server's reason follows). The remote reason often names the exact problem: a missing PTR/SPF record, a blocklist, or an authentication failure.

Mail not sending

Mail intercepted by a development catcher

The most common cause is a development mail-catcher (Mailpit or Mailhog) capturing outbound mail instead of sending it. Turn off mail capturing in Advanced > Mail Settings on production - see Configure mail.

Application mail misconfiguration

If the server can send but the app can't, the application's mail settings are usually wrong:

  • Wrong From address - many receivers reject mail whose From domain doesn't match an authorised sending domain. Use a From address on a domain you control and have authenticated.

  • SMTP settings pointing nowhere - if the app is configured for an external SMTP server with the wrong host, port, or credentials, sends fail or hang. For local delivery, point the app at the local mail service rather than a remote SMTP server.

  • Sender/return-path mismatch - a return-path that doesn't align with your SPF record causes failures at strict receivers.

Fix these in your application's own mail configuration, then resend and re-check the mail log.

Messages stuck in the queue

If mailq shows messages piling up as deferred, check the log to find out why. Common reasons: the remote server is temporarily unavailable, the connection is blocked, or your IP/domain is on a blocklist. Address the underlying reason; the mail service retries deferred mail automatically.

Mail landing in spam

Delivered-but-flagged mail is almost always missing or incorrect domain authentication (SPF, DKIM, DMARC), or a blocklisted sending IP. The full guide - the DNS records, the SPF 10-lookup limit, DMARC alignment, blocklists (RBLs) and when to move to an external SMTP provider - is on Mail deliverability.

When to contact support

If mail still won't send after the mail-catcher is off and the app is configured correctly, or if a PTR/reverse-DNS or IP-reputation issue is involved, contact support. Include the host, the sending domain and From address, the recipient that failed, the relevant mail-log lines, and what changed recently.

© 2026 Hosted Power — TurboStack