Cara Hantar E-mel dari Aplikasi Anda (dan Masuk ke Peti Masuk)

Untuk menghantar e-mel dari aplikasi anda dengan boleh dipercayai, gunakan pembekal penghantaran e-mel dan bukannya peti mel anda sendiri, hantar dari alamat pada domain anda sendiri, dan tambah rekod DNS yang diberikan pembekal supaya SPF, DKIM dan DMARC semuanya lulus. Asingkan e-mel transaksi — tetapan semula kata laluan, resit, pengesahan — daripada e-mel pemasaran, hantar setiap jenis hanya kepada orang yang menjangkakannya, dan urus mesej yang melantun serta permintaan nyahlanggan. Betulkan pengesahan dahulu; ia adalah punca paling biasa e-mel aplikasi masuk ke spam.

E-mel transaksi lawan pemasaran

Kedua-dua jenis e-mel ini kelihatan serupa dalam kod tetapi dilayan dengan sangat berbeza oleh penyedia peti masuk dan oleh undang-undang.

	Transaksi	Pemasaran (pukal)
Dicetuskan oleh	Sesuatu yang dilakukan pengguna	Jadual atau kempen anda
Contoh	Pengesahan pendaftaran, tetapan semula kata laluan, pautan ajaib, resit, peringatan tempahan, "seseorang telah membalas"	Surat berita, pengumuman produk, promosi, pengaktifan semula
Penerima	Seorang demi seorang	Ramai sekaligus
Persetujuan	Tersirat daripada tindakan	Perlu kebenaran, dengan nyahlanggan yang mudah
Masa	Mesti sampai dalam beberapa saat	Beberapa minit tidak mengapa
Dari mana dihantar	Aplikasi anda, melalui API	Alat surat berita atau ciri siaran pembekal

Asingkannya. Jika kempen pemasaran menerima aduan spam, anda tidak mahu tetapan semula kata laluan dari strim yang sama turut terjejas. Pendekatan biasa ialah subdomain berasingan — contohnya mail.example.com untuk e-mel akaun dan news.example.com untuk surat berita — dan sesetengah pembekal mengasingkan kedua-duanya secara dalaman. Postmark, sebagai contoh, menerangkan strim mesej transaksi dan siaran mereka sebagai berjalan pada infrastruktur penghantaran yang berasingan, mulai September 2026.

Memilih pembekal

Aplikasi anda tidak sepatutnya menghantar e-mel sendiri dari pelayannya sendiri. Pembekal penghantaran mengendalikan infrastruktur, reputasi IP, percubaan semula dan pemprosesan lantunan. Pilihan terkenal termasuk Postmark, Resend, SendGrid, Amazon SES dan Mailgun; setiap satunya mempunyai API HTTP dan akses SMTP, dan harga serta pelan sentiasa berubah, jadi bandingkan di laman web masing-masing.

Perkara yang perlu dibandingkan:

Fokus. Sesetengah pembekal menumpukan pada e-mel transaksi; yang lain menggabungkan transaksi dan pemasaran.
Pengalaman pembangun. API yang jelas, pustaka rasmi untuk bahasa anda, log yang berguna yang menunjukkan sama ada setiap mesej dihantar, melantun atau ditandakan sebagai spam.
Webhook untuk lantunan, aduan dan penghantaran, supaya aplikasi anda boleh bertindak balas.
Templat — disimpan dengan pembekal, atau dalam kod anda sendiri. Menyimpannya dalam kod menjadikannya berversi dan boleh diuji.
Wilayah dan pengendalian data, jika anda mempunyai keperluan tentang tempat data diproses.
Kos pada jumlah anda, termasuk apa yang berlaku apabila anda melebihi tahap percuma.

Untuk surat berita kepada senarai, alat surat berita atau pemasaran e-mel khusus selalunya lebih sesuai berbanding membina ciri kempen dalam aplikasi anda.

Sediakan domain penghantaran anda

Hantar dari domain anda sendiri — hello@example.com, bukan alamat Gmail atau Outlook. E-mel dari alamat peti mel percuma yang dihantar melalui perkhidmatan pihak ketiga gagal pemeriksaan pengesahan dan berkemungkinan besar akan ditapis.

Pertimbangkan subdomain khas untuk penghantaran. Resend, sebagai contoh, mengesyorkan penghantaran dari subdomain seperti updates.example.com untuk mengasingkan reputasi penghantaran (mulai September 2026). Ia juga memastikan rekod DNS e-mel anda berasingan daripada laman utama anda.

Pembekal kemudian memberikan rekod DNS untuk anda tambah di tempat DNS domain anda diuruskan. Jika DNS masih baharu bagi anda, cara domain dan DNS berfungsi menerangkan rekod dahulu.

SPF

SPF (Sender Policy Framework) ialah rekod TXT yang menyenaraikan pelayan mana yang dibenarkan menghantar e-mel untuk domain anda. Penerima menyemak sama ada pelayan penghantar berada dalam senarai.

Sesuatu domain sepatutnya hanya mempunyai satu rekod SPF. Jika anda menambah pembekal, gabungkannya ke dalam rekod sedia ada dan bukannya menambah rekod kedua.
SPF membenarkan paling banyak 10 carian DNS semasa penilaian; rantaian entri include: yang panjang boleh melebihi had itu dan menyebabkan kegagalan.
Kebanyakan pembekal menetapkan SPF pada subdomain laluan balik yang mereka minta anda cipta, jadi anda mungkin tidak perlu menyentuh rekod SPF utama anda sama sekali.

DKIM

DKIM (DomainKeys Identified Mail) menambah tandatangan kriptografi kepada setiap mesej. Pembekal menandatangani dengan kunci persendirian; anda menerbitkan kunci awam yang sepadan sebagai rekod DNS (TXT atau CNAME, bergantung pada pembekal). Penerima menyemak tandatangan untuk mengesahkan mesej datang dari penghantar yang dibenarkan dan tidak diubah di tengah jalan.

Langkah "sahkan domain" pembekal anda kebanyakannya berkaitan dengan DKIM. Jangan langkau.

DMARC

DMARC menghubungkan kedua-dua yang lain. Ia ialah rekod TXT di _dmarc.yourdomain.com yang memberitahu penerima:

Penjajaran: domain dalam alamat Dari yang kelihatan mesti sepadan dengan domain yang lulus SPF atau DKIM.
Dasar: apa yang perlu dilakukan terhadap mesej yang gagal — p=none (hanya laporkan), p=quarantine (anggap mencurigakan, selalunya spam) atau p=reject.
Laporan: ke mana laporan agregat dihantar (rua=), supaya anda dapat melihat siapa yang menghantar sebagai domain anda.

Laluan yang munasabah ialah bermula dengan p=none dan alamat laporan, sahkan mel sah anda lulus, kemudian beralih ke quarantine dan akhirnya reject. Dasar yang ketat juga menyukarkan pihak lain memalsukan domain anda.

Apa yang Gmail perlukan

Mulai September 2026, garis panduan penghantar Google menyatakan:

Semua penghantar ke akaun Gmail peribadi memerlukan SPF atau DKIM, DNS hadapan dan belakang yang sah untuk pelayan penghantar, TLS, dan kadar spam di Postmaster Tools di bawah 0.3%.
Penghantar pukal (lebih 5,000 mesej sehari ke Gmail) memerlukan SPF dan DKIM, rekod DMARC (dasar p=none dibenarkan), penjajaran domain Dari, serta nyahlanggan satu klik dan pautan nyahlanggan yang kelihatan pada mesej pemasaran dan mesej langganan.

Pembekal anda mengendalikan bahagian pelayan. Rekod DNS dan pengendalian nyahlanggan adalah tanggungjawab anda. Walaupun anda jauh dari 5,000 sehari, memenuhi peraturan pukal ialah cara paling mudah untuk berada di pihak yang selamat.

Bina penghantaran dalam aplikasi anda

Setelah domain disahkan:

Simpan kunci API sebagai rahsia di bahagian pelayan — jangan sekali-kali dalam kod bahagian hadapan. Lihat apakah itu pembolehubah persekitaran dan rahsia.
Hantar dari pelayan, selepas tindakan yang mencetuskan e-mel itu berjaya.
Jangan biarkan pengguna menunggu e-mel. Untuk apa-apa yang lebih daripada aplikasi paling mudah, beratur penghantaran dan cuba semula apabila ralat sementara berlaku, supaya respons pembekal yang perlahan tidak melambatkan pendaftaran.
Log hasilnya — ID mesej dan status pembekal — tanpa mencatat kunci atau badan mesej penuh yang mengandungi data peribadi.
Urus webhook untuk lantunan dan aduan: berhenti menghantar kepada alamat yang melantun dengan teruk atau menandakan anda sebagai spam.

Arahan yang meliputi asasnya:

Hantar e-mel transaksi dengan [PEMBEKAL] menggunakan rahsia pelayan [NAMA_ENV], dari "Acme hello@mail.acme.com". Hantar e-mel alu-aluan selepas pendaftaran dan pengesahan tempahan selepas tempahan disimpan. Simpan templat dalam kod, dengan versi teks biasa di sebelah HTML. Beratur penghantaran dan cuba semula kegagalan sementara sehingga tiga kali. Log kegagalan dengan ralat pembekal tetapi jangan sekali-kali kunci API. Tambah titik akhir webhook yang menandakan alamat sebagai tidak boleh dihantar pada lantunan keras dan aduan, dan langkau alamat tersebut pada masa hadapan.

E-mel akaun — pautan pengesahan, pautan ajaib dan tetapan semula kata laluan — adalah sebahagian daripada log masuk. Cara menambah log masuk ke aplikasi anda menerangkan bagaimana aliran tersebut berpadu; jadikan pautan ini sekali guna dan berjangka pendek.

Amalan kebolehhantaran

Pengesahan menjadikan e-mel anda dipertimbangkan. Tingkah laku pula memastikan anda kekal di peti masuk.

Hantar hanya apa yang dijangka orang. Pendaftaran yang disahkan, persetujuan jelas untuk pemasaran, tiada senarai yang dibeli.
Permudahkan nyahlanggan pada apa-apa yang tidak sepenuhnya transaksi, dan hormatinya dengan segera.
Panaskan domain baharu. Domain yang baru dibuat yang menghantar beribu mesej pada hari pertama kelihatan mencurigakan. Mulakan dengan mel transaksi anda dan tingkatkan jumlah secara beransur-ansur.
Pastikan senarai bersih. Buang lantunan keras dengan segera dan pertimbangkan untuk membuang orang yang sudah lama tidak membuka apa-apa.
Tulis seperti manusia. Subjek yang jelas, nama Dari yang mudah dikenali, bahagian teks biasa, sedikit imej dan pautan ke domain anda sendiri. Elakkan pemendek pautan.
Pantau. Daftarkan domain anda dalam Google Postmaster Tools dan baca laporan DMARC sekali-sekala.
Gunakan alamat balas yang sebenar yang seseorang baca. Balasan ialah isyarat yang baik dan maklum balas yang berguna.

Menguji tanpa menghantar spam kepada sesiapa

Gunakan mod ujian atau sandbox pembekal anda jika ada, atau hantar kepada alamat yang anda miliki.
Dalam pembangunan, hantar ke peti masuk ujian catch-all dan bukannya pengguna sebenar; pangkalan data yang diisi dengan alamat yang kelihatan sebenar adalah cara mudah untuk menghantar e-mel kepada orang asing secara tidak sengaja.
Semak setiap templat dalam beberapa klien — Gmail di web, aplikasi e-mel telefon, Outlook — dan dalam mod gelap.
Lihat pengepala mesej bagi e-mel ujian: ia menunjukkan sama ada SPF, DKIM dan DMARC lulus.

Asas undang-undang

Peraturan berbeza mengikut negara. Secara umum, e-mel pemasaran memerlukan persetujuan di banyak tempat, mesti mengenal pasti penghantar, dan mesti menawarkan nyahlanggan yang berfungsi; e-mel transaksi dilayan secara berbeza tetapi tidak wajar digunakan untuk menyelitkan pemasaran. Jika anda mengumpul alamat dari halaman senarai menunggu, nyatakan apa yang akan anda hantar dan simpan, bila dan bagaimana setiap orang mendaftar. Jika ragu-ragu, semak peraturan di tempat pengguna anda berada.

Senarai semak e-mel

Pembekal penghantaran dipilih; kunci API disimpan sebagai rahsia pelayan
Menghantar dari domain atau subdomain anda sendiri, bukan peti mel percuma
Rekod SPF, DKIM dan DMARC ditambah dan lulus
E-mel transaksi dan pemasaran diasingkan
Penghantaran diberi giliran dan dicuba semula; hasil dilog
Webhook lantunan dan aduan diurus
Nyahlanggan pada e-mel bukan transaksi, dihormati dengan segera
Templat diuji dalam beberapa klien; e-mel ujian tidak pernah sampai kepada pengguna sebenar

Menghantar e-mel dari aplikasi Mythex

Mythex tidak menyertakan perkhidmatan penghantaran e-mel terbina dalam untuk aplikasi yang anda bina, jadi anda membawa pembekal seperti Resend, SendGrid atau Postmark. Simpan kunci API sebagai rahsia projek — ejen boleh memintanya melalui kad rahsia dalam sembang — dan minta e-mel yang anda perlukan dalam perkataan biasa. Dokumentasi mempunyai arahan permulaan dalam hantar e-mel dari aplikasi anda. Jika anda membeli domain anda melalui Mythex pada Pro, anda boleh menambah rekod TXT dan CNAME pembekal dalam tetapan DNS domain; lihat domain tersuai.

Soalan lazim

Apakah beza antara e-mel transaksi dan e-mel pemasaran?

E-mel transaksi dicetuskan oleh sesuatu yang dilakukan pengguna dan memang dijangka — seperti tetapan semula kata laluan, resit atau pengesahan tempahan. E-mel pemasaran dihantar kepada ramai orang mengikut jadual anda, seperti surat berita dan pengumuman. Kedua-duanya mempunyai peraturan persetujuan yang berbeza dan sebaiknya dihantar dari strim atau subdomain yang berasingan.

Mengapa e-mel aplikasi saya masuk ke spam?

Punca biasanya ialah domain penghantaran tanpa SPF, DKIM dan DMARC yang disediakan, menghantar dari alamat percuma seperti Gmail melalui perkhidmatan pihak ketiga, domain yang baru dibuat tanpa reputasi, atau kandungan dan pautan yang kelihatan seperti spam. Betulkan pengesahan dahulu, kemudian semak kandungan dan jumlah.

Bolehkah saya hantar e-mel aplikasi dari akaun Gmail saya?

Mungkin untuk beberapa mesej ujian peribadi, tetapi tidak untuk aplikasi sebenar. Gunakan pembekal penghantaran e-mel dengan domain anda sendiri, sediakan rekod DNS yang diberikannya, dan hantar dari alamat pada domain tersebut.

Adakah saya perlukan DMARC?

Ya, dalam amalan. Mulai September 2026, Google memerlukan DMARC bagi sesiapa yang menghantar lebih daripada 5,000 mesej sehari ke alamat Gmail, dan rekod DMARC juga melindungi domain anda daripada dipalsukan. Bermula dengan dasar p=none adalah baik semasa anda menyemak laporan.