# Email transaksional: pengertian dan cara mengirimnya

URL kanonis: https://brew.new/id/blog/transactional-emails
Penulis: Thomas Park
Dipublikasikan: 2026-08-22
Diperbarui: 2026-09-28

Email transaksional memberikan informasi tentang suatu transaksi atau hubungan: bukti pembayaran, reset kata sandi yang diminta, pembaruan status pengiriman, atau pemberitahuan keamanan akun. Tujuannya berbeda dari kampanye yang mengajak seseorang untuk membeli atau kembali.

Perbedaannya bergantung pada isi pesan. Menandai sebuah email sebagai “transaksional” di alat pengiriman tidak menentukan status hukumnya.

## Terapkan uji tujuan utama

[Panduan CAN-SPAM dari FTC](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) menjelaskan kategori yang sempit untuk pesan transaksional dan pesan hubungan. Untuk konten yang mencampurkan unsur komersial dan transaksional, panduan ini mempertimbangkan apa yang akan dipahami oleh penerima yang wajar dari subjek email dan di mana informasi transaksional ditempatkan.

Subjek yang bersifat promosi bisa membuat pesan campuran tergolong komersial. Footer promosi yang singkat tidak otomatis berdampak demikian: FTC memberikan contoh laporan rekening yang tujuan utamanya tetap transaksional. Yang menentukan adalah [aturan](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-316/section-316.3) tersebut dan isi pesan yang sebenarnya.

Pastikan informasi penting tetap menonjol. Jika promosi mengalihkan perhatian dari bukti pembayaran atau pemberitahuan keamanan, email pemasaran yang terpisah biasanya menjadi pilihan editorial yang lebih jelas. Ini adalah panduan yang berlaku di AS; tinjau persyaratan yang berlaku untuk penerima dan bisnis Anda. Sumber ditinjau pada 28 September 2026.

## Beberapa kasus umum

| Pesan | Tujuan yang umum | Yang perlu ditinjau |
| --- | --- | --- |
| Bukti pembelian atau pemberitahuan pengembalian dana | Transaksional | Informasi pesanan yang akurat dan penerima yang tepat |
| Reset kata sandi yang diminta | Keamanan akun | Permintaan yang asli, tautan yang valid, dan tidak ada penawaran yang mengalihkan perhatian |
| Pembaruan status pengiriman | Transaksional | Informasi tentang pesanan yang sudah ada |
| Pengingat keranjang yang ditinggalkan | Pemasaran | Izin, status keranjang saat ini, dan perilaku berhenti berlangganan |
| Tawaran upgrade saat masa uji coba akan berakhir | Pemasaran | Penawaran yang sebenarnya dan apakah penerima masih memenuhi syarat |

Pemberitahuan status akun dan tawaran upgrade bisa menyangkut masa uji coba yang sama, tetapi melayani tujuan yang berbeda. Tinjau tindakan apa yang diminta email itu dari pembacanya.

## Aturan penyedia tetap berlaku

[Pedoman Gmail](https://support.google.com/mail/answer/81126) membedakan persyaratan berhenti berlangganan sekali klik untuk email pemasaran dan email langganan dari pesan transaksional. Autentikasi dan reputasi tetap penting untuk keduanya.

[Yahoo](https://senders.yahooinc.com/best-practices/) menyarankan agar email pemasaran massal dipisahkan dari email transaksional berdasarkan IP dan, jika sesuai, berdasarkan domain. Ikuti penyiapan dari penyedia Anda, alih-alih berasumsi bahwa subdomain baru saja sudah cukup untuk membangun reputasi yang terpisah.

Untuk email pemasaran, [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html) mendefinisikan mekanisme header sekali klik. Tautan di footer dan berhenti berlangganan berbasis header memiliki peran yang berbeda. Uji perilakunya pada pesan yang sudah diterima.

## Kirim peristiwa transaksi lewat Brew

Untuk alur kerja ini, Brew memakai otomatisasi yang sudah dipublikasikan beserta pemicunya. Konfigurasikan domain pengirim terverifikasi dengan tujuan pengiriman yang sesuai, deklarasikan payload pemicu, lalu buat langkah kirim email yang memakai domain tersebut. Pengaturan domain mengendalikan perilaku pengiriman Brew; pengaturan ini tidak membuat konten promosi menjadi transaksional secara hukum.

Setelah otomatisasi diuji dan dipublikasikan, backend Anda menjalankan pemicunya. Contoh ini mengasumsikan pemicu tersebut mendeklarasikan `order_id` dan `ship_date`:

```bash
curl --fail-with-body \
  "https://brew.new/api/v1/automations/triggers/${BREW_ORDER_TRIGGER_ID}/fire" \
  -H "Authorization: Bearer ${BREW_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-1234-shipped" \
  -d '{"payload":{"email":"ada@example.com","order_id":"1234","ship_date":"Tuesday"}}'
```

Gunakan ID pemicu yang sebenarnya dan kunci idempotensi yang stabil untuk peristiwa tersebut. Email dapat membaca field payload yang dideklarasikan dengan sintaks seperti `{{ trigger.order_id }}`. Periksa [dokumentasi merge tag](https://docs.brew.new/create-emails/merge-tags) dan uji nilai yang kosong.

Periksa eksekusinya dan email yang diterima. Uji perilaku percobaan ulang dan pastikan status berhenti berlangganan dari email pemasaran ditangani sesuai tujuan pengiriman. Perlindungan lain, termasuk pengecualian pengiriman, tetap berlaku; pengaturan transaksional bukan janji bahwa email akan terkirim ke setiap alamat.

[Panduan otomatisasi](/id/blog/email-marketing-automation-guide) membahas publikasi dan pemeriksaan status. Jika asisten AI yang menyusun templatnya, [peninjauan pengiriman](/id/blog/agent-email-deliverability) yang sama tetap berlaku.