Cara Mengirim Email dari Aplikasi Anda (dan Masuk ke Kotak Masuk)

Untuk mengirim email dari aplikasi secara andal, gunakan penyedia pengiriman email alih-alih kotak surat pribadi, kirim dari alamat di domain Anda sendiri, dan tambahkan rekaman DNS yang diberikan penyedia agar SPF, DKIM, dan DMARC lolos semuanya. Pisahkan email transaksional (reset kata sandi, kwitansi, konfirmasi) dari email pemasaran, kirim masing-masing hanya kepada orang yang memang mengharapkannya, dan tangani bounce serta berhenti langganan. Pastikan autentikasi benar terlebih dahulu; ini adalah penyebab paling umum email aplikasi berakhir di spam.

Transaksional vs pemasaran

Kedua jenis email ini terlihat mirip di dalam kode, tetapi diperlakukan sangat berbeda oleh penyedia kotak masuk dan oleh hukum.

	Transaksional	Pemasaran (massal)
Dipicu oleh	Sesuatu yang dilakukan pengguna	Jadwal atau kampanye Anda
Contoh	Konfirmasi pendaftaran, reset kata sandi, magic link, kwitansi, pengingat pemesanan, "seseorang membalas"	Newsletter, pengumuman produk, promosi, kampanye untuk pengguna yang tidak aktif
Penerima	Satu orang dalam satu waktu	Banyak sekaligus
Persetujuan	Tersirat dari tindakan	Perlu izin, dengan cara berhenti langganan yang mudah
Waktu	Harus sampai dalam hitungan detik	Beberapa menit masih wajar
Dikirim dari mana	Aplikasi Anda, melalui API	Alat newsletter atau fitur siaran penyedia

Pisahkan keduanya. Jika kampanye pemasaran mendapat keluhan spam, Anda tidak ingin reset kata sandi dari aliran yang sama ikut terdampak. Pendekatan yang umum adalah subdomain terpisah, misalnya mail.example.com untuk email akun dan news.example.com untuk newsletter, dan beberapa penyedia memisahkan keduanya secara internal. Postmark, misalnya, menjelaskan bahwa "message stream" transaksional dan siarannya berjalan di infrastruktur pengiriman yang terpisah, per September 2026.

Memilih penyedia

Aplikasi Anda sebaiknya tidak mengirim email sendiri dari servernya. Penyedia pengiriman menangani infrastruktur, reputasi IP, percobaan ulang, dan pemrosesan bounce. Pilihan yang dikenal antara lain Postmark, Resend, SendGrid, Amazon SES, dan Mailgun; masing-masing menyediakan API HTTP dan akses SMTP. Harga dan paket berubah, jadi bandingkan di situs masing-masing.

Hal yang perlu dibandingkan:

Fokus. Sebagian penyedia berfokus pada email transaksional; yang lain menggabungkan transaksional dan pemasaran.
Pengalaman developer. API yang jelas, library resmi untuk bahasa Anda, dan log yang berguna untuk melihat apakah setiap pesan terkirim, bounce, atau ditandai spam.
Webhook untuk bounce, keluhan, dan pengiriman berhasil, agar aplikasi Anda bisa bereaksi.
Template, disimpan di penyedia atau di kode Anda sendiri. Menyimpannya di kode membuatnya ter-versi dan bisa diuji.
Wilayah dan penanganan data, jika Anda punya persyaratan tentang di mana data diproses.
Biaya pada volume Anda, termasuk apa yang terjadi saat melampaui paket gratis.

Untuk newsletter ke daftar kontak, alat newsletter atau email marketing khusus sering kali lebih cocok daripada membangun fitur kampanye di dalam aplikasi Anda.

Atur domain pengirim

Kirim dari domain Anda sendiri, misalnya hello@example.com, bukan alamat Gmail atau Outlook. Email dari alamat kotak surat gratis yang dikirim melalui layanan pihak ketiga gagal pemeriksaan autentikasi dan kemungkinan besar difilter.

Pertimbangkan subdomain khusus untuk pengiriman. Resend, misalnya, menyarankan pengiriman dari subdomain seperti updates.example.com untuk mengisolasi reputasi pengirim (per September 2026). Cara ini juga menjaga rekaman DNS email tetap terpisah dari situs utama Anda.

Penyedia kemudian memberi Anda rekaman DNS untuk ditambahkan di tempat pengelolaan DNS domain Anda. Jika DNS masih baru bagi Anda, cara kerja domain dan DNS menjelaskan rekaman-rekaman ini terlebih dahulu.

SPF

SPF (Sender Policy Framework) adalah rekaman TXT yang mencantumkan server mana yang boleh mengirim email untuk domain Anda. Penerima memeriksa apakah server pengirim ada dalam daftar tersebut.

Sebuah domain sebaiknya hanya punya satu rekaman SPF. Jika Anda menambahkan penyedia, gabungkan ke rekaman yang sudah ada, bukan menambahkan rekaman kedua.
SPF mengizinkan paling banyak 10 lookup DNS saat dievaluasi; rantai panjang entri include: bisa melampaui batas itu dan menyebabkan kegagalan.
Banyak penyedia mengatur SPF pada subdomain return-path yang mereka minta Anda buat, sehingga Anda mungkin sama sekali tidak perlu menyentuh rekaman SPF utama.

DKIM

DKIM (DomainKeys Identified Mail) menambahkan tanda tangan kriptografis pada setiap pesan. Penyedia menandatangani dengan kunci privat; Anda mempublikasikan kunci publik yang cocok sebagai rekaman DNS (TXT atau CNAME, tergantung penyedia). Penerima memeriksa tanda tangan itu untuk memastikan pesan berasal dari pengirim yang sah dan tidak diubah di perjalanan.

Langkah "verify domain" dari penyedia Anda sebagian besar berkaitan dengan DKIM. Jangan dilewati.

DMARC

DMARC menghubungkan SPF dan DKIM. Ini adalah rekaman TXT di _dmarc.yourdomain.com yang memberi tahu penerima:

Keselarasan (alignment): domain pada alamat From yang terlihat harus cocok dengan domain yang lolos SPF atau DKIM.
Kebijakan: apa yang harus dilakukan terhadap email yang gagal: p=none (hanya laporan), p=quarantine (dianggap mencurigakan, sering kali spam), atau p=reject.
Laporan: ke alamat mana laporan agregat dikirim (rua=), sehingga Anda bisa melihat siapa yang mengirim atas nama domain Anda.

Jalur yang masuk akal adalah memulai dengan p=none dan alamat laporan, memastikan email sah Anda lolos, lalu naik ke quarantine dan akhirnya reject. Kebijakan yang ketat juga jauh lebih menyulitkan orang lain memalsukan domain Anda.

Yang diwajibkan Gmail

Per September 2026, pedoman pengirim Google menyatakan:

Semua pengirim ke akun Gmail pribadi perlu SPF atau DKIM, DNS balik dan maju yang valid untuk server pengirim, TLS, dan tingkat spam di Postmaster Tools di bawah 0,3%.
Pengirim massal (lebih dari 5.000 pesan per hari ke Gmail) perlu SPF dan DKIM, rekaman DMARC (kebijakan p=none diizinkan), keselarasan domain From, serta berhenti langganan satu klik dan tautan berhenti langganan yang terlihat pada email pemasaran dan email berlangganan.

Penyedia Anda menangani bagian sisi server. Rekaman DNS dan penanganan berhenti langganan adalah tanggung jawab Anda. Meskipun Anda jauh di bawah 5.000 per hari, memenuhi aturan pengirim massal adalah cara termudah agar aman.

Bangun pengiriman email ke dalam aplikasi

Setelah domain terverifikasi:

Simpan kunci API sebagai rahasia sisi server, jangan pernah di kode front-end. Lihat apa itu environment variable dan secret.
Kirim dari server, setelah tindakan yang memicu email berhasil.
Jangan membuat pengguna menunggu email. Untuk aplikasi yang lebih dari sekadar sederhana, antrekan pengiriman dan coba ulang saat terjadi kegagalan sementara, agar respons penyedia yang lambat tidak memperlambat pendaftaran.
Catat hasilnya, yaitu ID pesan dan status dari penyedia, tanpa mencatat kunci atau isi pesan lengkap yang berisi data pribadi.
Tangani webhook untuk bounce dan keluhan. Berhenti mengirim ke alamat yang mengalami hard bounce atau menandai Anda sebagai spam.

Berikut prompt dasar yang mencakup kebutuhan utamanya:

Kirim email transaksional dengan [PROVIDER] menggunakan secret server [ENV_NAME], dari "Acme hello@mail.acme.com". Kirim email sambutan setelah pendaftaran dan konfirmasi pemesanan setelah pemesanan disimpan. Simpan template di kode, dengan versi teks biasa di samping HTML. Antrekan pengiriman dan coba ulang kegagalan sementara hingga tiga kali. Catat kegagalan beserta error dari penyedia tetapi jangan pernah mencatat kunci API. Tambahkan endpoint webhook yang menandai alamat sebagai tidak dapat dikirimi saat terjadi hard bounce dan keluhan, lalu lewati alamat tersebut di pengiriman berikutnya.

Email akun, seperti tautan verifikasi, magic link, dan reset kata sandi, adalah bagian dari login. Cara menambahkan login ke aplikasi Anda menjelaskan bagaimana alur-alur itu saling terkait; buat tautan ini sekali pakai dan berumur pendek.

Kebiasaan agar deliverability terjaga

Autentikasi membuat email Anda dipertimbangkan. Perilaku Anda membuatnya tetap di kotak masuk.

Kirim hanya yang diharapkan orang. Pendaftar yang sudah dikonfirmasi, opt-in yang jelas untuk pemasaran, dan tanpa membeli daftar.
Buat berhenti berlangganan itu mudah untuk apa pun yang tidak sepenuhnya transaksional, dan patuhi segera.
Lakukan pemanasan untuk domain baru. Domain yang baru dan langsung mengirim ribuan pesan di hari pertama terlihat mencurigakan. Mulailah dengan email transaksional dan naikkan volume secara bertahap.
Jaga daftar tetap bersih. Hapus hard bounce segera dan pertimbangkan menghapus orang yang sudah lama tidak membuka apa pun.
Tulis seperti manusia. Subjek yang jelas, nama From yang dikenali, bagian teks biasa, sedikit gambar, dan tautan ke domain Anda sendiri. Hindari pemendek tautan.
Pantau. Daftarkan domain Anda di Google Postmaster Tools dan baca laporan DMARC secara berkala.
Gunakan balasan (reply-to) yang nyata dan benar-benar dibaca seseorang. Balasan adalah sinyal yang baik, sekaligus umpan balik yang berguna.

Menguji tanpa mengirim spam ke siapa pun

Gunakan mode test atau sandbox dari penyedia jika tersedia, atau kirim ke alamat yang Anda miliki.
Di lingkungan pengembangan, kirim ke kotak uji catch-all alih-alih pengguna sungguhan; database seed yang penuh alamat yang terlihat nyata adalah cara mudah untuk tanpa sengaja mengirim email ke orang asing.
Periksa setiap template di beberapa klien: Gmail di web, aplikasi email di ponsel, Outlook, dan dalam mode gelap.
Lihat header pesan dari email uji: header menunjukkan apakah SPF, DKIM, dan DMARC lolos.

Dasar hukum

Aturan berbeda di tiap negara. Secara umum, email pemasaran memerlukan persetujuan di banyak tempat, harus mengidentifikasi pengirim, dan harus menyediakan cara berhenti berlangganan yang berfungsi; email transaksional diperlakukan berbeda, tetapi tidak boleh dipakai untuk menyelipkan pemasaran. Jika Anda mengumpulkan alamat dari halaman waitlist, jelaskan apa yang akan Anda kirim dan simpan, serta kapan dan bagaimana setiap orang mendaftar. Jika ragu, periksa aturan di wilayah tempat pengguna Anda berada.

Daftar periksa email

Penyedia pengiriman sudah dipilih; kunci API disimpan sebagai secret server
Mengirim dari domain atau subdomain Anda sendiri, bukan kotak surat gratis
Rekaman SPF, DKIM, dan DMARC sudah ditambahkan dan lolos
Email transaksional dan pemasaran sudah dipisah
Pengiriman diantrekan dan dicoba ulang; hasilnya dicatat
Webhook bounce dan keluhan sudah ditangani
Berhenti berlangganan tersedia untuk email non-transaksional, dan dipatuhi segera
Template sudah diuji di beberapa klien; email uji tidak pernah sampai ke pengguna sungguhan

Mengirim email dari aplikasi Mythex

Mythex tidak menyertakan layanan pengiriman email bawaan untuk aplikasi yang Anda bangun, jadi Anda membawa penyedia sendiri, misalnya Resend, SendGrid, atau Postmark. Simpan kunci API-nya sebagai secret project; agen dapat memintanya melalui kartu secret di chat, lalu minta email yang Anda butuhkan dengan kata-kata biasa. Dokumentasi memiliki prompt awal di mengirim email dari aplikasi Anda. Jika Anda membeli domain melalui Mythex di paket Pro, Anda bisa menambahkan rekaman TXT dan CNAME dari penyedia di pengaturan DNS domain; lihat domain kustom.

Pertanyaan

Apa perbedaan email transaksional dan email pemasaran?

Email transaksional dipicu oleh sesuatu yang dilakukan pengguna dan memang diharapkan, misalnya reset kata sandi, kwitansi, atau konfirmasi pemesanan. Email pemasaran dikirim ke banyak orang sesuai jadwal Anda, seperti newsletter dan pengumuman. Keduanya punya aturan persetujuan yang berbeda dan sebaiknya dikirim dari aliran atau subdomain yang terpisah.

Mengapa email aplikasi saya masuk ke spam?

Penyebab yang umum adalah domain pengirim yang belum diatur SPF, DKIM, dan DMARC, mengirim dari alamat gratis seperti Gmail melalui layanan pihak ketiga, domain baru yang belum punya reputasi, atau isi dan tautan yang terlihat seperti spam. Perbaiki autentikasi terlebih dahulu, lalu periksa isi dan volume.

Bisakah saya mengirim email aplikasi dari akun Gmail saya?

Mungkin untuk beberapa pesan uji pribadi, tetapi tidak untuk aplikasi sungguhan. Gunakan penyedia pengiriman email dengan domain Anda sendiri, atur rekaman DNS yang diberikan penyedia, lalu kirim dari alamat di domain tersebut.

Apakah saya perlu DMARC?

Dalam praktiknya, ya. Per September 2026, Google mewajibkan DMARC bagi siapa pun yang mengirim lebih dari 5.000 pesan per hari ke alamat Gmail, dan rekaman DMARC juga melindungi domain Anda dari pemalsuan. Memulai dengan kebijakan p=none tidak masalah selama Anda masih memeriksa laporannya.