Security

Email holds the most sensitive material a company has. This page sets out exactly how we protect it, and what we do not yet have.

Version 1.0 · Effective 25 August 2026

Encryption

Layer	Implementation
In transit	TLS 1.2 or above, HSTS with a one-year max-age
At rest	AES-256-GCM authenticated encryption
Passwords	Argon2id, 64 MB memory cost
Tokens	SHA-256 hashes; plaintext never stored

Message bodies, subjects, participant addresses, attachment names and mailbox credentials are all encrypted. We use GCM rather than CBC because GCM authenticates as well as encrypts: if a single byte of ciphertext is altered, decryption fails outright instead of silently producing wrong data.

Each ciphertext is bound to the table and column it belongs to. Moving encrypted data from one field to another therefore breaks decryption, which closes off an entire class of database-level tampering.

Mail data uses a key separate from the application key. Rotating an application key is routine; if both shared one key, every rotation would render historical mail permanently unreadable.

Searching encrypted data

Because each encryption uses a random initialisation vector, the same value produces different ciphertext every time, so ordinary equality queries cannot work. We store a keyed hash alongside the encrypted value: deterministic enough for exact matching, one-way enough to be useless in a database leak. The key used for it is held outside the database.

Tenant isolation

The most expensive bug in multi-tenant software is one organisation seeing another's data. We do not rely on developers remembering to filter queries. Isolation is enforced at the model layer, so every query is automatically scoped to the correct organisation. Bypassing it requires deliberate, explicit code that is immediately visible in review.

Access control

• Default deny: a new user sees nothing until permissions are granted.
• Grants attach at company, brand, category or individual mailbox level.
• Each grant carries its own abilities: view, reply, send, delete, assign, export, manage.
• Deny always overrides allow, so exceptions are guaranteed to hold.
• Grants can carry an expiry date, which suits contractors and temporary staff.

Authentication

• Two-factor authentication by authenticator app, email code, SMS code or backup codes.
• Mandatory two-factor for administrator roles.
• Brute-force protection counted separately per account and per IP address, so an attacker cannot lock out a legitimate user on purpose.
• Progressive delays that slow automated attacks without revealing that they have been detected.
• Re-authentication required before sensitive actions such as billing or permission changes.
• Session limits, idle timeout and per-device sign-out.
• Optional network restrictions using CIDR ranges.

Tamper-evident audit log

Every audit entry includes a hash of the entry before it, forming a chain. If any record is altered or removed, the chain breaks at that point and our verification command reports exactly where.

The practical consequence is that we cannot alter your audit trail either. Credentials, tokens and secrets are redacted before they are written, because audit logs are read by more people than any other data store.

Protecting against hostile email

Anyone in the world can send mail to your inbox, which makes rendering it the largest attack surface in the product. Three independent layers address it:

1. An allow-list HTML sanitiser. Anything not explicitly permitted is removed, so new attack techniques fail by default rather than needing a new rule.
2. A sandboxed rendering frame in which scripts cannot execute at all.
3. A nonce-based content security policy with no inline script permitted anywhere.

Remote images are blocked by default, because tracking pixels reveal when a message was opened and from which IP address.

Attachments

• Files are never stored in a web-accessible directory.
• The original filename is never used on disk, which eliminates path traversal and encoding tricks.
• Extension and actual file content are both verified, so a renamed executable is caught.
• Downloads are served through expiring signed links with forced-download headers.
• Archives are inspected internally, including protection against compression bombs.
• Optional on-premise antivirus scanning. If the scanner is unavailable, files are held rather than passed through.

Payment security

Card details never reach our servers. The entire payment occurs on the gateway's own secure page, which keeps us within the narrowest PCI DSS scope.

Every payment is confirmed by a server-to-server API call. A "success" flag arriving in the browser is never trusted on its own, since it can be forged. Amounts are re-verified against our own records at every stage.

Minimal external dependencies

The product makes outbound connections to exactly four external services: the four payment gateways. This is enforced in code by an allow-list, not merely stated as policy.

Deliberately not used	Reason
reCAPTCHA	Sends every visitor's IP and behaviour to a third party
Password breach lookup APIs	Would require transmitting password hashes externally
Cloud antivirus	Would require uploading customer attachments
Third-party analytics or error tracking	Stack traces and payloads can contain customer content
CDN-hosted fonts or scripts	A well-known supply-chain attack route

Compliance

• DPDP Act 2023 — data localisation, consent records, erasure workflow, breach notification
• GDPR Article 32 — technical and organisational measures, with a signable Data Processing Addendum
• IT (Reasonable Security Practices) Rules, 2011 — documented security programme
• PCI DSS SAQ-A — cardholder data never enters our environment

What we do not yet have

Trust is built by disclosure, so here is the honest list.

• Independent penetration test. The controls described above are implemented, but no external test has yet been commissioned.
• SOC 2 report. Controls are designed with SOC 2 in mind, but a formal audit requires an observation period we have not yet completed.
• Hardware security module. Encryption keys are held securely on the server, not in dedicated key management hardware.
• Public bug bounty. Not yet launched; responsible disclosure is welcomed in the meantime.

If any of these is a procurement requirement for you, get in touch and we will share our current position and timeline in writing.

Reporting a vulnerability

Please do not disclose publicly. Email info@ajontec.com.

• We acknowledge within 48 hours.
• We target a fix within 90 days, sooner for critical issues.
• We will not pursue legal action against researchers who follow our responsible disclosure guidelines.
• We are happy to credit you publicly once a fix has shipped.

Contact

Dream Blend Solutions Private Limited
Samastipur
Samastipur, Bihar 848101
India

Email: info@dreambspl.com
Phone: +91 7280008555