Migrating off MailChannels: options for African developers

For years, the easiest way to send email from a Cloudflare Worker was MailChannels, mostly because it was free from the edge. That free Workers tier has been retired. If your app sends through MailChannels from a Worker, you are now looking for a new transactional sender whether you planned to or not. This is a guide to choosing one and switching cleanly.

What you actually need in a replacement

Strip it back to the requirements that matter for transactional mail:

A way to send from your existing code, whether that is a Cloudflare Worker calling an API over fetch, or a backend speaking SMTP. Reliable deliverability with proper domain authentication, suppression handling, and reputation management, so your password resets and receipts reach the inbox. Delivery webhooks so your app knows when mail bounces. And a price you can predict, which for an African team means thinking about the billing currency, not just the sticker.

The options

Amazon SES is the cheapest per email, but it is raw infrastructure. You build warm-up, suppression, reputation isolation, and your own dashboard on top of it, and you pay AWS in dollars. Right for teams with the engineering capacity to operate it.

Resend and SendGrid are solid API-first providers with good docs. Both bill in US dollars from US infrastructure, which carries the FX and virtual-card overhead we break down in what dollar-billed email really costs.

SendByte is the direct replacement we built for this case: a REST API and SMTP relay you can call from a Worker or any backend, deliverability tuned for African inboxes, hosting in af-south-1, and pricing fixed in Naira with a real free tier of 3,000 emails a month. The full side-by-side, including where MailChannels’ legacy integration was genuinely convenient, is on the MailChannels alternative page.

Sending from a Cloudflare Worker after MailChannels

The edge logic does not change. You only change where the send request goes. From a Worker, you call the provider’s API over fetch:

export default {
  async fetch(request, env) {
    const res = await fetch('https://api.sendbyte.africa/v1/emails', {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${env.SENDBYTE_API_KEY}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        from: 'noreply@yourcompany.com',
        to: 'user@example.com',
        subject: 'Your one-time passcode',
        text: 'Your code is 481920. It expires in 10 minutes.',
      }),
    });
    return new Response(res.ok ? 'sent' : 'failed', { status: res.status });
  },
};

Store the API key as a Worker secret, never in code. Check the docs for the current endpoint, SDKs, and the exact payload.

Migrating without dropping a message

The risk in any email migration is a gap in delivery during the cutover. Avoid it with a staged switch.

First, authenticate your domain on the new provider: add the SPF, DKIM, and DMARC records, and verify them. The key move is merging your SPF rather than replacing it, so both the old and new senders are authorised at once and you can dual-send. The SPF, DKIM, and DMARC guide covers exactly how.

Second, send a slice of real traffic through the new provider and watch delivery, bounces, and inbox placement for a few days. Run your domain through the deliverability audit to confirm everything authenticates.

Third, move the rest of your traffic over once delivery looks healthy, then remove the old sender from your SPF.

The migration tool generates the exact DNS records for your domain and a step-by-step plan, so you are not assembling this by hand.

The bottom line

The free Workers tier going away is annoying, but it is also a chance to move to something built for where you actually send from. Pick a replacement that authenticates properly, isolates transactional reputation, and bills in a currency you can budget. For African senders, that is the whole reason SendByte exists. See how it compares to every option before you commit.