Email Provider Plugins Ecosystem (SMTP, Resend, Postmark, etc.)

[Glazastyy]

Hello EmDash team!

I'm currently exploring the email architecture with the goal of building email provider plugins (SMTP via Worker Mailer, Resend, Postmark, SES, and others)

The current email pipeline looks solid:

• Clear stages: beforeSend → deliver (exclusive hook) → afterSend
• email:provide capability for registering transports
• email:send for consumption and email:intercept for middlewares
• Built-in dev provider (emdash-console-email) already working
• System emails (source: "system") properly isolated for security
• Exclusive hook resolver supports multiple providers with automatic selection

This shows the core is already well-prepared to support multiple email providers through plugins

Before moving forward with implementation and publishing, I'd like to align with the maintainers' vision:

1. API Stability: Do you plan any significant (breaking) changes to the email hooks (email:deliver, email:provide) or capabilities in the short/medium term?

2. Recommended Direction: Is having separate plugins for each email provider the right approach according to the project's direction?

3. Admin UX: What is the preferred pattern for a provider's settings page in the admin?

   • adminEntry (React component)
   • Block Kit (declarative)
   • Or a custom route?

4. Reusable Base Plugin: Would it make sense to create a reusable "email provider base" to reduce code duplication across providers (configuration, validation, error handling, etc.)?

5. Official vs Community Plugins: What’s the long-term policy for “official/recommended” providers? Is there interest in maintaining a curated list?

My initial suggestions:

• Keep each provider as a separate plugin, but follow common conventions for configuration, error handling, and logging
• Create a compatibility checklist (security, observability, dev/prod behavior, etc.)

If this direction sounds good to you, I can prepare a more concrete proposal. I’d probably start with a generic SMTP provider, as it covers most use cases

Thanks in advance for the great work

Looking forward to your feedback!

[maikunari]

Great discussion @RibasSu — worker-mailer is impressive work, building a real SMTP client on Cloudflare TCP Sockets is genuinely non-trivial.

I'm planning to build the Resend provider plugin alongside this, so flagging it to avoid duplication. Since Resend is HTTP-based rather than SMTP it won't overlap with your approach at all — just network:fetch to api.resend.com, no TCP sockets needed. I'm also building a forms plugin that consumes email:send, so I have an end-to-end use case to validate the provider pattern against.

Happy to coordinate on shared conventions so the SMTP and Resend plugins feel consistent to users.

[Glazastyy]

Excellent! I'm currently testing some ways to integrate this into EmDash (in a private repo) — it also involves Cloudflare Queues to avoid blocking EmDash's main flow — and I plan to open a PR shortly after. Would be great to know how you're approaching the integration on your end.

I also took a look at Cloudflare's new email sending feature, but it's still very early/beta so I'll leave that for a bit later.

[ascorbic]

Thanks for looking at this! To answer your questions:

1. I have no plans for major changes to the hooks, unless implementors like you find important failings or missing parts. In that case I would consider changing.
2. Yes, separate plugins would be best
3. Ideally use Block Kit in all cases, as this allows it to be sandboxed. React adminUI means it can only be installed via npm.
4. Possibly. If there's a common set of tools that you think would be useful then I might consider adding them to a shared helper lib.
5. I would like to keep most things as community plugins, but we would likely do things like "featured plugins". Right now we don't have much in the way of tooling for that though, but hopefully we can change that soon.

[Glazastyy]

Thanks, this is super helpful and lines up well with what I had in mind.

I’ve started with the SMTP provider plugin and wired it against the existing email:deliver / email:provide flow. I’m using @workermailer/smtp as the transport and keeping the package separate as discussed. PR #406

One implementation note from this first pass: SMTP on Cloudflare ends up needing some provider-specific configuration/validation around transport security (for example, STARTTLS vs implicit TLS), but so far the core email pipeline itself feels like a good fit, and I haven’t run into any hook-level blockers.

Thanks again. This gave me a clear path forward.

[marks-zyz]

Data point for this thread: we needed a production email provider on Cloudflare Workers and ended up writing an AWS SES one. It has been running on three client sites since 2026-09-06 (magic link, invites, form notifications).

Full source and the wiring are in #2933 — single file, aws4fetch for SigV4, no AWS SDK, secrets read from the Worker env at delivery time. MIT, take it or point at it.

One finding that belongs in this thread: hooks run outside the request context, so the env has to come from import("cloudflare:workers"), not Astro.locals.runtime.env. That is not obvious from the plugin docs and it is where a first attempt fails.

[minemeraj]

Another data point for the ecosystem picture here: there's already a published SMTP plugin on npm — emdash-smtp by @masonjames (repo masonjames/emdash-smtp, MIT, currently v0.3.4). I've been using it and it's been working nicely for me — I can see verification emails coming through on my Better Auth signup flow, so the email:deliver path is delivering end to end on Cloudflare Workers.

None of this to detract from the SMTP work in #406 or the SES provider in #2933 — really the opposite. Between that PR, this package, and the SES one, there are now a few solid transactional/SMTP efforts in flight, and it might help everyone to cross-link them from this thread so people evaluating options can find them in one place (and so contributors can coordinate rather than each rebuild the transport). The "email provider base" idea and a future featured-plugins list would both help here.

Also +1 on the env finding from #2933: hooks run outside the request context, so the transport reads secrets from import("cloudflare:workers") env rather than Astro.locals.runtime.env. I ran into the same thing — worth getting into the plugin docs.

[marks-zyz]

Cool, is there already a marketplace with all the developed plugins? I feel like it's about time to have one; I have the impression that I'm constantly recreating things that already exist...

[minemeraj]

TBH, I'm missing this, me myself created plugins that are already available somewhere, and in the age of AI we all are reinventing the wheel unfortunately. I have created a list here: https://github.com/theweekendprojects/awesome-emdash

I hope this will help. But feel free to create PR, thanks!