Security at RAPID SMTP
We treat your SMTP credentials and contact lists with the same care we would want for our own. This page describes the controls that are currently enabled across the platform.
This page is maintained by RapidHost BD to answer common security questions about RAPID SMTP. It describes platform capabilities we operate today and is not a certification by any third party.
Encrypted SMTP credentials
Passwords are encrypted with AES before being written to the database and decrypted only inside the worker that delivers your email. They never appear in logs, exports, or admin views.
Row-level isolation
Every customer table enforces row-level security. A query authenticated as your workspace can only ever read or write your own rows, regardless of the underlying infrastructure.
Modern authentication
Passwords are hashed with a salted modern algorithm. Sessions are signed JWTs, refresh tokens rotate, and admin paths additionally check role membership server-side.
Minimal logging
We log the metadata we need to debug delivery (recipient, subject, status, SMTP response) and security events. We do not log message bodies or attachment contents.
TLS everywhere
All dashboard traffic is forced over TLS 1.2 or newer. Outbound SMTP uses STARTTLS or implicit SSL according to the encryption mode you choose on each account.
Edge-deployed runtime
Server functions run on a globally distributed edge runtime. There are no long-lived servers for an attacker to compromise; instances are ephemeral and rebuilt on every deploy.
Strict outbound surface
The worker that sends your email reaches the host, port and credentials you configured — and nothing else. There is no shared relay or shared IP pool.
Role separation
Admin actions (suspending users, viewing global tables) require a database role and are recorded in an audit log distinct from product activity.
Backups & recovery
Backups run automatically, are encrypted, and are retained on a rolling window. We test restore paths regularly.
Dependency hygiene
Production dependencies are tracked, security advisories are reviewed, and we patch on a rolling cadence. The codebase is built with strict TypeScript to catch entire classes of bugs at compile time.
Vulnerability scanning
Every meaningful change is reviewed against an automated security checklist before deploy. We run periodic database linter passes for misconfigured policies and exposed tables.
Responsible disclosure
Researchers can report findings privately to company@rapidhostbd.com. We acknowledge within 48 hours, will not pursue good-faith research, and credit reporters on request.
Shared responsibility
Securing email delivery is a partnership. The table below describes what we operate and what stays with you.
| Area | RAPID SMTP | You |
|---|---|---|
| Encryption of credentials at rest | AES encryption, scoped decryption | Rotate the SMTP password periodically |
| Authentication | Password hashing, session management | Use a strong password, enable 2FA when available |
| Sender reputation | Honest delivery logs, unsubscribe handling | SPF/DKIM/DMARC on your domain, send only to opted-in contacts |
| Workspace access | Row-level isolation across all tables | Invite only people you trust, revoke promptly |
| Incident response | Triage, fix, notify within 72 hours where required | Report suspected abuse from your account immediately |
Data location & subprocessors
The dashboard runs on a global edge platform and persists data in a managed database. Email is delivered through the SMTP server you configure — we are not part of the relay path. A current list of subprocessors is available on request to support@rapidhostbd.com.
Reporting a vulnerability
If you believe you have found a security issue, please email company@rapidhostbd.com with:
- A description of the issue and the impact you observed.
- The URL or endpoint affected and the steps to reproduce.
- Any proof-of-concept payload, ideally limited to a test account you created.
We commit to acknowledging your report within 48 hours, keeping you informed of progress, and not pursuing legal action against good-faith research that does not access other customers' data, degrade service, or exfiltrate data beyond what is needed to prove the issue.