Security
An overview of how MailBlastr protects your data and your account — encryption, access controls, key management, and responsible disclosure.
Email is sensitive: recipient lists, message bodies, and API keys all flow through MailBlastr. This page summarizes the controls in place to keep that data safe, and the principles they're built on.
Foundational principles
MailBlastr's security controls follow a small set of guiding principles, applied consistently across the platform:
- Least privilege — access is limited to those with a legitimate need. This applies to staff access and to your own API keys, which can be scoped to sending-only.
- Defense in depth — controls are layered, so a single failure never exposes data on its own.
- Consistency — the same controls apply across every part of the system rather than only the obvious entry points.
- Continuous improvement — controls are revisited and tightened over time, reducing friction without weakening protection.
Data protection
| Area | Control |
|---|---|
| Data at rest | All datastores are encrypted at rest. Sensitive fields — including API key material — receive additional row-level encryption. |
| Data in transit | TLS 1.2 or higher is required for every connection to the API. Outbound mail is delivered over TLS to receiving servers wherever they support it; you can require it per-domain via opportunistic vs. enforced TLS. |
| Data backup | Production data is backed up with a point-in-time approach and retained so the platform can recover from operational failures. |
Product security
Penetration testing
MailBlastr engages third-party firms to conduct penetration testing on a recurring basis. The product and its cloud infrastructure are in scope for these assessments, and testers are given the access they need to maximize coverage.
Vulnerability scanning
Multiple techniques — code-level scanning, dependency scanning, and security reviews — are used to find and remediate vulnerabilities. Findings are prioritized by severity and risk, and remediated against a defined timeline:
| Severity | Remediation target |
|---|---|
| Critical | 15 days |
| High | 30 days |
| Medium | 90 days |
| Low | 180 days |
| Informational | As needed |
Operational & enterprise security
- Endpoint protection — company devices run anti-malware protection with monitored security alerts, and a managed-device configuration enforces disk encryption, screen locks, and timely software updates.
- Identity & access management — staff access is granted by role and deprovisioned when it is no longer needed; multi-factor authentication is required to reach internal applications.
- Security education — personnel receive security training on onboarding and on an ongoing basis, including briefings on issues that need attention.
API keys
API keys are the primary credential for the platform. MailBlastr is built to keep them safe and to limit the blast radius if one leaks:
- Keys are shown once at creation. MailBlastr stores only a hash, so a key can never be retrieved again — rotate by creating a new one and deleting the old.
- Keys can be scoped to full access or sending-only, so a key embedded in an app that only sends mail cannot read your domains, contacts, or logs. See API keys.
- A leaked or unused key should be revoked immediately via DELETE /api-keys/:id — revocation takes effect right away.
- Treat keys like passwords: keep them in a secret manager or environment variable, never in source control, client-side code, or shell history.
Sending authentication
Strong sender authentication protects both your recipients and your domain reputation. MailBlastr requires you to verify a domain before sending from it, which means publishing DNS records for:
- SPF — authorizes MailBlastr's infrastructure to send on your domain's behalf.
- DKIM — cryptographically signs each message so receivers can confirm it wasn't altered in transit and genuinely came from you.
- DMARC (recommended) — tells receivers how to treat mail that fails SPF/DKIM, and gives you reporting.
See Domains for the exact records and the verification flow.
Webhook security
Every webhook delivery is signed so your endpoint can prove a payload genuinely came from MailBlastr and wasn't tampered with. Verify the signature over the raw request body before acting on any event, and reject anything that doesn't match. See Webhooks and the verification recipe under Examples.
Recipient protection
Several controls exist specifically to protect recipients and your sender reputation, and they are enforced on every send path:
- An account-wide suppression list skips addresses that bounced, complained, or unsubscribed.
- Permanent (hard) bounces and spam complaints auto-suppress the recipient — see Email bounces.
- Campaigns inject an RFC 8058 one-click unsubscribe automatically — see Unsubscribe links.
- Attachment
pathURLs are fetched through an SSRF-guarded client, and custom header values are sanitized to prevent header injection.
Reporting a vulnerability
If you discover a security issue, please report it responsibly rather than disclosing it publicly. Email the details — steps to reproduce, affected endpoints, and any proof of concept — to security@mailblastr.com, and allow time for a fix before going public. We do not pursue legal action against good-faith research that respects user privacy and avoids data destruction.