Resend remains the primary email path in ZShip

Resend is still the default recommendation

The Email Service work is meant to give ZShip operators more routing options, not to replace the production path that already works for most teams. Resend remains the recommended primary provider for transactional email.

That means existing Resend keys, app bindings, and support email flows should continue to run first. Site owners do not need to migrate away from Resend just because Cloudflare Email Service support exists.

What the new Email Service adds

The new email service adds an optional provider layer for teams that want Cloudflare-native fallback delivery or app-specific routing. It can store provider metadata, route a project to a specific provider order, write delivery logs, and test Cloudflare Email Sending after the sender domain and Worker binding are ready.

In Admin, Resend is now the first provider choice. Cloudflare Email Service is available when a project intentionally needs it.

How fallback should be used

A practical production setup should treat Resend as the first hop. Cloudflare Email Service can be placed after Resend in a failover route, or enabled only for a specific app that has completed Cloudflare sender-domain onboarding.

This avoids making a newer Cloudflare Email setup the default for every project before the domain, EMAIL binding, deployed Worker, and D1 configuration have all been verified.

What site owners should check

For normal email delivery issues, check Resend first: API key, verified sender domain, app binding, quota, and node2 email logs.

Only check the Cloudflare Email Service guide when the optional fallback is enabled. In that case, confirm the sender domain is onboarded, the Worker has the EMAIL binding, the production zship-email D1 database is real, and the test is running against a deployed Worker rather than local wrangler simulation.