Email you can prove.
A complete email platform — transactional API, newsletters, and automation — on infrastructure we own, not resell. The proof is built in: signed delivery receipts, tamper-evident audit chains, and opt-in encryption under keys only you hold.
curl https://api.emailfast.dev/v1/emails \
-H "Authorization: Bearer ef_sandbox_..." \
-d '{
"to": "ada@example.com",
"subject": "Welcome!",
"html": "<h1>Hi {{name}}</h1>",
"data": { "name": "Ada" },
"idempotency_key": "signup-42"
}'
# → 202 { "id": "…", "status": "queued" }Build with it
One clean REST API, SMTP, a browser SDK, and drop-in SendGrid/Mailgun/Postmark compatibility. A sandbox that fakes nothing. Docs your coding agent can read.
Start building →Grow with it
Newsletters with a public archive, RSS, and paid subscriptions — on pipes we own, with contacts that are never billed. Own your audience for real.
Grow your list →Trust it — verifiably
Customer-held keys with an instant revoke kill-switch, fail-closed DLP, and cryptographic proof of delivery. Claims you can check, not badges.
Read the security story →Most email platforms ask for trust. We built receipts.
Every claim on this page is checkable — every send — REST, SMTP, browser SDK, compatibility endpoints, broadcasts, automations — passes through one admission gate: idempotency, suppression, quota, and content policy in a single checkpoint no ingress can skip, and a 202 from the API means the send is committed to a durable, partitioned outbox before we answer — a crash can't lose it, and a retry with the same idempotency key can't double-send.
We own the pipes
every newsletter platform we surveyed rents its delivery: beehiiv's status page lists SendGrid components; Buttondown's subprocessor list names Mailgun and Postmark; Substack sends through Mailgun (verified on their own public pages, July 2026).
Email Fast is different by construction: Email Fast runs its own mail transfer agent, warmup engine, reputation breaker, and per-tenant fair queue — the pipes are ours, not resold. When you need an answer about deliverability, there is no upstream provider to blame — the whole path, from your API call to the receiving mail server's response, is ours to show you.
- One admission gate — idempotency, suppression, quota, and content policy in a single checkpoint
- Durable partitioned outbox — accepted means it cannot be lost
- Our own MTA — DKIM-signed, warmed, reputation-guarded, fairly queued
- The receipt — delivery events, and on request a signed certificate
Receipts, not vibes
delivered messages can mint an Ed25519-signed delivery certificate — receiving mail server, TLS details, the server's SMTP response, and timestamps, with the recipient stored only as a keyed hash — chained into a tamper-evident ledger and verifiable without trusting us.
{
"recipient_hash": "hmac:6f1c…be02",
"receiving_mx": "gmail-smtp-in.l.google.com",
"tls": "TLSv1.3 / TLS_AES_256_GCM_SHA384",
"smtp_response": "250 2.0.0 OK 1720979183 x12-20020a17",
"sent_at": "2026-07-17T18:04:11Z",
"delivered_at": "2026-07-17T18:04:12Z",
"signature": "ed25519:9b3f…c771"
}Verify it with our published public key — or don't trust us and verify it anyway. That's the point.
Analytics tell the truth too: open tracking that refuses to lie: privacy-proxy prefetch “opens” are detected and not counted as human reads.
Keys you hold
organizations can bring their own encryption keys — enroll, rotate, suspend, or revoke — and revocation fails closed: new sends are rejected and stored secrets become unreadable, to us included.
For organizations that turn it on, it goes further: BYOK organizations can additionally enable at-rest message encryption: recipient, subject, and body stored as ciphertext under per-recipient keys wrapped by the customer's key — revoke the key and the stored content is unreadable everywhere, instantly.
encrypted sends give up click-tracking, send-time optimization, and per-recipient analytics — that is what “we can't read it” costs, and we say so.
Erasure is real, too: GDPR erasure by crypto-shred: destroying a key destroys the data it protected, without corrupting the tamper-evident audit ledger.
Switch without rewriting
SendGrid-, Mailgun-, and Postmark-compatible endpoints: point your existing SDK at a new base URL with a new key and keep your code.
From SendGrid
- const client = require("@sendgrid/mail");
- client.setApiKey(SENDGRID_API_KEY);
+ // same SDK, new base URL + key
+ client.setApiKey(EMAILFAST_API_KEY);
+ client.setDefaultRequest("baseUrl", "https://api.emailfast.dev");From Postmark
- const client = new postmark.ServerClient(POSTMARK_TOKEN);
+ const client = new postmark.ServerClient(EMAILFAST_KEY, {
+ requestHost: "api.emailfast.dev",
+ });From EmailJS
- import emailjs from "@emailjs/browser";
+ import emailjs from "@email-fast/browser";
emailjs.init({ publicKey }); // same call signaturesEvery migration path, in detail →
Built for how developers work now
SDKs for the browser (EmailJS-compatible), Node.js, Python, PHP, Go, and Ruby, plus a zero-dependency CLI and a published OpenAPI specification — and sandbox keys (ef_sandbox_…) that run the real pipeline dry: real validation, real rendering, real events, a hosted capture inbox — and no email leaves.
And because your coding agent is part of the team: every page on this site has a markdown mirror (append .md to any URL), llms.txt is first-class, and an MCP server is arming at launch. Point your agent here →
For the people with the list
Own your audience for real: newsletters with a hosted, search-indexable archive, RSS, paid subscriptions, and hosted signup forms — hosted signup forms with double opt-in through our own delivery path, so every subscriber carries verifiable proof of consent. Unsubscribes that actually work: one-click unsubscribe per RFC 8058, with the headers signed under DKIM so stripping them in transit breaks the signature.
And the part your budget will notice: contacts and subscribers are never billed — we price sending, not the size of your audience.
The security layer is the platform
an outbound data-loss-prevention gateway that fails closed — card numbers, government IDs, and secrets can be blocked, redacted, or held for a second person's sign-off before anything leaves. Single sign-on, SCIM provisioning, passkeys, and two-factor are built in — and the whole thing sits on 75/75 tenant tables under database-enforced row-level isolation, with a structural guard that fails the build if a new table ever lacks it.
No borrowed badges here: our security page tells you exactly what we've built, what we've verified and how — in the open, crawlable by anyone. Or anyone's AI.
Questions, answered plainly
Is there a free tier?
Yes, and it doesn't expire. It includes full platform features and an unlimited test sandbox; free-tier emails carry a small “Sent with Email Fast” footer that any paid plan removes. See pricing for the numbers.
Can I migrate from SendGrid, Mailgun, or Postmark without changing code?
Yes — SendGrid-, Mailgun-, and Postmark-compatible endpoints: point your existing SDK at a new base URL with a new key and keep your code. The migration guides show the exact two-line diff for each provider's SDK.
Can Email Fast read my email?
By default, message content lives in our database like any email platform's — protected, but readable by the operator. The difference: BYOK organizations can additionally enable at-rest message encryption: recipient, subject, and body stored as ciphertext under per-recipient keys wrapped by the customer's key — revoke the key and the stored content is unreadable everywhere, instantly. And a vendor-access transparency log: a tamper-evident chain that records operator access, so “we never looked” is checkable, not promised.
Do you have SOC 2?
No — and we won't imply otherwise with borrowed badges. What we have instead: a 19-stage adversarial security review, run to zero confirmed findings, 65 end-to-end verification suites and 351 unit tests, green at every commit, and an open, crawlable security page that states exactly what is and isn't true. When a third-party audit happens, it will be announced there first.
Can I send email from my frontend without a backend?
Yes — a browser SDK with EmailJS-compatible endpoints — the recipient always comes from the server-stored template, never from the request, so a public key in your frontend can't be abused to spam arbitrary addresses. If you're on EmailJS today, the browser SDK is a drop-in replacement.
How is deliverability handled?
Email Fast runs its own mail transfer agent, warmup engine, reputation breaker, and per-tenant fair queue — the pipes are ours, not resold. Warmup, reputation circuit-breakers, blocklist monitoring, bounce and complaint feedback loops, and per-message delivery inspection are built into the platform — read how deliverability works.