# 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](https://www.mailblastr.com/docs/domains/managing). |
| Data backup | Production data is backed up with a point-in-time approach and retained so the platform can recover from operational failures. |

> **Note:** Your API requests must use HTTPS. A request over plain HTTP is refused before any credentials are read.

## 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](https://www.mailblastr.com/docs/api-keys/overview).
- A leaked or unused key should be revoked immediately via [DELETE /api-keys/:id](https://www.mailblastr.com/docs/api/api-keys-delete) — 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](https://www.mailblastr.com/docs/domains/managing) 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](https://www.mailblastr.com/docs/webhooks/overview) and the verification recipe under [Examples](https://www.mailblastr.com/docs/resources/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](https://www.mailblastr.com/docs/emails/suppressions) skips addresses that bounced, complained, or unsubscribed.
- Permanent (hard) bounces and spam complaints **auto-suppress** the recipient — see [Email bounces](https://www.mailblastr.com/docs/emails/bounces).
- Campaigns inject an RFC 8058 one-click unsubscribe automatically — see [Unsubscribe links](https://www.mailblastr.com/docs/emails/unsubscribe).
- Attachment `path` URLs 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.

> **Warning:** Never include real recipient data, live API keys, or other people's personal information in a vulnerability report. Redact or use test data.