Deliver the messages your product needs
A separate path for receipts, account notifications and application events.
Content revised · English
- Architecture to evaluate
- Receipts / resets / alerts
- Prepared starting points
- 3 plans
- Responsibilities
- Application, rights and recovery
A fit shortlist, not installed software or live inventory.
Keep these in view.
- Receipts / resets / alerts.
- Make a queue that can retry safely.
- Close the feedback loop.
Receipts / resets / alerts
A receipt, password-reset notice or product alert should retain its transactional purpose. Keep promotions under a distinct consent and unsubscribe design. Authenticate the domain and restrict who can trigger a message or change a template.
Make a queue that can retry safely
Use an application-level message identifier, bounded retries and backoff. Reconcile an uncertain send result before generating duplicates. Avoid logging reset tokens or unnecessary personal information, and redact sensitive values in support records.
Close the feedback loop
Handle bounces, complaints and suppressed recipients in the application. The SMTP tier’s domain and message limits remain explicit. A SendGrid-compatible API, webhook delivery and a live sender dashboard are future integration questions, not available local controls.
Keep the purpose clear
Transactional messages relate to a user's activity or account. Marketing content can change the classification and obligations, so keep essential notifications focused and consent handling separate.
Authenticate the domain
Use the provider's exact SPF and DKIM values and introduce DMARC with reporting you can interpret. An authenticated sender is only one factor in delivery; content, reputation and recipient systems also matter.
Design for repeat delivery
Queue events, make message generation idempotent and track delivery outcomes without storing secrets in logs. Never email plaintext passwords or full recovery credentials.
Know the mail pipeline
In a self-managed design, a mail transfer agent such as Postfix handles submission and relay, while a separate filter such as Rspamd can score messages and recommend actions. Filtering may inspect headers, URLs or body content depending on configuration. A privacy statement must describe that real processing; naming a spam filter cannot also establish that no content is evaluated.
- Document message processing, access and retention at each component.
- These software roles are examples, not a connected OmbraHost mail stack or an installed application included with the configuration.
Capacity to consider.
Match these starting points to the representative application. Software installation and live inventory are not connected; the exact specification and period total come from the catalogue.
Signal 1K
Send up to 1,000 messages per day through a relay configuration with one dedicated IPv4 address and PowerMTA or Postfix tooling. A prepared IP is available separately, making this a starting point for permission-based or transactional mail with domain authentication and sender reputation managed deliberately.
- Transfer
- Unmetered
billed monthly
Signal 10K
Scale permission-based or transactional delivery to 10,000 messages per day across three dedicated IPv4 addresses. The configuration includes IP rotation tooling and SPF, DKIM and DMARC setup, while successful delivery still depends on consent, content, recipient policies and the reputation of your sending domains.
- Transfer
- Unmetered
billed monthly
Signal 50K
Build a larger sending configuration with a daily allowance of 50,000 messages, ten dedicated IPv4 addresses and support for multiple domains. Delivery monitoring tooling is part of the service specification, with authentication, consent and reputation controls remaining essential at this volume.
- Transfer
- Unmetered
billed monthly
Before this workload goes live.
- Check the exact plan’s CPU, memory, disk, transfer and port.
- Choose a listed region and verify the workload’s permitted use.
- Test the representative application and an independent restore.
Questions, answered.
Is this a drop-in SendGrid API?
No compatible API or webhook sender is connected. SMTP and application-side queues are the prepared design; any API compatibility needs a separate tested contract.
Who owns templates?
The application maintains its message templates, versions and sensitive substitution rules. No live template editor is supplied by the catalogue.
How do I judge delivery?
Track submission, recipient-server acceptance, bounces and complaints separately. Acceptance is not proof of inbox placement or reading.
Can I send from my own domain?
A live sender needs the domain’s SPF/DKIM/DMARC, correct identity and permitted use. Check the exact plan’s domain count, then verify authentication before sending.
What is kept in my account workspace?
Your configuration, selected plan, image, location and billing term are kept with the order and payment request references. Quotes, payment-state reads and support conversations remain linked to your account. Read fulfilment details separately from payment status.