Skip to content

Transactional email

Beta

Send transactional email from your app

Send password resets, receipts, sign-in codes and notifications through the same Eza account that runs your app. Use a Resend-compatible sending API at https://email.eza.co.ke, or SMTP relay on port 587 or 465. Included with every hosting plan. Beta.

  • Resend-compatible sending API
  • SMTP relay
  • SPF, DKIM and DMARC
  • Beta
reset-password.ts
import { Resend } from 'resend' const email = new Resend(process.env.EZA_EMAIL_KEY, {  baseUrl: process.env.EZA_EMAIL_URL}) await email.emails.send({  from: 'no-reply@yourapp.co.ke',  to: 'user@example.com',  subject: 'Reset your password',  html: '<p>Use your password reset link.</p>'})
Send a password-reset email with the Resend package.

API or SMTP

Send with API or SMTP

Use whichever your framework already supports. Both use an API key with the email scope.

Use a separate API key with only the email scope for each app. If one app leaks its key, you revoke that key alone.

Read the SMTP guide

Sending API

Compatible with Resend’s email-send request and response format. Send one message or a batch.

Base URL
https://email.eza.co.ke
Batch send
Up to 100 emails per request
Rate limit
10 requests per second per Organisation

SMTP relay

For Laravel, WordPress, Django, Rails and anything else that already sends mail through SMTP.

Host
smtp.eza.co.ke
Ports
587 STARTTLS, 465 implicit TLS
Username
eza
Password
API key with the email scope
Connections
10 at once per Organisation

Moving from Resend

Change one URL in the Resend SDK

The sending API accepts Resend’s email-send request and returns the same response format. Existing Resend SDKs work when you set the base URL to https://email.eza.co.ke and use an Eza API key.

Webhooks, sending domains, limits and authentication are Eza-specific. Verify your domain on Eza and point webhooks at the Eza format before you switch production traffic.

Read the quick start
.env
EZA_EMAIL_URL=https://email.eza.co.keEZA_EMAIL_KEY=ez_email_your_key_here

Sending domains

Verify a sending domain

Add a sending domain before you send email to external recipients.

Read the domain guide
  1. 01

    Add a sending subdomain

    Use a dedicated subdomain such as mail.yourapp.co.ke. It protects the reputation of your main domain and leaves an SPF record used by Google Workspace or cPanel untouched.

  2. 02

    Add the DNS records Eza shows

    The dashboard generates the DKIM, SPF, MX and DMARC records for that domain. Add them at your DNS host.

  3. 03

    Eza checks each record

    Sending to external recipients starts once SPF, DKIM and DMARC all pass.

  • A root domain and each of its subdomains are verified separately.
  • A sending domain belongs to one Organisation at a time.
  • Another Organisation can claim a domain by adding a new TXT record. The original Organisation is emailed and loses the domain after a successful claim.

Authentication

SPF, DKIM and DMARC

Eza requires all three. Gmail and other mailbox providers expect them from senders, and require DMARC once volume grows.

See the exact records

DKIM

A 2048-bit RSA key for each domain, published at the eza._domainkey selector. Eza signs every message with it.

SPF

include:spf.eza.co.ke on a bounce subdomain such as send.yourapp.co.ke. That subdomain also gets an MX record so bounces come back to Eza.

DMARC

A DMARC record with at least p=none. Eza requires it so a busy month never runs into a late verification block.

Before verification

Mail before domain verification

You can start testing before DNS finishes. Until a domain is verified, email can only be sent to members of the sending Organisation.

Invite a teammate to the Organisation if they need to receive test mail.

Delivery events

Delivery events and webhooks

Eza records whether each message was delivered, bounced or complained about.

Read events by webhook, in the searchable dashboard log, as a CSV export or from a paginated API endpoint.

Read the webhook guide
  • email.delivered
  • email.bounced
  • email.complained

Signed with

Eza-Signature: t=<timestamp>,v1=<signature>

HMAC-SHA256 over timestamp.body, with a secret for each endpoint. Reject timestamps older than 5 minutes. Eza webhooks are not Resend-compatible.

Retries over 24 hours

  1. 1About 10 seconds
  2. 21 minute
  3. 35 minutes
  4. 430 minutes
  5. 52 hours
  6. 66 hours
  7. 712 hours

Failed webhook events stay available for replay from the dashboard for 30 days.

Suppression

Bounce and complaint suppression

Hard bounces

An address that hard bounces is suppressed for your Organisation for 90 days. Remove up to 20 hard-bounce suppressions a day from the dashboard or API.

Complaints

An address that marks your mail as spam stays suppressed until removed. Removal needs a support request with evidence that the recipient agreed to receive the message.

Suppressions stay with the Organisation that created them, including after a domain moves.

Allowance

Allowance, grace and email packs

Every hosting plan includes an email allowance that resets on your subscription anniversary.

At 90%, Eza warns Organisation Owners. You get one 10% grace period each billing cycle. After that, Eza returns a clear email_limit_reached error. No message is silently delayed.

Buy an extra 20,000 emails for KES 500 from Billing → Add-ons or the CLI. Eza sends the M-Pesa prompt only after you choose Pay, and the credits become available once payment confirms. There is no automatic top-up.

Extra packs are used after the plan allowance. They expire at the end of the billing cycle after the one in which you bought them.

Read limits and allowance
Transactional email allowance by plan
PlanIncluded each billing cycle
Hobby5,000 emails
Starter25,000 emails
Pro100,000 emails

Sending limits

  • 10/sAPI requests per Organisation
  • 100Emails per batch request
  • 10SMTP connections at once
  • 10 MBAttachments per message, after encoding

For the first 14 days, new Organisations get one-quarter of these limits.

Over-limit requests return HTTP 429 with a Retry-After header.

Retention

Message and event retention

Send HTML, plain text or both. If you send only HTML, Eza generates a plain-text version.

Executable and similar high-risk attachment types are blocked.

  • 72 hoursMessage bodies and attachments, then deleted
  • 30 daysDelivery records and events
  • 90 daysHard-bounce suppression
  • Until removedComplaint suppression
Transactional only

For app messages, not campaigns

Eza email sends one-to-one app messages after a user action: password resets, sign-in codes, receipts and account notifications.

Newsletters, marketing campaigns, promotional bulk email and purchased contact lists are not allowed. Send those through a marketing-email tool.

Read the Acceptable Use Policy

FAQ

Transactional email questions

Something else? support@eza.co.ke

Can my app send email through Eza?

Yes. Eza Cloud sends transactional email such as password resets, receipts, sign-in codes and app notifications. Use a Resend-compatible sending API by changing the base URL, or connect through SMTP on port 587 or 465. Your sending domain must pass SPF, DKIM and DMARC checks. Transactional email is Beta.

Does my app need to be hosted on Eza?

No. Any app with an Eza API key that has the email scope can send, wherever it runs. The allowance comes with the Organisation’s hosting plan.

Do my Resend webhooks work unchanged?

No. Only the sending request and response format is Resend-compatible. Eza webhooks use their own Eza-Signature header, signed with HMAC-SHA256.

What happens if I run out of emails?

Eza warns Organisation Owners at 90% of the monthly allowance because password-reset and sign-in email should not fail without notice. You receive one 10% grace period each billing cycle. After that, Eza returns a clear sending error. Buy an extra 20,000-email pack for KES 500, or upgrade to a plan with a higher allowance.

Can I send newsletters?

No. Newsletters, marketing campaigns, promotional bulk email and purchased contact lists are not allowed. Use a marketing-email provider for those.

Does email keep sending if my invoice is overdue?

Yes, while the account is overdue but limited. If the Organisation is suspended, new sends return org_suspended. Messages accepted before suspension are still delivered, and scheduled sends are cancelled.

What happens to email settings when ownership transfers?

Sending domains, API keys and suppressions stay with the Organisation. If a domain moves to a different Organisation, it must be verified again with new DNS records, and its suppression list stays behind.

Send your first email from Eza

Create an API key with the email scope, verify a sending domain and point your Resend SDK or SMTP settings at Eza.