Last updated: 2026-05-25
01 — Approach
Our approach is to operate a small, well-understood stack — dedicated email infrastructure on hardened Linux systems — rather than a sprawling platform with attack surface we can't fully map. That choice is itself a security posture: the fewer moving parts there are, the more thoroughly each one can be defended, and the faster a real incident can be diagnosed and contained.
Security is treated as part of operations, not a separate function. The engineers running the infrastructure are the same people who harden it and respond when something goes wrong. There's no security theater in the form of dashboards that nobody reads — what we do is concrete and operational.
02 — Infrastructure
The mail layer runs on dedicated servers operated by us, in data centers selected for jurisdictional fit (EU, US, or LATAM, depending on the customer's residency choice). Network ingress is restricted to the ports and sources the service actually needs. Operating systems are kept on supported releases with security patches applied on a defined cadence and out-of-band for high-severity advisories.
Configuration is version-controlled and changes go through review. We don't make ad-hoc changes to production infrastructure outside the change-management process, except in incident response where the change itself is logged in detail.
03 — Access control
Administrative access to production is limited to engineers who require it for their role, authenticated with hardware-backed multi-factor authentication, and scoped to the systems and operations actually needed. Access is reviewed periodically and revoked promptly when no longer required.
Customer-facing access — API credentials, SMTP credentials, dashboard logins — is the customer's responsibility to manage; we provide the means to rotate and scope credentials and recommend that customers do so as a matter of routine.
04 — Encryption
Connections to our services use TLS 1.2 or higher. Outbound mail is delivered with opportunistic TLS to any receiving server that supports it, which today is the substantial majority of significant mail providers, and with required TLS for customer-defined critical routes. Stored data — logs, metadata, account information — is encrypted at rest using accepted algorithms and key-management practices.
Customer-managed encryption (BYOK, customer-held keys) is available for customers whose compliance posture requires it; raise it during scoping.
05 — Monitoring & logging
The infrastructure is monitored continuously for availability, throughput, error rates, and security signals. Logs are centralized, retained for the windows required by the service contract and applicable law, and protected against tampering. We alert on the things that matter — authentication anomalies, unexpected configuration changes, unusual traffic patterns — and we keep the alert volume low enough that real signals don't drown.
For customers, we provide visibility into their own sending — delivery events, bounce and complaint feedback, placement signals — through the dashboards and APIs detailed in the service agreement.
06 — Incident response
We maintain a documented incident response process covering detection, triage, containment, eradication, recovery, and post-incident review. Customer-affecting security incidents are communicated promptly to named technical and account contacts, with the information needed to act and a follow-up summary once the incident is closed.
For personal-data breaches, we follow the notification commitments in our Data Processing Agreement — informing affected customers without undue delay so they can meet their own regulatory clocks.
07 — Vendor & sub-processor management
The small set of vendors that touch customer data — data centers, billing, support tooling — are reviewed before engagement and reassessed periodically. We bind them to confidentiality and to data-protection terms substantively equivalent to those we offer customers. A current list is available to active customers and to prospects under appropriate confidentiality.
08 — Compliance posture
We architect for the most common compliance regimes our customers operate under — GDPR, UK GDPR, CCPA, LGPD, and others — through data-residency choices, contractual provisions in the DPA, and the technical controls described above. The specific posture available to a given customer depends on the architecture chosen during scoping.
On formal certifications: we'll be plain. Where we hold an active third-party certification or attestation, we say so explicitly, name the framework, and provide the report under appropriate NDA. Where we don't — yet — we describe the relevant controls honestly as architectural capability and operational practice, without dressing them up as certifications we haven't completed. Customers conducting security reviews can ask for the current state directly, and we'll answer plainly.
09 — Reporting a vulnerability
If you believe you've found a security issue in our infrastructure or website, please report it to security@emaildeliveryplatform.com. We acknowledge reports quickly, investigate seriously, and don't pursue good-faith researchers who report responsibly. Where appropriate, we coordinate public disclosure with the reporter.