Security at testmail.app
Last updated:
We take the privacy, security, and availability of customer data seriously. We use layered, industry-standard security measures across infrastructure, encryption, access controls, monitoring, vulnerability management, backups, and incident response to protect customer data and the systems that receive, process, and store test emails.
Hosting and data location
Our application infrastructure and related customer data are hosted on Amazon Web Services (AWS). By default, primary systems are hosted in the N. Virginia region (us-east-1), and encrypted backups are stored separately in the Ohio region (us-east-2).
Our applications and data stores operate within AWS network controls, including Virtual Private Clouds (VPCs), that segment production infrastructure and restrict access to the systems, services, and ports that require it. Public traffic is routed through controlled application endpoints, and internal systems are not directly exposed to the public internet unless required for their function.
We operate our own email receiving infrastructure so we maintain direct control over the systems used to receive and process test emails.
Encryption
HTTPS/TLS is enforced for web traffic, with TLS 1.2 as the minimum supported version and TLS 1.3 used where supported. AWS EBS volumes use encryption at rest with keys managed through AWS Key Management Service (AWS KMS). Supported AWS compute instances also benefit from AWS infrastructure-level encryption between instances, in addition to application-level transport protections. Backups are encrypted and stored separately from primary systems.
Network and application protection
We use industry-standard network and application protections, including distributed denial-of-service (DDoS) protection and a Web Application Firewall (WAF) to help identify and block common malicious request patterns. Production infrastructure is segmented using AWS network controls so access is limited to the systems and services that require it.
Authentication and access controls
User logins are passwordless. Access to email data through testmail.app APIs requires an API key, and API keys can be authorized for specific namespaces. Customers should treat API keys as secrets because a valid key may allow access to email data in the namespaces it is authorized to use.
Access to production systems and customer data is restricted to authorized team members who need it for legitimate operational purposes, such as maintaining the service, providing support, or investigating reliability and security issues. We limit access to the systems and data necessary for those responsibilities.
Monitoring and vulnerability management
We continuously monitor our systems for operational and security issues. We use a modern Application Performance Monitoring (APM) system for real-time visibility into application requests and server activity, helping our team investigate unusual behavior and respond quickly when needed. We also scan application containers for known vulnerabilities before deployment, and security patches and dependency updates are reviewed as part of our normal engineering and deployment process.
Backups and resilience
Critical service data is backed up and encrypted. Backups are stored in a separate AWS region from our primary environment to reduce the risk that a single regional event affects both production systems and backups.
Our APIs are distributed across multiple data centers and actively monitored. Customers can view current service availability and incident history on our public status page.
Email retention and data minimization
testmail.app is designed for email testing, not long-term email storage. Test emails are automatically deleted after the retention period configured for the account. The default retention period is currently 3 days on the Essential plan and 30 days on Pro and Enterprise plans. Accounts with custom retention settings may have a different window.
If our systems are breached, the short retention period limits any potential data exposure to the last 3 or 30 days of test emails. We recommend using test or synthetic data whenever possible and avoiding production secrets, live credentials, or sensitive personal data in test emails unless they are genuinely required for the test scenario.
Subprocessors and supplier security
We do not outsource data handling beyond the subprocessors disclosed in our Privacy Policy.
Our current subprocessors maintain recognized security certifications and/or provide independent assurance reports, such as ISO certifications or SOC 2 reports. We review suppliers based on their security practices, certifications, assurance reports, and data-handling policies, and limit supplier access to the data and systems required to provide their service.
Incident response and customer notification
We investigate suspected security incidents promptly. If we confirm an incident that materially affects customer data, we notify affected customers without undue delay and in accordance with applicable legal and contractual requirements.
Reporting a security vulnerability
We welcome responsible reports from customers and security researchers who believe they have discovered a vulnerability in testmail.app.
Scope
This disclosure policy applies to public-facing systems and services owned and operated by testmail.app. Testing of third-party services, customer-owned systems, or unrelated infrastructure is not authorized. If you are unsure whether a system is in scope, contact us before testing.
Good-faith testing rules
Use accounts and data that you own or have explicit permission to use. Test only to the extent reasonably necessary to confirm that a vulnerability exists and understand its impact.
Do not access, copy, download, modify, or delete data belonging to other users. If you unexpectedly encounter customer data or other sensitive information, stop testing, do not retain or share the data, and notify us immediately.
Do not establish persistence, move laterally to other systems, introduce malware, or exploit a vulnerability beyond what is necessary to demonstrate it. Do not conduct denial-of-service testing, high-volume automated testing, brute-force or credential-stuffing attacks, social engineering, phishing, spam, or physical security testing. Do not intentionally degrade availability or performance for testmail.app or its customers.
Safe harbor
If you conduct security research in good faith and comply with this policy, we will consider your testing authorized and will not initiate legal action against you for that research. If a third party initiates legal action against you for activities that complied with this policy, we will make it known, where appropriate, that your research was conducted in accordance with our policy. This safe harbor does not apply to activity that violates this policy or applicable law.
How to report
Please report potential security issues privately to [email protected]. A useful report should include a clear description of the issue and potential impact, the affected page, endpoint, feature, or service, step-by-step reproduction instructions, and a proof of concept or screenshots when they materially help demonstrate the issue.
Coordinated disclosure
Please keep vulnerability details confidential until we have had a reasonable opportunity to investigate and remediate the issue. We will work with researchers in good faith to coordinate any public disclosure after remediation.