E-mel laman web masuk spam: lima lapisan yang diperiksa penerima dan cara menyemaknya sendiri

Borang hubungan di laman anda berfungsi dan mesej keluar. Masalahnya mesej itu tiba di folder Spam pelanggan, bukan di peti masuk. Kesannya bukan teknikal tetapi komersial: pelanggan menunggu balasan yang tidak pernah dilihatnya, dan pemilik laman tidak tahu ada mesej yang tersimpan. Dalam kebanyakan kes yang saya periksa, puncanya bukan teks e-mel dan bukan perkataan tertentu dalam subjek. Puncanya ialah identiti penghantar, dan identiti itu ditentukan oleh rekod DNS yang mungkin belum pernah disemak sejak laman dibina.

Penerima besar seperti Gmail, Outlook dan Yahoo menilai mesej sebelum membacanya. Ada beberapa lapisan pemeriksaan dan kebanyakannya mesti lulus. Satu lapisan yang gagal tidak terus menjadikan anda pengirim spam, tetapi tiga atau empat kegagalan bersama menjadikan mesej anda sukar dipercayai. Berikut ialah lapisan itu mengikut urutan penerima memeriksanya, dan cara menyemaknya sendiri.

Satu: reverse DNS dan semakan dua hala

Garis panduan penghantar Google menyatakan alamat IP penghantar mesti mempunyai rekod PTR yang menunjuk kepada satu nama hos, dan nama hos itu mesti mempunyai rekod A atau AAAA yang kembali kepada IP yang sama. Syarat ini terpakai kepada semua penghantar yang menghantar ke akaun Gmail peribadi sejak 1 Februari 2024, bukan hanya penghantar pukal.

Di pelayan laman ini, IP 194.233.74.195 menunjuk kepada mail.thalhah.my dan mail.thalhah.my menunjuk kembali kepada IP yang sama. Kedua-dua arah mesti betul. Rekod PTR biasanya hanya boleh diubah melalui panel penyedia VPS atau pemilik blok IP, bukan melalui panel domain. Kalau anda menggunakan hosting berkongsi, PTR itu milik penyedia.

dig +short -x 194.233.74.195
# mail.thalhah.my.
dig +short A mail.thalhah.my
# 194.233.74.195

Yang sering rosak ialah PTR yang menunjuk nama generik penyedia, contohnya vps-12-ab34.penyedia.com. Penerima membacanya sebagai tanda infrastruktur yang tidak dijaga.

Dua: SPF, satu rekod dan had sepuluh carian DNS

SPF ialah senarai IP yang dibenarkan menghantar e-mel bagi pihak domain anda. Satu domain hanya boleh ada satu rekod bermula dengan v=spf1. Kalau ada dua, sesetengah penerima mengembalikan permerror dan menolak semuanya, jadi dua rekod bukan dua kali lebih baik.

Ada had yang jarang disebut. RFC 7208 seksyen 4.6.4 mewajibkan pelaksanaan SPF mengehadkan istilah yang menyebabkan carian DNS, iaitu include, a, mx, ptr, exists dan redirect, kepada sepuluh sahaja. Melebihi had itu hasilnya permerror, bukan kejayaan kadang-kadang.

Rekod laman ini ringkas, iaitu v=spf1 mx -all. Mekanisme mx bermakna IP yang disenaraikan dalam rekod MX domain ini dibenarkan menghantar, dan pengakhir -all bermakna semua IP lain gagal secara tegas. Ini memadai kerana e-mel laman ini keluar melalui pelayan sendiri sahaja.

dig +short TXT thalhah.my
# "v=spf1 mx -all"

Dua kesilapan biasa. Pertama, guna +all atau ?all. Kedua-duanya membenarkan sesiapa menghantar sebagai domain anda. Kedua, rekod tidak dikemas kini apabila sistem baharu ditambah. Setiap kali anda pasang sesuatu yang menghantar e-mel, sama ada borang tempahan, surat berita atau sistem invois, penghantarnya perlu dimasukkan, dan setiap include dikira dalam had sepuluh itu.

Tiga: DKIM, kunci dan pemilih

DKIM meletakkan tandatangan kriptografi pada setiap mesej. Penerima menyemaknya dengan kunci awam yang diterbitkan dalam DNS pada nama <pemilih>._domainkey.<domain>. Laman ini menggunakan pemilih mail dengan kunci RSA 2048 bit dan algoritma sha256. Google mewajibkan sekurang-kurangnya 1024 bit untuk penghantaran ke akaun Gmail peribadi dan mengesyorkan 2048 bit, manakala RFC 6376 seksyen 3.3.3 mewajibkan penandatangan menggunakan sekurang-kurangnya 1024 bit untuk kunci jangka panjang.

dig +short TXT mail._domainkey.thalhah.my
# v=DKIM1;h=sha256;k=rsa;p=MIIBIjANBgkqh...

Kegagalan DKIM yang paling kerap bukan kunci hilang, tetapi pemilih yang salah. Sistem e-mel dipasang semula, kunci dijana dengan pemilih baharu, dan pemilih lama ditinggalkan dalam DNS. Mesej keluar tanpa tandatangan yang boleh disemak dan penerima melaporkannya sebagai dkim kosong. Kes kedua ialah penandatangan memakai domain penyedia sedangkan From ialah domain anda. Tandatangan itu sah, tetapi tidak sejajar.

Empat: DMARC dan alignment

DMARC diterbitkan pada _dmarc.<domain>. Ia tidak menyemak tandatangan atau IP sendiri. Ia menyemak dua perkara, adakah SPF atau DKIM lulus, dan adakah domain yang lulus itu sejajar dengan domain dalam From yang dilihat penerima.

Inilah punca nombor satu bagi kes SPF lulus tetapi mesej masih masuk spam. Contohnya laman anda menghantar dari alamat no-reply@laman-anda.my melalui pelayan hosting berkongsi. Envelope penghantar, iaitu Return-Path, sebenarnya bounce@penyedia-hosting.com. SPF lulus, tetapi untuk penyedia-hosting.com. Kalau DKIM tiada atau ditandatangani dengan domain penyedia, tiada satu pengesahan pun yang sejajar dengan From. DMARC gagal, dan pilihan penerima menentukan sama ada mesej dikarantin atau ditolak.

Laman ini memakai dasar reject dengan alignment ketat untuk kedua-dua DKIM dan SPF, dan laporan agregat dihantar ke postmaster@thalhah.my. Alignment ketat bermakna domain mesti sama tepat, bukan sekadar berkongsi domain organisasi yang sama.

dig +short TXT _dmarc.thalhah.my
# "v=DMARC1; p=reject; rua=mailto:postmaster@thalhah.my; adkim=s; aspf=s; pct=100"

Cara paling cepat melihat apa yang penerima lihat ialah buka mesej dalam Gmail, tekan menu tiga titik dan pilih Show original. Baris Authentication-Results mesti menunjukkan spf lulus, dkim lulus dan dmarc lulus, dan domain pada baris SPF mesti sepadan dengan domain From. Kalau SPF lulus tetapi diikuti domain penyedia, masalahnya bukan SPF tetapi alignment.

Lima: reputasi IP dan had penghantaran

Selepas identiti lulus, penerima menilai reputasi alamat IP. Garis panduan Google menyatakan aktiviti mana-mana penghantar pada satu IP berkongsi mempengaruhi reputasi semua penghantar pada IP itu, dan IP yang berada dalam senarai hitam lebih mudah ditandakan sebagai spam.

Kalau anda menghantar melalui VPS sendiri, hadnya dua, iaitu reputasi julat IP penyedia dan had kadar penyedia. Contabo, penyedia VPS yang menempatkan laman ini, menyatakan had penghantaran kira-kira 25 e-mel seminit dan memberi amaran bahawa penghantaran berterusan melebihi had itu boleh menyebabkan pelayan diperlahankan. Untuk borang hubungan dan notifikasi, 25 seminit jauh lebih daripada cukup. Untuk surat berita 5,000 penerima, ia tidak mencukupi, dan itu tanda kerja itu perlu melalui perkhidmatan penghantaran khusus.

Enam: port 25 dan keadaan di Malaysia

Di Malaysia, TM menyekat trafik SMTP keluar pada port 25 untuk pelanggan dengan alamat IP dinamik sejak 3 Disember 2007, dan hanya membenarkan trafik keluar melalui pelayan SMTP mereka. Sebab yang diumumkan pada masa itu ialah banyak IP dalam rangkaian TM sudah disenaraihitamkan oleh organisasi anti-spam. Maksudnya bagi pemilik laman, pelayan e-mel di rumah atau di pejabat nampak berfungsi tetapi mesej tidak keluar ke internet.

Banyak penyedia hosting Malaysia juga mengehadkan jumlah e-mel sejam daripada pelayan berkongsi, atau menghalangnya terus. Kalau borang laman anda menghantar puluhan e-mel sehari dan sebahagiannya gagal tanpa ralat dilihat pengguna, had penghantaran penyedia ialah tempat pertama untuk disemak.

Tujuh: kandungan, kadar aduan dan persetujuan

Kandungan jarang menjadi punca tunggal, tetapi ia boleh menutup semua kerja DNS di atas.

• ▸ E-mel yang hanya imej tanpa teks. Penapis perlu membaca teks untuk memahami mesej.
• ▸ Pautan ke domain yang sudah disenaraihitamkan, termasuk perkhidmatan pemendek URL murah yang pernah disalah guna.
• ▸ E-mel kepada senarai lama yang tidak mengenali anda. Kadar aduan naik dan reputasi turun bersama.

Google menetapkan kadar aduan spam yang dilaporkan penerima mesti kekal di bawah 0.3 peratus, dan mengesyorkan di bawah 0.1 peratus. Untuk penghantar pukal, iaitu lebih 5,000 mesej sehari ke akaun Gmail, Google dan Yahoo mewajibkan SPF dan DKIM kedua-duanya lulus, DMARC diterbitkan walaupun hanya dengan dasar none, domain From sejajar dengan SPF atau DKIM, dan butang berhenti langgan satu klik yang permintaannya diproses dalam dua hari.

MCMC menyatakan perbezaan utama antara e-mel sah dan spam ialah persetujuan. Kalau penerima meminta e-mel itu, ia bukan spam. Dalam halaman yang sama, MCMC menyatakan penghantar komersial wajib mendapatkan kebenaran penerima, memberikan maklumat penghantar yang tepat dan menyediakan kemudahan berhenti langgan yang berfungsi. Senarai yang dibeli tidak akan diselamatkan oleh mana-mana rekod DNS.

Lapan: akaun yang diambil alih

Sebahagian kes e-mel masuk spam bukan masalah penghantaran, tetapi akaun yang diambil alih. Pelayan laman ini menyimpan log Postfix, dan dalam tempoh 27 September hingga 13 Oktober 2026 log itu mencatat 11,506 cubaan log masuk SASL yang gagal melalui port 587 dan 465. Nama pengguna yang paling kerap dicuba ialah test, diikuti info dan demo, dan alamat IP paling aktif dalam tempoh itu ialah 62.60.134.210.

Angka ini biasa bagi pelayan yang port SMTP-nya terbuka, dan ia menerangkan dua perkara. Pertama, kalau kata laluan peti mel lemah, penyerang boleh menghantar e-mel sebagai anda dan reputasi domain anda boleh jatuh dalam beberapa jam. Kedua, penguncian selepas beberapa cubaan gagal lebih berguna daripada sekadar menukar kata laluan.

Sembilan: urutan pemeriksaan dua puluh minit

Semua ini boleh diperiksa dengan alat dalam talian, tetapi urutannya penting kerana satu lapisan bergantung pada lapisan sebelumnya.

• ▸ Semak PTR alamat IP penghantar dan pastikan nama hos itu menunjuk kembali kepada IP yang sama.
• ▸ Semak rekod SPF. Satu rekod sahaja, akhiran -all atau ~all dan bukan +all.
• ▸ Semak pemilih DKIM yang benar-benar digunakan sistem anda, bukan pemilih lalai dalam panduan.
• ▸ Semak rekod DMARC dan baca laporan agregat. Naikkan taraf daripada dasar none apabila laporan bersih.
• ▸ Hantar mesej ujian ke akaun Gmail sendiri dan baca baris Authentication-Results melalui Show original.
• ▸ Daftarkan domain dalam Postmaster Tools untuk melihat kadar aduan, kerana tanpa angka itu semua kerja lain hanya tekaan.

Sepuluh: apa yang DNS tidak boleh betulkan

SPF, DKIM dan DMARC membetulkan identiti, bukan hubungan dengan penerima. Beberapa perkara kekal masalah walaupun semua rekod betul, jadi jangan belanjakan masa pada DNS kalau kes anda salah satu daripada ini.

• ▸ Reputasi IP baharu. IP yang belum pernah menghantar perlu dipanaskan secara beransur-ansur selama beberapa hari.
• ▸ Mesej kepada orang yang tidak pernah meminta e-mel daripada anda. Kadar aduan naik dan penapis bertindak balas.
• ▸ IP berkongsi yang sudah tersenarai hitam kerana penyewa lain. Di sini tukar IP atau tukar penyedia memang penyelesaiannya.

Pemulihan reputasi bukan isu tetapan tetapi isu masa. Amalan yang berkesan ialah menghantar jumlah kecil secara berterusan kepada penerima yang benar-benar mahu mesej itu, kemudian memantau kadar aduan. Google sendiri menyatakan perubahan kadar spam mengambil masa untuk dicerminkan. Sesiapa yang menjanjikan pemulihan dalam 24 jam tidak boleh mengesahkannya.