Kenapa pengiriman email transaksional adalah tantangan yang berbeda
Ada perbedaan penting antara email pemasaran dan email transaksional yang banyak dilewatkan pengembang saat pertama kali mulai memikirkan keterkiriman secara serius. Email pemasaran — buletin, kampanye promosi, pengumuman — dikirim ke pelanggan yang sudah memilih untuk menerimanya. Mereka dapat mentolerir keterlambatan sesekali dan bahkan penempatan di folder spam sesekali. Jika sebuah buletin masuk ke spam untuk 2% dari daftarmu, itu memang disayangkan tapi bisnismu tetap berjalan.
Email transaksional sepenuhnya berbeda. Tautan verifikasi, reset kata sandi, konfirmasi pembelian, kode autentikasi dua faktor, peringatan keamanan akun — semuanya mendarat pada momen kritis dalam perjalanan pengguna. Reset kata sandi yang masuk ke spam berarti penggunamu terkunci dari akunnya dan kemungkinan besar akan membuat tiket dukungan atau, lebih buruk, tidak pernah kembali. Email verifikasi yang masuk ke spam berarti pengguna baru tidak bisa menyelesaikan pendaftaran dan funnel akuisisimu memiliki kebocoran yang sunyi dan tak terlihat.
Namun, email transaksional sering kali disiapkan dengan kurang cermat dibanding kampanye pemasaran. Banyak pengembang menggunakan kode pengiriman email apa pun yang disediakan oleh framework mereka, mengonfigurasinya dengan server SMTP bersama, men-deploy-nya, mengujinya sekali dengan kotak masuk mereka sendiri — yang memiliki ambang spam yang longgar — lalu melanjutkan. Masalahnya baru muncul ketika pengguna asli di Gmail, Outlook, atau Yahoo melaporkan email yang hilang. Pada saat itu, masalah tersebut sudah gagal secara diam-diam di produksi selama berminggu-minggu.
SPF: fondasi autentikasi email
Sender Policy Framework (SPF) adalah rekaman DNS TXT pada domain pengirimmu yang memberi tahu dunia server surat mana yang diizinkan mengirim email atas namamu. Ketika Gmail menerima email yang seolah-olah berasal dari [email protected], ia melakukan pencarian DNS untuk rekaman SPF domainmu. Jika alamat IP server yang benar-benar mengirim email itu tercantum dalam rekaman SPF-mu, email tersebut lolos SPF. Jika tidak ada rekaman SPF sama sekali — atau server pengirim tidak tercantum — email tersebut diperlakukan dengan kecurigaan bahkan sebelum evaluasi konten apa pun dimulai.
Menyiapkan SPF cukup mudah setelah kamu tahu apa yang kamu lakukan. Tambahkan rekaman TXT ke DNS domainmu. Nilainya bergantung pada penyedia pengirimanmu. Jika kamu menggunakan SendGrid: v=spf1 include:sendgrid.net ~all. Jika kamu menggunakan AWS SES: v=spf1 include:amazonses.com ~all. Jika kamu menggunakan Mailgun: v=spf1 include:mailgun.org ~all. Dokumentasi penyediamu akan memberimu nilai include yang tepat. Akhiran ~all adalah "soft fail" — email dari server yang tidak tercantum akan ditandai tapi tidak langsung ditolak. Setelah kamu yakin bahwa rekaman SPF-mu lengkap dan benar, kamu bisa meningkatkannya menjadi -all (hard fail), yang menginstruksikan server penerima untuk menolak sepenuhnya surat yang tidak sah.
Satu jebakan umum: batas 10 pencarian DNS. Rekaman SPF yang merangkai beberapa direktif include: dapat melampaui batas ini, menyebabkan SPF gagal meskipun semua servermu secara teknis tercantum. Gunakan MXToolbox untuk memeriksa rekaman SPF-mu — ia akan menandai masalah jumlah pencarian dengan jelas. Memahami bagaimana SPF, DKIM, dan DMARC saling berkaitan dibahas dengan baik dalam dokumentasi SendGrid tentang autentikasi email.
DKIM: bukti kriptografis bahwa emailmu tidak dirusak
DomainKeys Identified Mail (DKIM) menambahkan tanda tangan kriptografis ke setiap email yang kamu kirim. Tanda tangan itu dihasilkan menggunakan kunci privat yang dipegang oleh penyedia pengirimanmu, dan server surat penerima memverifikasinya terhadap kunci publik yang kamu publikasikan sebagai rekaman DNS TXT. Jika tanda tangan itu cocok, dua hal terbukti: email tersebut benar-benar berasal dari infrastruktur pengirimanmu, dan kontennya tidak diubah antara pengiriman dan penerimaan.
Tanpa DKIM yang dikonfigurasi, menjadi jauh lebih mudah bagi pelaku jahat untuk memalsukan domainmu — mengirim email yang tampak berasal dari [email protected] tapi sebenarnya dikirim oleh orang lain sepenuhnya. Beginilah cara kampanye phishing bekerja. Filter spam juga tahu ini, itulah sebabnya email yang tidak memiliki tanda tangan DKIM yang valid dari domain yang seharusnya memilikinya diperlakukan dengan kecurigaan yang lebih tinggi. Spamhaus dan layanan reputasi lainnya memperhitungkan riwayat penandatanganan DKIM ke dalam skor reputasi domain.
Menyiapkan DKIM dilakukan melalui penyedia pengirimanmu. Mereka menghasilkan pasangan kunci, menyimpan kunci privat di infrastruktur mereka, dan memberimu kunci publik untuk ditambahkan ke DNS-mu sebagai rekaman TXT. Setelah rekaman DNS itu dipublikasikan dan tersebar, setiap email yang mereka kirim atas namamu akan membawa tanda tangan DKIM yang valid secara otomatis. Sebagian besar penyedia besar — SendGrid, Mailgun, Amazon SES, Postmark — memandumu melalui proses ini selama penyiapan awal. Jika kamu melewatkannya, kembali dan konfigurasikan sekarang.
DMARC: lapisan kebijakan yang mengikat semuanya
DMARC (Domain-based Message Authentication, Reporting, and Conformance) dibangun di atas SPF dan DKIM dengan mendefinisikan apa yang harus dilakukan server penerima ketika sebuah email gagal dalam pemeriksaan tersebut. Ia juga memperkenalkan "penyelarasan" (alignment) — mengharuskan domain di header From email benar-benar cocok dengan domain yang lolos SPF atau DKIM. Ini mencegah penyerang lolos pemeriksaan SPF pada satu domain sambil memalsukan domain lain di alamat From yang terlihat.
Pendekatan yang tepat untuk DMARC adalah memulai secara bertahap. Mulailah dengan kebijakan pemantauan saja: v=DMARC1; p=none; rua=mailto:[email protected]. p=none memberi tahu server penerima untuk tidak mengambil tindakan atas kegagalan, hanya mengirimimu laporan. Laporan agregat itu akan memberi tahu server mana yang mengirim email atas namamu dan apakah mereka lolos SPF dan DKIM. Tinjau laporan tersebut selama beberapa minggu sebelum membuat perubahan kebijakan apa pun.
Setelah kamu yakin semua yang sah lolos, beralihlah ke p=quarantine (email yang gagal masuk ke folder spam) dan akhirnya p=reject (email yang gagal ditolak sepenuhnya). Perkembangan ini melindungi reputasi domainmu dari pemalsuan sambil memberimu waktu untuk menangkap sumber email sah apa pun yang mungkin terlewat. Kebijakan DMARC p=reject yang dikombinasikan dengan SPF dan DKIM yang lolos membuat penyerang hampir mustahil untuk menyamar sebagai domainmu secara efektif.
Reputasi IP: kenapa server pengirimmu penting
Bahkan dengan SPF, DKIM, dan DMARC yang sempurna, emailmu masih bisa masuk ke spam jika alamat IP tempat email itu dikirim memiliki reputasi buruk. Server surat penerima memelihara — atau berkonsultasi dengan layanan pihak ketiga yang memelihara — daftar blokir dan skor reputasi untuk alamat IP pengirim. IP dengan riwayat mengirim spam, atau yang muncul di daftar blokir yang dikelola oleh layanan seperti Spamhaus, akan memiliki email keluarnya diperlakukan dengan kecurigaan terlepas dari pengaturan autentikasimu.
Jika kamu menggunakan alamat IP bersama dari penyedia hosting bersama atau layanan SMTP murah, reputasimu terikat pada semua orang lain yang menggunakan IP yang sama itu. Satu pengirim spam di kumpulan bersama yang sama dapat menghancurkan keterkiriman untuk semua pengirim di IP tersebut. Ini adalah salah satu argumen terkuat untuk menggunakan penyedia email transaksional khusus — SendGrid, Amazon SES, Postmark, Mailgun — daripada mengirim email langsung dari server aplikasimu atau melalui layanan SMTP bersama.
Pada IP pengirim baru, kamu juga perlu "memanaskan" IP secara bertahap. Mengirim lonjakan volume email yang tiba-tiba dari IP baru terlihat seperti perilaku spam bagi server penerima. Mulailah dengan volume yang lebih rendah dan tingkatkan secara bertahap selama beberapa hari atau minggu. Sebagian besar penyedia email khusus menangani pemanasan IP secara otomatis jika kamu berada di kumpulan pengiriman bersama, atau menyediakan jadwal pemanasan IP jika kamu menggunakan IP khusus.
Konten dan baris subjek: apa yang memicu filter
Di luar autentikasi dan reputasi IP, konten emailmu sendiri dievaluasi oleh filter spam. Pola tertentu secara andal memicu klasifikasi spam. Kata pemicu spam di baris subjek — "GRATIS", "DIJAMIN", "BERTINDAK SEKARANG", tanda seru berlebihan, HURUF KAPITAL SEMUA — adalah hal yang jelas yang dihindari sebagian besar pengembang. Yang kurang jelas: baris subjek yang terlalu samar ("Pesan penting untukmu"), terlalu mendesak ("Akunmu akan ditutup"), atau terlalu promosional untuk sesuatu yang seharusnya email transaksional.
Rasio teks-ke-gambar juga penting. Email yang sebagian besar berupa gambar dengan teks minimal adalah pola spam klasik — pengirim massal menggunakan gambar untuk mengaburkan kata kunci dari filter berbasis teks. Email transaksional harus terutama berbasis teks dengan gambar minimal. HTML yang rusak — tag yang tidak ditutup, atribut yang salah bentuk — adalah tanda bahaya lain. Selalu kirim alternatif teks biasa bersama versi HTML-mu. Filter spam memandang email yang hanya HTML dengan kecurigaan yang lebih tinggi, dan sistem email perusahaan sering menghapus HTML sepenuhnya.
Menguji pengiriman emailmu — dengan cara yang benar
Metode pengujian tercepat dan paling praktis untuk pengiriman email adalah: kirim email uji ke kotak masuk temp mail yang baru dan periksa baik folder kotak masuk maupun folder spam. Ini memberimu umpan balik langsung dan tegas tentang apakah emailmu mencapai kotak masuk atau tersaring. Berbeda dengan pengujian dengan akun Gmail-mu sendiri — yang mungkin telah menempatkanmu di whitelist sebagai pengirim yang sering — alamat sementara yang baru tidak memiliki riwayat sebelumnya dengan domainmu, yang lebih akurat mensimulasikan pengalaman kontak pertama pengguna baru.
Kamu harus menguji pengiriman setiap kali kamu mengubah apa pun yang dapat memengaruhinya: berganti penyedia email, memperbarui template HTML secara signifikan, mengubah domain pengirim, menambahkan subdomain pengirim baru, atau men-deploy ke lingkungan baru (staging, produksi). Ini memakan dua menit dan memberimu bukti definitif. Alternatifnya — menunggu pengguna melaporkan masalah — berarti masalah keterkirimanmu sudah gagal secara diam-diam selama periode yang tidak diketahui.
Di luar pemeriksaan kotak masuk/spam, gunakan pemeriksa kesehatan email MXToolbox untuk memeriksa kesehatan keseluruhan domainmu: SPF, DKIM, DMARC, status daftar hitam, dan konfigurasi rekaman MX semuanya di satu tempat. Jadikan ini bagian dari daftar periksa pra-peluncuranmu untuk setiap aplikasi atau domain pengirim baru. Periksa juga pedoman OWASP untuk praktik terbaik email terkait keamanan.
Tingkat pentalan dan keluhan spam: metrik yang penting
Dua metrik memiliki efek yang luar biasa pada keterkiriman jangka panjang: tingkat pentalan (bounce rate) dan tingkat keluhan spam. Tingkat pentalan di atas 2% memberi tahu server penerima dan penyedia pengirimanmu bahwa kamu mengirim ke banyak alamat yang tidak valid atau tidak ada — yang merupakan pola yang terkait dengan daftar email yang dibeli dan operasi spam. Bahkan jika kamu melakukan segala sesuatu yang lain dengan benar, tingkat pentalan yang tinggi akan menyebabkan masalah keterkiriman. Hapus pentalan keras (hard bounce) dari daftar pengirimanmu segera dan secara permanen.
Tingkat keluhan spam di atas 0,1% (satu keluhan per seribu email yang dikirim) adalah ambang di mana sebagian besar penyedia pengiriman akan mulai membatasi akunmu. Postmaster Tools milik Gmail melaporkan tingkat keluhan secara langsung jika kamu sudah menyiapkannya. Pantau metrik ini melalui dasbor penyedia pengirimanmu. Jika tingkat keluhan meningkat, selidiki mengapa — apakah kamu mengirim ke pengguna yang tidak secara eksplisit memilih ikut? Apakah emailmu terlalu sering? Apakah ada ketidaksesuaian antara apa yang pengguna harapkan dan apa yang mereka terima?
Daftar periksa keterkiriman lengkap
- Rekaman SPF: Rekaman DNS TXT pada domain pengirimmu yang mencantumkan semua server pengirim yang sah. Uji dengan MXToolbox.
- DKIM: Penandatanganan kriptografis dikonfigurasi melalui penyedia pengirimanmu, kunci publik dipublikasikan di DNS.
- DMARC: Mulai dengan pemantauan
p=none, lanjutkan kep=quarantinelalup=rejectsetelah meninjau laporan agregat. - Penyedia pengiriman khusus: Gunakan SendGrid, SES, Postmark, atau Mailgun — bukan server aplikasimu atau SMTP bersama.
- Baris subjek bersih: Spesifik, relevan, tanpa kata pemicu, tanpa tanda baca atau huruf kapital berlebihan.
- HTML + teks biasa: Selalu sertakan keduanya. Jangan pernah mengirim email yang hanya HTML.
- Tanpa pemendek URL: Gunakan URL penuh dan langsung di badan email dan tautan verifikasi.
- Tautan berhenti berlangganan: Sertakan bahkan dalam email transaksional di mana sesuai — beberapa penyedia mewajibkannya.
- Alamat fisik: Diwajibkan oleh CAN-SPAM dan peraturan serupa di banyak yurisdiksi.
- Penanganan pentalan keras: Hapus segera; jangan pernah mencoba ulang pentalan keras.
- Pemantauan keluhan: Siapkan Gmail Postmaster Tools; pantau dasbor tingkat keluhan.
- Pengujian kotak masuk: Kirim email uji ke kotak masuk sementara yang baru sebelum setiap deploy dan setelah perubahan template atau konfigurasi apa pun.
- Pemeriksaan kesehatan MXToolbox: Sertakan dalam daftar periksa pra-peluncuranmu untuk setiap domain dan lingkungan baru.
Kapan menggunakan layanan email transaksional khusus
Jika aplikasimu mengirim email apa pun yang perlu diterima pengguna agar berfungsi — tautan verifikasi, reset kata sandi, konfirmasi pembelian — kamu harus menggunakan penyedia email transaksional khusus sejak hari pertama. Biayanya rendah (sering kali gratis hingga puluhan ribu email per bulan), keandalannya jauh lebih baik daripada SMTP buatan sendiri, dan infrastruktur keterkiriman — kumpulan IP bersama dengan reputasi yang dikelola, penandatanganan DKIM otomatis, penanganan pentalan dan keluhan — dipelihara oleh tim yang seluruh pekerjaannya adalah menjaga email tetap di kotak masuk.
Kesalahan buatan-sendiri yang paling umum adalah menjalankan server surat di IP yang sama dengan aplikasi webmu, atau menggunakan layanan SMTP bawaan dari penyedia hosting murah. IP-IP ini secara rutin ditambahkan ke daftar blokir oleh layanan seperti Spamhaus karena lingkungan hosting-nya dibagikan dengan pelaku jahat. Beralih ke penyedia transaksional khusus biasanya adalah pekerjaan satu sore dan memiliki dampak positif langsung pada keterkiriman. Ini adalah salah satu peningkatan infrastruktur dengan pengaruh tertinggi yang dapat dilakukan tim kecil. Tim yang sadar privasi juga harus meninjau panduan dari Electronic Frontier Foundation tentang penanganan data pengguna secara bertanggung jawab ketika email terlibat. Selain itu, memantau alamat terhadap basis data pelanggaran yang diketahui melalui Have I Been Pwned dapat melengkapi pencegahan penipuanmu saat akun baru dibuat.