Trust

Security

Last updated: July 2026

PostTo is a secure form backend: every submission travels over TLS, sensitive content is encrypted at rest, and server-to-server integrations can be authenticated with a signed request rather than a bare token. This page summarises the security model in one place. For the legal side, see our Privacy Policy and Data Processing Agreement.

1. Authenticating submissions

Every endpoint has a unique submission token in its URL. That's sufficient for browser-facing forms, where the token is necessarily public in your page source anyway — the real anti-abuse controls (rate limiting, honeypot, spam filtering) do the work there.

For server-to-server integrations, endpoints can require signed mode: requests are authenticated with HMAC-SHA256(secret, "<unix_ts>.<raw_body>"), so the signature covers both the timestamp and the exact request body, not just a static token. We reject requests outside a configurable replay window (60s / 5min / 15min) and compare signatures using a constant-time comparison to avoid timing attacks. Signed mode requires the secret to be held server-side — never use it from a browser form, since the secret would be exposed in your page source.

Outbound webhooks are signed the same way: every delivery carries a t=<ts>,v1=<hmac> signature header using your webhook's own secret, so your receiving endpoint can verify a payload genuinely came from PostTo. Verification examples are provided for Node.js, PHP, Laravel, and Python in the webhooks documentation.

2. Encryption at rest

Submission content — fields, subject, message, and sender name — is encrypted at rest using AES-256, on every plan including Free. Endpoint signing secrets and webhook secrets are encrypted the same way and, unlike a password, can only be rotated, never retrieved — we don't store them in a form we could read back even if we wanted to.

3. Secret rotation & audit trail

You can rotate an endpoint's signing secret at any time from the dashboard; the new value is shown once and the old one stops working immediately. Security-sensitive actions on an endpoint — secret rotation, destination changes, pausing, deletion — are recorded in an audit trail visible from the endpoint's dashboard.

4. Account security

Dashboard accounts support two-factor authentication (TOTP with recovery codes) and passkeys (WebAuthn), in addition to standard password authentication.

5. Spam filtering & abuse prevention

Baseline spam filtering — a honeypot field and heuristic scoring — runs on every submission on every plan and is entirely first-party; no submission content leaves our infrastructure for it. Optional AI-assisted classification is off by default, opt-in per endpoint, and only invoked for borderline cases; when enabled, only the submission content needed for classification is sent to Anthropic (our AI sub-processor, covered by our DPA), and a classifier failure never blocks delivery. Rate limiting protects both individual endpoints and the platform from abuse.

6. Data retention

Submission bodies are automatically purged after the retention period set by your plan — see the Privacy Policy for the current per-plan periods — and can be purged manually at any time from the dashboard for data-subject erasure requests.

7. Infrastructure

PostTo is hosted in Europe. All traffic to and from the API runs over TLS. Email delivery goes through Lettermint (with Postmark as a backup provider) via structured HTTP APIs rather than raw SMTP, which avoids an entire class of header-injection issues; we still validate sender addresses and strip control characters from subject lines as a second layer.

8. Reporting a vulnerability

If you believe you've found a security issue in PostTo, please report it to [email protected]. Include enough detail to reproduce the issue (endpoint/URL, request, expected vs. actual behaviour). We aim to acknowledge reports within 2 business days and to keep you updated as we investigate and fix. Please report privately and give us a reasonable window to fix an issue before any public disclosure — we won't pursue legal action against good-faith security research conducted under this policy.

Our security.txt file at /.well-known/security.txt carries the same contact.