Email dari domain Anda sendiri

Bot Anda dapat mengirim email kepada pelanggan Anda dari alamat di domain Anda sendiri, misalnya noreply@example.com. Namun pesannya dikirim oleh server kami. Karena itu, sebelum pengiriman pertama Anda perlu menambahkan tiga rekaman ke DNS domain Anda satu kali. Berikut: mengapa ini perlu, apa persisnya yang ditambahkan, dan apa yang terjadi setelahnya.

Mengapa tanpa rekaman DNS email tidak sampai

Lihat dari sisi penerima — Gmail, Outlook, atau server email pelanggan Anda. Datang sebuah pesan yang mengaku berasal dari domain Anda, tetapi tiba dari server yang bukan milik domain Anda. Itu persis rupa sebuah pemalsuan: begitulah phishing bekerja.

Satu-satunya cara penerima membedakan keduanya adalah bertanya kepada domain itu sendiri: «apakah pengirim ini benar-benar bertindak atas nama Anda?» Jawabannya Anda terbitkan di DNS domain Anda, karena DNS adalah satu-satunya tempat yang hanya Anda kuasai — dan karenanya satu-satunya yang dipercaya penerima.

Selama jawaban itu tidak ada, server email yang benar wajib menganggap pesan itu mencurigakan. Paling baik masuk ke Spam; paling buruk ditolak dan penerima tidak pernah tahu pesan itu ada.

Jadi ketiga rekaman di bawah bukan formalitas dan bukan kotak centang di antarmuka. Itulah izin Anda.

Tiga rekaman dan fungsi masing-masing

DKIM — tanda tangan yang membuktikan keaslian

DKIM adalah tanda tangan kriptografis pada setiap pesan keluar. Platform membuat sepasang kunci untuk domain Anda: kunci privat tetap pada kami dan menandatangani pesan, kunci publik Anda terbitkan di DNS. Penerima mengambil kunci publik dari DNS Anda dan memeriksa tanda tangannya. Jika cocok, pesan dikirim oleh pemegang kunci privat dan isinya tidak diubah di perjalanan.

Tanpa DKIM: tidak ada yang bisa dipakai memeriksa tanda tangan. Pesan tampak tak bertanda tangan dan tak dipercaya, dan tak ada pengaturan lain yang menutupinya. DKIM adalah yang terpenting dari ketiganya.

SPF — server mana yang boleh mengirim atas nama Anda

SPF menjawab pertanyaan lain: dari server mana saja email untuk domain ini dapat diterima. Ini daftar sumber — server email hosting Anda, layanan pengiriman yang sudah Anda pakai, dan, agar bot bisa menulis, server pengirim kami.

Tanpa SPF: pesan datang dari server yang tidak dikenali domain Anda. Bagi penyaring, itu tanda pemalsuan yang klasik dan menambah semua kecurigaan lain.

DMARC — apa yang harus dilakukan penerima bila pemeriksaan gagal

DKIM dan SPF menjawab «apakah pesan ini asli». DMARC menjawab pertanyaan berikutnya: apa yang dilakukan bila tidak. Ini instruksi Anda kepada penerima — tidak melakukan apa-apa dan hanya melaporkan, memasukkan ke spam, atau menolak. DMARC juga alamat tujuan laporan gabungan dari penerima tentang email atas nama Anda, termasuk upaya pemalsuan oleh pihak lain.

Mulailah dengan kebijakan paling lunak, «hanya laporan». Perketat nanti, setelah Anda yakin semua pengirim sah Anda (keuangan, CRM, buletin, bot ini) lolos pemeriksaan. Kebijakan ketat yang dinyalakan terlalu dini mulai memakan email Anda sendiri.

Tanpa DMARC: setiap penerima memutuskan sendiri, dan Anda tidak pernah tahu apa yang terjadi pada email atas nama Anda.

Rekaman apa yang ditambahkan

Daftarkan dulu domainnya di panel: bagian Email → «Sending domains» → tombol «Add domain». Dialognya punya tiga isian: domain itu sendiri (misalnya shop.example.com), bagian lokal alamat (yang sebelum @, biasanya noreply), dan nama pengirim yang dilihat penerima menggantikan alamat. Setelah disimpan, rekaman DNS Anda muncul di layar.

Ketiganya rekaman TXT di DNS domain Anda. Ditambahkan di tempat Anda mengelola domain: panel registrar atau penyedia DNS.

Nilai di bawah memakai example.com sebagai contoh — ganti dengan milik Anda. Nilai persis untuk domain Anda ditampilkan pada kartu domain di panel; salin dari sana, terutama DKIM: nilainya memuat kunci publik Anda sendiri, berbeda untuk tiap domain dan tidak bisa diambil dari dokumentasi.

Di layar tiap rekaman dipecah menjadi dua isian terpisah — «Host» dan «Value» — masing-masing dengan tombol «Copy» sendiri. Salin satu per satu ke isian yang sesuai di penyedia DNS Anda: kedua bagian itu tidak bisa ditempel sekaligus.

Dua hal yang paling sering menjegal:

• Banyak panel menambahkan domain ke nama rekaman secara otomatis. Jika kolom nama sudah menampilkan «.example.com», isi hanya mybot._domainkey, bukan nama lengkap; kalau tidak, hasilnya mybot._domainkey.example.com.example.com.
• Nilai DKIM panjang dan tidak boleh mengandung pemenggalan baris atau spasi di dalam kunci. Salin dengan tombol, bukan dengan menyeret tetikus.

Jika domain sudah punya rekaman SPF

Sebuah domain hanya boleh punya satu rekaman SPF. Jika Anda sudah mengirim email lewat hosting, CRM, atau layanan buletin lain, rekaman itu sudah ada. Jangan tambahkan yang kedua — sisipkan satu include lagi ke rekaman yang ada, sebelum ~all di akhir:

v=spf1 include:spf.penyediaanda.co.id include:esp.getmybot.dev ~all

Dua rekaman SPF pada satu domain adalah kesalahan yang sama dengan tidak punya sama sekali: pemeriksaan gagal, karena penerima tidak tahu harus percaya yang mana.

Perhatikan: «tercakup» lewat rekaman orang lain tidaklah cukup. Sekalipun penyedia Anda sekarang memuat kami dalam SPF mereka, include kami harus berada langsung di rekaman Anda — alasannya ada di bawah, pada bagian verifikasi domain.

Mengapa include, bukan alamat IP

Kesalahan paling sering adalah menempelkan alamat IP yang terlihat di header pesan atau di sebuah forum. Jangan lakukan itu.

include:esp.getmybot.dev adalah penunjuk ke daftar server pengirim milik kami yang kami pelihara sendiri. Hari ini nama itu mengarah ke satu relai. Besok jumlahnya bisa bertambah, bisa pindah, bisa diganti. Saat itu terjadi kami memperbarui daftarnya di sisi kami dan rekaman Anda terus bekerja tanpa Anda ubah sama sekali. Itulah intinya: alamat berubah di satu tempat, bukan di DNS setiap pelanggan.

Alamat IP yang ditulis manual justru berhenti benar pada saat itu. Email mulai gagal SPF tanpa peringatan apa pun — tidak ada galat di panel, tidak ada notifikasi. Anda tahu dari pelanggan yang «tidak menerima apa-apa».

Tulis persis include:esp.getmybot.dev dan jangan tambahkan apa pun.

Verifikasi domain

Verifikasi domain adalah platform sendiri melihat DNS domain Anda dan memastikan ketiga rekaman beres. Jika ketiganya lulus, domain menjadi terverifikasi dan pengiriman diizinkan. Selama satu saja gagal, domain tetap menunggu.

Yang diperiksa lebih dari sekadar «rekamannya ada»:

Mengapa DMARC diperiksa lebih longgar: ia memberi tahu penerima apa yang harus dilakukan dengan hasil DKIM dan SPF, tetapi tidak memberi kami hak mengirim atas nama Anda. Hak itu datang dari dua rekaman pertama saja, dan keduanya diperiksa isinya secara penuh.

Include milik orang lain tidak dihitung

include:esp.getmybot.dev harus berada di rekaman SPF Anda sendiri. Jika SPF Anda memuat penyedia pihak ketiga yang rekamannya memuat kami, verifikasi tidak menerimanya: platform tidak menelusuri rantai include milik orang lain. Alasannya sederhana — dengan begitu jawaban atas «apakah domain ini yang memberi kami izin» tetap tegas.

Praktisnya: sekalipun Anda yakin sudah «tercakup lewat penyedia», tambahkan include kami langsung ke rekaman Anda sendiri. Hal yang sama tertulis di layarnya sendiri, pada penjelasan rekaman SPF: kalau domain sudah punya rekaman SPF, tambahkan nilai include:... ke dalamnya alih-alih mengganti seluruh rekaman, sebab domain bisa saja mengirim surat lewat jalur lain juga. Catatan itu selalu tampil, bukan muncul hanya setelah pemeriksaan gagal.

DNS tidak diperbarui seketika. Setelah disimpan di registrar, rekaman harus menyebar ke server nama: biasanya menit, kadang jam, sesekali sampai sehari. Bergantung pada penyedia dan TTL. Ini wajar dan di luar kendali kami.

Meski begitu Anda tidak perlu menunggu pasif. Platform memeriksa ulang domain yang menunggu sekali sejam, tetapi di kartu domain ada tombol «Verify now» — pemeriksaan yang sama, dijalankan segera, dengan hasil langsung di layar. Gunakan tepat setelah menyimpan rekaman: kalau ada salah ketik, Anda tahu dalam sedetik, bukan sejam. Bisa diulang sesering yang Anda mau.

Status domain terlihat di kartu: «Pending verification», «Verified», atau «Not verified». Selama belum terverifikasi, kartu juga memuat peringatan «Sending from this domain is disabled until it is verified.»

Hasilnya bukan sekadar «gagal». Ketiga rekaman punya statusnya masing-masing di layar — «Passing», «Not passing», atau «Not checked yet» — dan barisnya sendiri yang menjelaskan apa yang salah.

Untuk SPF layar membedakan dua situasi, dan inilah pembedaan yang paling penting dalam seluruh alur:

• Domain sama sekali tidak punya rekaman SPF. Terbitkan satu, dengan nilai dari tabel di atas.
• Rekaman SPF ada tetapi tidak memuat include kami. Tambahkan include ke rekaman yang sudah ada: jangan membuat yang kedua dan jangan menggantinya seluruhnya. Pesan yang sama juga secara eksplisit mencakup kasus berantai: kalau include hanya sampai ke kami lewat rekaman SPF penyedia lain, itu tidak dihitung — rantai tidak ditelusuri.

Kasus kedua adalah momen paling membingungkan dalam seluruh alur: rekamannya sudah ada, Anda baru saja membacanya sendiri, dan verifikasi tetap menolak. Pesan galat kini menyatakan persis sama dengan catatan yang selalu tampil di sebelah rekaman: tambahkan include kami ke apa yang sudah Anda punya.

Jika verifikasi tidak lolos:

1. Baca rekaman mana dari ketiganya yang bertanda «Not passing» dan apa isi penjelasannya, lalu ikuti itu.
2. Pastikan rekaman benar-benar terbit — banyak panel menuntut «terapkan perubahan» terpisah.
3. Periksa nama rekaman dari domain ganda (lihat di atas).
4. Periksa bahwa rekaman SPF hanya satu dan include kami berada di dalam rekaman itu sendiri.
5. Tunggu sebentar dan periksa lagi: perubahan mungkin belum menyebar.

Sebelum terverifikasi, pengiriman menolak bekerja

Selama domain belum terverifikasi, email tidak dikirim. Bukan «dikirim lalu masuk spam» — tidak keluar sama sekali: percobaan gagal dengan galat domain belum terverifikasi, terlihat di jurnal.

Ini disengaja dan bukan kerusakan. Email dari domain yang belum menjamin dirinya sendiri berubah menjadi keluhan spam, dan keluhan merusak reputasi infrastruktur pengiriman yang dipakai bersama oleh semua pelanggan platform. Tidak mengirim satu pesan lebih murah daripada mengirimnya lalu setengah tahun keluar dari daftar blokir. Karena itu larangan, bukan peringatan.

Jika Anda melihat galat ini, periksa rekaman DNS dan jalankan pemeriksaan sebelum menulis ke dukungan. Pada mayoritas kasus penyebabnya salah ketik pada nama rekaman.

Berhenti berlangganan, keluhan, dan kegagalan pengiriman

Tiga aturan yang mengejutkan bila tidak diketahui lebih dulu.

Setiap pesan pemasaran memuat berhenti berlangganan sekali klik. Platform sendiri menambahkan tautan berhenti berlangganan di kaki pesan serta header teknis yang dipakai klien email untuk menggambar tombol «Berhenti berlangganan» di sebelah alamat pengirim. Ini tidak bisa dihilangkan — baik lewat pengaturan maupun tata letak pesan. Berhenti berlangganan berlaku seketika, tanpa membuka pesan dan tanpa langkah konfirmasi. Gmail dan penyedia besar lain mensyaratkannya bagi pengirim massal: pesan tanpa itu pasti masuk spam.

Berhenti berlangganan bersifat final dan tidak bisa dibatalkan dari antarmuka. Alamat yang berhenti tidak menerima email lagi dari bot ini. Tidak ada tombol «pulihkan» dan tidak ada jalan pintas lewat impor ulang daftar: keputusan itu tidak pernah dibatalkan di atas kepala orangnya. Ia hanya bisa kembali sendiri — dengan mendaftar lagi lewat formulir langganan Anda.

Ada kasus yang lebih keras lagi: jika seseorang menekan «Ini spam» di klien emailnya, alamat itu ditutup selamanya. Pendaftaran baru lewat formulir Anda pun tidak membukanya — karena kami sudah tahu bagaimana percobaan sebelumnya berakhir, dan menulis ke alamat semacam itu paling cepat menghancurkan reputasi domain. Alamat yang ditutup manual atas permintaan hukum berperilaku sama.

Kegagalan permanen menutup alamat selamanya. Jika server penerima menjawab bahwa kotak surat itu tidak ada, alamat ditandai tak terkirim dan dikeluarkan dari pengiriman berikutnya. Ini bukan keadaan sementara: terus mengetuk kotak yang tak ada adalah jalan tercepat menuju penyaring spam, bersama semua alamat lain.

Kegagalan sementara (kotak penuh, server sedang tak tersedia) tidak menutup alamat — pengiriman berlanjut.

Mengapa angka pembukaan lebih rendah dari kenyataan

Statistik email memuat angka pembukaan, dan angka itu selalu lebih rendah dari kenyataan. Ini bukan galat penghitungan, melainkan cara pembukaan diukur.

Pembukaan tercatat ketika klien email memuat gambar pelacak mungil dari server saat menampilkan pesan. Klien modern secara bawaan tidak memuat gambar jarak jauh; dan yang memuatnya (Apple Mail dan fitur privasi serupa) melakukannya lebih dulu untuk semua orang, termasuk yang tidak pernah membuka pesan. Pada kasus pertama pembukaan hilang; pada kasus kedua dikreditkan kepada orang yang tidak ada. Tidak ada cara menghitung pembukaan lebih tepat — tidak bagi kami maupun siapa pun.

Karena itu antarmuka mencantumkan catatan di samping angka: itu batas bawah, bukan angka pasti. Pakailah untuk membandingkan pesan satu sama lain, di mana distorsi yang sama berlaku bagi semuanya, tetapi bukan sebagai jawaban atas «berapa orang membaca pesan ini».

Jika Anda butuh metrik keterlibatan yang andal, lihat «Link clicks». Klik pada tautan adalah tindakan nyata orang nyata; tak ada yang melakukannya lebih dulu untuknya. «Delivered», «Unsubscribes», «Complaints», dan «Bounces» juga dihitung tepat: itu dilaporkan server email, bukan gambar di dalam pesan. Semuanya ada di blok «Sending stats» pada layar Email yang sama.

Selanjutnya

• Saluran — multikanal dan kemampuan tiap saluran.
• Siaran — pengiriman massal.
• Analitik — di mana melihat angkanya.