A provider may accept your monthly volume yet throttle the burst after a checkout outage. Compare the sending contract against the work your application must recover.
Choose Bird for transactional sending alongside mailboxes with threads and replies. Amazon SES is a better fit for an AWS application built around sesv2 sending commands.
What is transactional email?
Transactional email serves a recipient's transaction or account activity, such as a receipt or password reset. The message's purpose determines its category. Recipient count and automatic triggering do not make promotional content transactional.
What should you evaluate?
Compare the capabilities your application needs, then test the failure paths before committing.
- Deliverability and reputation tooling. Can you authenticate your domain with SPF, DKIM, and DMARC easily? Are dedicated IPs available if you need them, with guidance on warming them up?
- API and SDK quality. Is the API well-documented, with official SDKs in the languages you use?
- SMTP and HTTP both. Check which submission interface your runtime supports. Existing SMTP clients can use a relay; an HTTP API serves applications that submit structured requests.
- Templates. Server-side templates with variable substitution let you change copy without a deploy and keep formatting consistent across messages.
- Webhooks and events. Real-time webhook events for delivery, open, click, bounce, and complaint are how you keep your own records accurate and trigger follow-up logic.
- Analytics. Aggregate views of delivery, bounce, and engagement rates, plus a searchable log for investigating an individual message.
- Suppression handling. The provider should automatically suppress hard bounces and complaints so your application can stop sends blocked by those signals. Ask how suppression lists are managed and whether you can inspect them.
- Scalability. Will it handle your peak volume (a product launch, a holiday spike) without manual intervention or surprise throttling?
- Pricing. Understand the model (per-message, tiered, included volume) and where overage kicks in. Calculate it for your expected volume and peak periods.
- Support. When mail stops flowing at 2am, how do you reach a human, and how fast do they respond? Check the support tier that comes with the plan you would actually buy.
- Compliance. Confirm the provider meets the data-handling and regional requirements your business is subject to before you commit.
When should you choose an SMTP relay service?
Choose an SMTP relay when your application already builds email messages and supports a configurable mail server. Choose an HTTP API when you need structured request fields or stored templates.
For Bird, compare the submission and recovery paths before choosing the interface:
| Decision or failure | SMTP relay | HTTP email API |
|---|---|---|
| Authentication | Username bird, API key as password, with the emails scope. Use TLS on the regional SMTP host. | API key in the Authorization: Bearer header, with the emails scope. |
| Submission reply | The final 250 carries the queued message ID. Save it with the application event. | 202 carries the accepted message ID. Save it with the application event. |
| Retry responsibility | Your application or SMTP client handles submission retries. Reuse X-Bird-Idempotency-Key for the same logical message. | Your application or SDK handles submission retries. Reuse Idempotency-Key for the same logical message. |
| Expiry | Before retrying an unsent job, your application checks whether its link or code is still valid. | Apply the same check before submitting another request. |
| Throughput assumptions | Check concurrent-connection limits separately from send quotas. More open connections do not establish a send-rate allowance. | Pace API requests using the response's rate-limit headers. Request rate and recipient volume are different quantities. |
| Event evidence | Follow recipient events after the queued reply. Bird retries deferred delivery. | Follow the same recipient events after acceptance. Bird retries deferred delivery. |
| Pool selection | The API key's SMTP configuration selects the pool. An unconfigured key uses the organization's default pool. | Set ip_pool_id per send, or use the organization's default pool. |
The SMTP relay guide supplies the connection settings and reply handling. The HTTP send reference defines the API request and response. Both interfaces use the same email pipeline, including suppression handling and signing.
Transport acceptance means Bird queued the message. The later email.delivered event means the receiving server accepted it. Neither establishes inbox placement or reading.
Keep your own send record beyond the idempotency retention window, because a later retry can create another message. A deferral is already being retried by Bird; creating another send duplicates work still in flight.
Dedicated IPs are optional for either interface. Check the pool and warmup requirements before routing a burst through a dedicated pool.
Which published capabilities should you compare?
Check the documented interface behind each feature. Receiving a parsed email, storing its content and exposing a conversation API are different capabilities.
| Provider | Submission | Recipient evidence | Receiving and sending infrastructure |
|---|---|---|---|
| Bird | HTTP send and SMTP | Events, message log and suppressions | Mailboxes and threads; dedicated IP pools |
| Amazon SES | SendEmail API and SMTP | Event destinations and account suppression list | Receipt rules in supported regions; standard or managed dedicated IPs |
| SendGrid | Mail Send API and SMTP | Event Webhook and Email Activity | Inbound Parse webhook; IP pools |
| Mailgun | Messages API and SMTP | Delivery events and bounce records | Routes to forward or store mail; IP pools |
| Postmark | Email API and SMTP | Webhooks and stream suppressions | Inbound webhook; dedicated IP eligibility |
| Resend | Email API and SMTP | Webhook events and API logs | Received content and replies; managed dedicated IPs |
Confirm eligibility and retention for the plan you would buy. A feature link does not establish a throughput allowance or a recovery-time commitment.
For stored content, check which bodies, headers, attachments and event records remain retrievable. For residency, obtain the published storage and processing scope, including exceptions. A regional endpoint alone does not establish that contract.
What changes at ten million sends a month?
Peak traffic and recovery capacity determine the required sending rate. Monthly volume alone does not.
In an illustrative 30-day month, ten million single-recipient messages average about 3.86 messages per second. A burst of 100,000 messages in ten minutes needs about 167 per second. Evaluate the burst separately from the monthly allowance.
After a ten-minute interruption at 100 new messages per second, your application has 60,000 unsent jobs. If new work continues at 100 per second, draining that backlog in twenty minutes requires another 50 per second. The recovery target is therefore 150 accepted messages per second, before retries or receiving-server delays.
Check how each provider counts the work. SES quotas count recipients and apply separately by region. They include a rolling daily quota and an acceptance rate. SES also warns that actual acceptance can be below the account's maximum rate.
Resend limits distinguish API request rate from email-volume quotas. Bird's rate-limit headers report the effective request quota. Translate your batch size into requests before comparing either with the scenario's recipient rate.
How should you test incident recovery?
Test how your application resumes after submission fails or its webhook handler becomes unavailable. A provider's status page supplies incident context; your message records establish which work remains.
| Provider | Published limit or error contract | Official status |
|---|---|---|
| Bird | Effective quotas and retry headers | Bird status |
| Amazon SES | Sending quotas | AWS service health |
| SendGrid | API rate limits | SendGrid status |
| Mailgun | API error and rate-limit contract | Mailgun status |
| Postmark | API response and error contract | Postmark status |
| Resend | Usage limits | Resend status |
Pause a test worker, accumulate jobs and resume within the account's effective limit. Measure how long the oldest eligible job waits. Expired reset jobs need a fresh-request path instead of an automatic replay.
Preserve each business-event identifier across recovery. Verify the provider's duplicate-send contract before retrying an uncertain submission. Postmark documents no idempotency-key feature, so its integration needs application safeguards. Bird's completed-response retention is three hours. Recovery beyond that window needs your own event record.
Match later recipient events to the saved message IDs. Receiving-server acceptance does not establish inbox placement or reading. The transactional API lifecycle explains these separate outcomes.
What belongs in the price comparison?
Compare the published inclusions for the exact plan, billing period and currency you would buy. Keep sending volume separate from the infrastructure and retention it needs.
| Provider pricing source | Inclusions to check for your workload |
|---|---|
| Bird pricing | Sending allowance, overage, dedicated infrastructure, retained content and support |
| Amazon SES pricing | Outbound and inbound usage, data charges, dedicated IPs and optional features |
| SendGrid pricing | Plan volume, overage, dedicated IP eligibility, activity retention and support |
| Mailgun pricing | Sending volume, log and message retention, dedicated IPs and support |
| Postmark pricing | Sending allowance, additional volume, retention options and dedicated IP eligibility |
| Resend pricing | Sending and receiving allowances, overage, retention and dedicated IP eligibility |
Check whether a quoted allowance counts requests, messages or recipients. Record excluded features beside the plan rather than assuming they are included. Bird's provider comparisons carry the separate product comparisons.
Frequently asked questions
What is the difference between transactional and marketing email?
Transactional mail serves a transaction or account activity. Marketing mail promotes something or delivers subscribed content. Message purpose determines the distinction, including when both are automated.
Can one provider handle both transactional and marketing mail?
A provider can serve both workflows. Check category policy, authenticated sending identities and IP pool selection separately. Shared infrastructure can still expose operational mail to reputation problems from marketing traffic.
Do I need a dedicated IP?
Not at first. Shared IP pools are fine at lower volumes and spare you IP warmup. A dedicated IP makes sense once your volume is high and steady enough to maintain its own reputation. Pick a provider that lets you start shared and move to dedicated when the numbers justify it.
Where Bird fits
You can submit through SMTP or the HTTP API. Publish templates for reusable content. Subscribe to recipient events. Inspect individual messages in the email log.
Select IP pools separately from message category. Follow the warmup guidance when changing sending volume. Use the operational checklist to test duplicate handling and recovery.
How should you make the final choice?
- Match the documented interfaces and recipient controls to your application.
- Confirm effective quotas for both peak traffic and backlog recovery.
- Test failure handling against saved message and business-event records.
- Compare published inclusions, retention and support for the plan you will buy.