Email you can prove.
Send your newsletter, your app's emails, and your campaigns from one place — on email infrastructure we run ourselves. Delivery you can verify, and pricing that never bills you for the size of your audience.
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" }Grow with it
Write and send a newsletter people actually receive. Public archive, signup forms, paid subscriptions — and we never charge you for the size of your list.
Grow your list→Build with it
One clean email API with copy-paste code for every stack, plus drop-in SendGrid, Mailgun, Postmark, and EmailJS compatibility. Test everything safely before one real email goes out.
Start building→Trust it — verifiably
Encryption keys only you hold, proof of delivery you can check yourself, and a security page with no fine print. Claims you can verify, not badges.
Read the security story→What will you send?
A newsletter people actually receive. Write it here, send it here, and grow it here: hosted signup forms, a public web archive readers and search engines can find, RSS, and paid subscriptions when you're ready. The creator tour →
Your product's emails. Welcome messages, receipts, password resets — the email that has to arrive. Your developers get a five-minute setup and a test mode that can't send anything real by accident. The developer tour →
Campaigns and automations. Announcements to exactly the right slice of your audience, welcome series designed on a visual canvas, and A/B tests with statistics that don't fool you. See what's included →
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. If that read as jargon, here's what it means: no email gets lost, none gets sent twice, and nobody who unsubscribed ever hears from you again — and we spell out precisely what each of those promises means, and its assumptions. The rest of this page works the same way — plain promise first, proof underneath.
We run our own pipes
Here's the email industry's open secret: beehiiv, Buttondown, and Substack each rent their delivery from bigger senders — beehiiv's status page lists SendGrid components, Buttondown's subprocessor list names Mailgun and Postmark, and Substack's own public pages name Mailgun (each verified July 2026) — see our survey list and method.
Email Fast is the other kind of company: Email Fast runs its own mail transfer agent, warmup engine, reputation breaker, and per-tenant fair queue — we run these ourselves, with no upstream ESP reselling us your delivery. When you need an answer about deliverability, there is no upstream provider to blame — the whole path, from the send button to the receiving mail server's response, is ours to show you.
- One admission gate — spam checks, unsubscribe protection, and rate limits in a single checkpoint no send can skip
- Durable queue — accepted means it cannot be lost
- Our own mail servers — authenticated, warmed up, and reputation-guarded
- 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 — how we measure that, and its error bounds.
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: erasure by crypto-shred: destroying a key renders the data it protected unreadable — our approach to honoring GDPR erasure, documented in the DPA — 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 — attachment sends are the one exception, refused with a clear error in your provider's own format rather than silently dropped.
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 arrives at general availability — one of the roadmap items on our what's-arriving-at-GA list. 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 and what we don't yet claim — in the open, crawlable by anyone. Or anyone's AI.
Questions, answered plainly
I'm not technical — is Email Fast for me?
Yes. Creators and businesses run everything here without touching code: write and send your newsletter, put a hosted signup form on your site, get a public archive, set up a welcome series on a visual canvas. The developer tools exist for when you have a team that wants them — they're never a prerequisite.
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.
How is Email Fast different from Mailchimp, Substack, or beehiiv?
Three ways that matter. First, price: contacts and subscribers are never billed — we price sending, not the size of your audience — a million subscribers costs the same as a hundred. Second, revenue: we take no percentage of your paid-subscription income (you pay only card-processing fees). Third, the part nobody talks about — beehiiv, Buttondown, and Substack each rent their delivery from bigger senders — beehiiv's status page lists SendGrid components, Buttondown's subprocessor list names Mailgun and Postmark, and Substack's own public pages name Mailgun (each verified July 2026). We run our own delivery. The comparison pages go deeper, and they're honest about where those tools win.
I'm using EmailJS today — why switch?
Because it's a one-line change that upgrades you to a full platform: 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. Same code, plus the things a frontend-only service can't give you — automatic bounce and unsubscribe handling, delivery tracking, and a real deliverability engine underneath. See the migration guide.
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 — attachment sends are the one exception, refused with a clear error in your provider's own format rather than silently dropped. The migration guides show the exact two-line diff for each provider's SDK.
Can I bring my existing email list?
Yes — bring your contacts and, just as important, your unsubscribe list, so your sender reputation is protected from day one. During early access we help you migrate everything hands-on; one-click importers from the major providers arrive with general availability.
What makes Email Fast better than other email services?
We'd rather show you than tell you — our claims are checkable. Deliveries can mint signed receipts you can verify without trusting us. Your open rates aren't inflated: open tracking that refuses to lie: privacy-proxy prefetch “opens” are detected and not counted as human reads. On privacy, as of July 2026, none of the twelve competitor platforms we surveyed offers customer-held encryption keys for message content — the closest, a healthcare email provider, documents that its master keys live in its own cloud KMS — see our survey list and method. And every factual claim on this site is checked against the actual codebase when the site is built, so the marketing can't outrun the product.
Can Email Fast read my email?
Two questions live here. On the human side, by default, Email Fast operators can read message content — we say so plainly instead of implying otherwise; BYOK with at-rest message encryption is the exception, and the vendor-access transparency log makes “we didn't look” checkable rather than promised; for organizations that turn on BYOK at-rest encryption 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. On the abuse side, content is machine-screened in flight — every outbound message is machine-screened for abuse — spam, scams, phishing, brand impersonation, and malware links — at admission and again at send, on every self-serve plan; the screen is automated and runs before delivery, never a person reading your mail — with one exception: one lane switches that abuse screening off entirely — the sales-vetted Enterprise content-privacy tier — and it is the only way outbound content goes un-scanned; it is granted solely by an operator through the audited admin plane after vetting, never self-serve, and every grant is logged. At-rest encryption protects stored content; it does not, by itself, remove the in-flight abuse screen.
Do you have SOC 2?
No — and we won't imply otherwise with borrowed badges. What we have instead: an open, crawlable security page that lists exactly what is built — encryption at rest, database-level tenant isolation, passkeys and two-factor sign-in — and says plainly what we don't yet claim. When a third-party audit happens, it will be announced there first.
How is deliverability handled?
Email Fast runs its own mail transfer agent, warmup engine, reputation breaker, and per-tenant fair queue — we run these ourselves, with no upstream ESP reselling us your delivery. 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.