SMTP and e-mail queue

Why configure multiple SMTP profiles

An ISP may use separate senders for administration, billing, technical support, sales, or different verified domains. Multiple profiles keep the visible identity, credentials, reputation, and provider limits of those flows separate.

Creating a profile does not automatically route every message through it. Each module or communication setting must select the intended SMTP profile, and the default is used only by flows that explicitly rely on the default transport.

Profile fields

Give the profile a clear internal name, then configure the public From name and email address, SMTP host, username, dedicated application password or credential, port, encryption mode, and default status. The visible address must be permitted by the authenticated mailbox or provider policy.

Do not reuse a personal mailbox password when the provider supports application credentials. Keep host and username distinct, use the exact fully qualified server name expected by its certificate, and never place SMTP secrets in templates, tickets, screenshots, or diagnostic exports.

Port and encryption

Choose the port and encryption combination documented by the provider. Submission commonly uses STARTTLS on port 587 or implicit TLS on port 465; port 25 may be filtered or reserved for server-to-server delivery. Do not guess TLS mode from the port alone.

Keep certificate verification enabled, confirm the server hostname matches the certificate, and check whether the provider requires SMTP authentication before or after TLS negotiation. A timeout, TLS handshake failure, and invalid credentials are different problems and require different corrections.

Default profile, saving, and editing

Mark one profile as default only after it has been tested and authorized for the ISP’s normal sender domain. When another profile becomes default, review modules that inherit this choice and make sure their From name, reply handling, and templates still make sense.

Editing host, credentials, sender, port, or encryption affects future deliveries and retries. Existing queued messages may retain their event data but use the updated transport when processed, so coordinate changes with the queue and avoid rotating credentials in the middle of an unexplained backlog.

Connection test and monitoring

Run the built-in test after saving. It should verify network reachability, TLS negotiation, and authentication; then send a controlled message to an authorized mailbox and confirm Inbox or expected spam placement. Server acceptance alone does not prove that the recipient received the message.

Record the provider response without exposing credentials, monitor quota and rejection trends, and repeat a real delivery test after DNS, sender, password, firewall, hosting, or provider changes. If several profiles exist, test each independently.

SPF, DKIM, and DMARC

Publish an SPF record that authorizes the actual sending provider without exceeding lookup limits. Enable DKIM with the selector and public key supplied by that provider, then verify that the signed domain aligns with the visible From domain.

Introduce DMARC with reporting and a monitoring policy, study legitimate sources, then move deliberately toward quarantine or reject. SPF, DKIM, and DMARC are domain controls outside the SMTP form: a successful login does not prove they are configured, and an incorrect strict policy can reject genuine ISP Billing messages.

How the e-mail queue works

The operational queue shows pending, processing, retried, and failed jobs with recipient, subject, event type, attempt count, error, and next eligible execution time. A scheduled command-line dispatcher claims bounded batches and sends them through the selected profile.

Successful jobs leave the active queue according to the application flow. A processing row that remains locked beyond the safety period can be recovered by the supported worker logic. Opening or refreshing the queue page does not dispatch messages; the scheduler must be installed, non-overlapping, and monitored.

Retry, Remove, and Clear queue

Use Retry only after correcting the cause, such as invalid credentials, unavailable host, rejected sender, malformed recipient, quota, or content. First determine whether the provider may already have accepted the message, because retrying an uncertain delivery can send a duplicate invoice or notification.

Remove cancels one queued job without undoing the business event that created it. Clear queue can discard many pending communications and therefore requires deliberate authorization, a reviewed filter or scope, and an alternative plan for messages that still have to reach customers.

Diagnosis

Diagnose in order: selected profile, enabled state, host and DNS, route and firewall, port, TLS mode and certificate, username and password, permitted From address, provider quota, recipient syntax, message size, attachment access, and provider response. Then check SPF, DKIM, DMARC, bounce information, and recipient filtering.

For queue problems, also verify scheduler execution, locks, attempts, next-run time, and whether the related document or communication was regenerated. Preserve only redacted error evidence and never publish message bodies, customer addresses, or credentials in the manual.

Checklist

• Use dedicated credentials
• Match port and encryption
• Authorize the From address
• Configure SPF, DKIM, and DMARC
• Test actual delivery
• Select SMTP in each module
• Monitor queue and CLI dispatcher
• Fix before retrying
• Assess duplicate risk
• Protect credentials and message data