Penyedia mungkin menerima volume bulanan Anda tetapi membatasi lonjakan setelah gangguan checkout. Bandingkan kontrak pengiriman dengan pekerjaan yang harus dipulihkan aplikasi Anda.
Pilih Bird untuk pengiriman transaksional bersama kotak masuk dengan thread dan balasan. Amazon SES lebih cocok untuk aplikasi AWS yang dibangun di sekitar perintah pengiriman sesv2.
Apa itu email transaksional?
Email transaksional melayani transaksi atau aktivitas akun penerima, seperti tanda terima atau reset kata sandi. Tujuan pesan menentukan kategorinya. Jumlah penerima dan pengiriman otomatis tidak menjadikan konten promosi sebagai transaksional.
Apa yang harus Anda evaluasi?
Bandingkan kemampuan yang dibutuhkan aplikasi Anda, lalu uji jalur kegagalan sebelum berkomitmen.
- Deliverability dan perangkat reputasi. Dapatkah Anda mengautentikasi domain dengan SPF, DKIM, dan DMARC dengan mudah? Apakah IP dedicated tersedia jika Anda membutuhkannya, dengan panduan pemanasan?
- Kualitas API dan SDK. Apakah API terdokumentasi dengan baik, dengan SDK resmi dalam bahasa yang Anda gunakan?
- SMTP dan HTTP keduanya. Periksa antarmuka pengiriman mana yang didukung runtime Anda. Klien SMTP yang sudah ada dapat menggunakan relay; HTTP API melayani aplikasi yang mengirimkan permintaan terstruktur.
- Template. Template sisi server dengan substitusi variabel memungkinkan Anda mengubah teks tanpa deploy dan menjaga format tetap konsisten di seluruh pesan.
- Webhook dan event. Event webhook real-time untuk pengiriman, open, click, bounce, dan complaint adalah cara Anda menjaga catatan tetap akurat dan memicu logika tindak lanjut.
- Analitik. Tampilan agregat tingkat pengiriman, bounce, dan engagement, ditambah log yang dapat dicari untuk menyelidiki pesan individual.
- Penanganan supresi. Provider harus secara otomatis menekan hard bounce dan complaint agar aplikasi Anda dapat menghentikan pengiriman yang diblokir oleh sinyal tersebut. Tanyakan bagaimana daftar supresi dikelola dan apakah Anda dapat memeriksanya.
- Skalabilitas. Dapatkah ia menangani volume puncak Anda (peluncuran produk, lonjakan hari libur) tanpa intervensi manual atau throttling mendadak?
- Harga. Pahami modelnya (per pesan, bertingkat, volume termasuk) dan kapan biaya lebih mulai berlaku. Hitung untuk volume yang Anda perkirakan dan periode puncak.
- Dukungan. Ketika email berhenti mengalir pukul 2 pagi, bagaimana Anda menghubungi seseorang, dan seberapa cepat mereka merespons? Periksa tier dukungan yang disertakan dalam paket yang benar-benar akan Anda beli.
- Kepatuhan. Pastikan provider memenuhi persyaratan penanganan data dan regional yang berlaku untuk bisnis Anda sebelum berkomitmen.
Kapan Anda harus memilih layanan relay SMTP?
Pilih relay SMTP ketika aplikasi Anda sudah membangun pesan email dan mendukung server email yang dapat dikonfigurasi. Pilih HTTP API ketika Anda membutuhkan field permintaan terstruktur atau template tersimpan.
Untuk Bird, bandingkan jalur pengiriman dan pemulihan sebelum memilih antarmuka:
| Keputusan atau kegagalan | Relay SMTP | Email HTTP API |
|---|---|---|
| Autentikasi | Username bird, kunci API sebagai password, dengan scope emails. Gunakan TLS pada host SMTP regional. | Kunci API di header Authorization: Bearer, dengan scope emails. |
| Balasan pengiriman | 250 terakhir membawa ID pesan yang diantrikan. Simpan bersama event aplikasi. | 202 membawa ID pesan yang diterima. Simpan bersama event aplikasi. |
| Tanggung jawab retry | Aplikasi Anda atau klien SMTP menangani retry pengiriman. Gunakan kembali X-Bird-Idempotency-Key untuk pesan logis yang sama. | Aplikasi Anda atau SDK menangani retry pengiriman. Gunakan kembali Idempotency-Key untuk pesan logis yang sama. |
| Kedaluwarsa | Sebelum mencoba ulang pekerjaan yang belum terkirim, aplikasi Anda memeriksa apakah tautan atau kodenya masih valid. | Lakukan pemeriksaan yang sama sebelum mengirimkan permintaan lain. |
| Asumsi throughput | Periksa batas koneksi bersamaan secara terpisah dari kuota pengiriman. Lebih banyak koneksi terbuka tidak menetapkan jatah laju pengiriman. | Atur laju permintaan API menggunakan header rate-limit dari respons. Laju permintaan dan volume penerima adalah kuantitas yang berbeda. |
| Bukti event | Ikuti event penerima setelah balasan antrean. Bird mencoba ulang pengiriman yang ditangguhkan. | Ikuti event penerima yang sama setelah penerimaan. Bird mencoba ulang pengiriman yang ditangguhkan. |
| Pemilihan pool | Konfigurasi SMTP dari kunci API memilih pool. Kunci yang tidak dikonfigurasi menggunakan pool default organisasi. | Atur ip_pool_id per pengiriman, atau gunakan pool default organisasi. |
Panduan relay SMTP menyediakan pengaturan koneksi dan penanganan balasan. Referensi pengiriman HTTP mendefinisikan permintaan dan respons API. Kedua antarmuka menggunakan pipeline email yang sama, termasuk penanganan supresi dan penandatanganan.
Penerimaan transport berarti Bird mengantrikan pesan. Event email.delivered berikutnya berarti server penerima menerimanya. Keduanya tidak menetapkan penempatan inbox atau pembacaan.
Simpan catatan pengiriman Anda sendiri melampaui jendela retensi idempotensi, karena retry berikutnya dapat membuat pesan lain. Penangguhan sudah dicoba ulang oleh Bird; membuat pengiriman lain menduplikasi pekerjaan yang masih berjalan.
IP dedicated bersifat opsional untuk kedua antarmuka. Periksa persyaratan pool dan pemanasan sebelum merutekan burst melalui pool dedicated.
Kemampuan terpublikasi mana yang harus Anda bandingkan?
Periksa antarmuka terdokumentasi di balik setiap fitur. Menerima email yang di-parse, menyimpan kontennya, dan mengekspos API percakapan adalah kemampuan yang berbeda.
| Provider | Pengiriman | Bukti penerima | Infrastruktur penerimaan dan pengiriman |
|---|---|---|---|
| Bird | Pengiriman HTTP dan SMTP | Event, log pesan dan supresi | Kotak masuk dan thread; pool IP dedicated |
| Amazon SES | SendEmail API dan SMTP | Destinasi event dan daftar supresi akun | Aturan penerimaan di region yang didukung; IP dedicated standar atau managed |
| SendGrid | Mail Send API dan SMTP | Event Webhook dan Email Activity | Inbound Parse webhook; IP pools |
| Mailgun | Messages API dan SMTP | Event pengiriman dan catatan bounce | Rute untuk meneruskan atau menyimpan email; IP pools |
| Postmark | Email API dan SMTP | Webhook dan supresi stream | Inbound webhook; kelayakan IP dedicated |
| Resend | Email API dan SMTP | Event webhook dan log API | Konten diterima dan balasan; IP dedicated managed |
Konfirmasi kelayakan dan retensi untuk paket yang akan Anda beli. Tautan fitur tidak menetapkan jatah throughput atau komitmen waktu pemulihan.
Untuk konten tersimpan, periksa body, header, lampiran, dan catatan event mana yang masih dapat diambil. Untuk residensi data, dapatkan cakupan penyimpanan dan pemrosesan yang dipublikasikan, termasuk pengecualian. Endpoint regional saja tidak menetapkan kontrak tersebut.
Apa yang berubah pada sepuluh juta pengiriman per bulan?
Lalu lintas puncak dan kapasitas pemulihan menentukan laju pengiriman yang dibutuhkan. Volume bulanan saja tidak.
Dalam ilustrasi bulan 30 hari, sepuluh juta pesan penerima-tunggal rata-rata sekitar 3,86 pesan per detik. Burst 100.000 pesan dalam sepuluh menit membutuhkan sekitar 167 per detik. Evaluasi burst secara terpisah dari jatah bulanan.
Setelah gangguan sepuluh menit pada 100 pesan baru per detik, aplikasi Anda memiliki 60.000 pekerjaan yang belum terkirim. Jika pekerjaan baru berlanjut pada 100 per detik, menguras backlog tersebut dalam dua puluh menit membutuhkan tambahan 50 per detik. Target pemulihan adalah 150 pesan diterima per detik, sebelum retry atau penundaan server penerima.
Periksa cara setiap provider menghitung pekerjaan. Kuota SES menghitung penerima dan berlaku terpisah per region. Kuota ini mencakup kuota harian bergulir dan laju penerimaan. SES juga memperingatkan bahwa penerimaan aktual bisa di bawah laju maksimum akun.
Batas Resend membedakan laju permintaan API dari kuota volume email. Header rate-limit Bird melaporkan kuota permintaan efektif. Terjemahkan ukuran batch Anda menjadi permintaan sebelum membandingkan keduanya dengan laju penerima skenario.
Bagaimana Anda harus menguji pemulihan insiden?
Uji bagaimana aplikasi Anda melanjutkan setelah pengiriman gagal atau handler webhook-nya tidak tersedia. Halaman status provider menyediakan konteks insiden; catatan pesan Anda menetapkan pekerjaan mana yang tersisa.
| Provider | Batas terpublikasi atau kontrak error | Status resmi |
|---|---|---|
| Bird | Kuota efektif dan header retry | Status Bird |
| Amazon SES | Kuota pengiriman | Kesehatan layanan AWS |
| SendGrid | Rate limit API | Status SendGrid |
| Mailgun | Kontrak error dan rate-limit API | Status Mailgun |
| Postmark | Kontrak respons dan error API | Status Postmark |
| Resend | Batas penggunaan | Status Resend |
Jeda worker uji, akumulasi pekerjaan, dan lanjutkan dalam batas efektif akun. Ukur berapa lama pekerjaan tertua yang memenuhi syarat menunggu. Pekerjaan reset yang kedaluwarsa membutuhkan jalur permintaan baru, bukan replay otomatis.
Pertahankan setiap identifier business-event selama pemulihan. Verifikasi kontrak pengiriman duplikat dari provider sebelum mencoba ulang pengiriman yang tidak pasti. Postmark tidak mendokumentasikan fitur idempotency-key, sehingga integrasinya membutuhkan pengamanan di sisi aplikasi. Retensi completed-response Bird adalah tiga jam. Pemulihan melampaui jendela tersebut membutuhkan catatan event Anda sendiri.
Cocokkan event penerima berikutnya dengan ID pesan yang disimpan. Penerimaan oleh server penerima tidak menetapkan penempatan inbox atau pembacaan. Siklus hidup API transaksional menjelaskan hasil-hasil terpisah ini.
Apa yang termasuk dalam perbandingan harga?
Bandingkan inklusi terpublikasi untuk paket, periode penagihan, dan mata uang yang tepat yang akan Anda beli. Pisahkan volume pengiriman dari infrastruktur dan retensi yang dibutuhkannya.
| Sumber harga provider | Inklusi yang perlu diperiksa untuk beban kerja Anda |
|---|---|
| Harga Bird | Jatah pengiriman, biaya lebih, infrastruktur dedicated, konten tersimpan, dan dukungan |
| Harga Amazon SES | Penggunaan outbound dan inbound, biaya data, IP dedicated, dan fitur opsional |
| Harga SendGrid | Volume paket, biaya lebih, kelayakan IP dedicated, retensi aktivitas, dan dukungan |
| Harga Mailgun | Volume pengiriman, retensi log dan pesan, IP dedicated, dan dukungan |
| Harga Postmark | Jatah pengiriman, volume tambahan, opsi retensi, dan kelayakan IP dedicated |
| Harga Resend | Jatah pengiriman dan penerimaan, biaya lebih, retensi, dan kelayakan IP dedicated |
Periksa apakah jatah yang dikutip menghitung permintaan, pesan, atau penerima. Catat fitur yang dikecualikan di samping paket, jangan berasumsi fitur tersebut sudah termasuk. Perbandingan provider Bird memuat perbandingan produk terpisah.
Pertanyaan yang sering diajukan
Apa perbedaan antara email transaksional dan marketing?
Email transaksional melayani transaksi atau aktivitas akun. Email marketing mempromosikan sesuatu atau mengirimkan konten berlangganan. Tujuan pesan menentukan perbedaannya, termasuk ketika keduanya diotomatisasi.
Bisakah satu provider menangani email transaksional dan marketing?
Satu provider dapat melayani kedua alur kerja. Periksa kebijakan kategori, identitas pengiriman yang diautentikasi, dan pemilihan pool IP secara terpisah. Infrastruktur bersama masih dapat mengekspos email operasional terhadap masalah reputasi dari lalu lintas marketing.
Apakah saya memerlukan IP dedicated?
Tidak pada awalnya. Pool IP bersama memadai pada volume rendah dan menghindarkan Anda dari pemanasan IP. IP dedicated masuk akal setelah volume Anda cukup tinggi dan stabil untuk mempertahankan reputasinya sendiri. Pilih provider yang memungkinkan Anda memulai dari IP bersama dan beralih ke dedicated ketika angkanya membenarkan.
Posisi Bird
Anda dapat mengirim melalui SMTP atau HTTP API. Publikasikan template untuk konten yang dapat digunakan ulang. Berlangganan event penerima. Periksa pesan individual di log email.
Pilih pool IP secara terpisah dari kategori pesan. Ikuti panduan pemanasan saat mengubah volume pengiriman. Gunakan checklist operasional untuk menguji penanganan duplikat dan pemulihan.
Bagaimana Anda membuat pilihan akhir?
- Cocokkan antarmuka terdokumentasi dan kontrol penerima dengan aplikasi Anda.
- Konfirmasi kuota efektif untuk lalu lintas puncak dan pemulihan backlog.
- Uji penanganan kegagalan terhadap catatan pesan dan business-event yang disimpan.
- Bandingkan inklusi terpublikasi, retensi, dan dukungan untuk paket yang akan Anda beli.