Pengesahan E-mel untuk Perniagaan Malaysia: SPF, DKIM dan DMARC

Invois yang tidak pernah sampai

Pelanggan menghantar e-mel bertanya di mana resitnya. Anda hantar semula. Masih tidak sampai — bukan dipulangkan, bukan disekat terus, cuma senyap-senyap difailkan ke dalam folder spam yang tiada siapa semak, atau digugurkan tanpa kesan. Jika laman web anda menghantar e-mel — pengesahan pesanan, balasan borang hubungi, set semula kata laluan, invois — dan mana-mana bahagian bermakna daripadanya tidak sampai ke peti masuk, puncanya jarang sekali kandungan e-mel anda. Hampir selalu ia kerana pelayan mel penerima, yang menjalankan penapisan spam Gmail, Outlook atau Yahoo, tidak dapat mengesahkan domain anda benar-benar memberi kuasa mesej itu dihantar. Tiga rekod DNS membetulkan ini, dan setiap satu melakukan tugas yang benar-benar berbeza.

SPF: senarai jemputan untuk domain anda

Sender Policy Framework (SPF) ialah rekod DNS yang menyenaraikan pelayan mel mana yang dibenarkan menghantar e-mel yang mendakwa datang daripada domain anda. Apabila pelayan penerima mendapat mesej daripada "perniagaananda.com," ia menyemak rekod SPF untuk domain itu dan bertanya: adakah pelayan yang baru sahaja menyampaikan mesej ini sebenarnya berada dalam senarai yang diluluskan? Jika tidak, itu isyarat spam yang kuat.

Masalah dengan SPF sahaja ialah ia hanya menyemak pelayan penghantar teknikal — alamat "sampul" (envelope) yang tidak kelihatan — bukan nama "From:" yang benar-benar dilihat penerima dalam peti masuk mereka. Mesej boleh lulus SPF sambil masih memaparkan nama penghantar yang dipalsukan, sebab itulah SPF memang tidak pernah direka untuk berfungsi bersendirian.

DKIM: meterai kalis-godam pada mesej

DomainKeys Identified Mail (DKIM) berfungsi secara berbeza. Sistem mel anda melampirkan tandatangan kriptografi pada setiap mesej keluar, dijana menggunakan kunci peribadi yang hanya anda pegang. Pelayan penerima mencari kunci awam yang sepadan dalam DNS anda dan menyemak sama ada tandatangan itu sah dan sama ada mesej itu telah diubah sejak ditandatangani. Jika SPF menyemak "adakah ini datang daripada pelayan yang diluluskan," DKIM menyemak "adakah mesej ini sebenarnya ditulis oleh domain yang didakwanya, dan adakah ia telah diusik semasa penghantaran." Mesej boleh melalui beberapa pelayan penerus dan masih membawa tandatangan DKIM yang sah, salah satu sebab DKIM cenderung lebih tahan lasak berbanding SPF sahaja.

DMARC: dasar yang mengikat dua perkara pertama, dan melaporkan semula

Domain-based Message Authentication, Reporting and Conformance (DMARC) ialah rekod yang menjadikan SPF dan DKIM benar-benar berguna untuk menghentikan penyamaran. Ia melakukan dua perkara: ia menyatakan apa yang perlu dilakukan oleh pelayan penerima terhadap mesej yang gagal pengesahan (tidak buat apa-apa, kuarantin ke spam, atau tolak terus), dan ia meminta pelayan penerima menghantar semula laporan berkala tentang mel yang mendakwa datang daripada domain anda — yang selalunya kali pertama sesebuah perniagaan mendapati seseorang telah menyamar sebagai mereka.

Yang penting, DMARC turut memperkenalkan penjajaran (alignment), butiran yang menjatuhkan kebanyakan persediaan buat-sendiri (DIY). SPF dan DKIM masing-masing boleh "lulus" secara berasingan sambil menyemak domain yang berbeza daripada domain yang benar-benar dilihat penerima dalam medan "From:" — contohnya, platform pemasaran yang menghantar bagi pihak anda mungkin lulus semakan SPF miliknya sendiri sementara domain anda tidak disahkan dalam alamat From yang kelihatan. Penjajaran DMARC menghendaki domain dalam semakan lulus SPF atau DKIM itu sendiri benar-benar sepadan dengan domain yang dipaparkan kepada penerima, sama ada tepat sama (penjajaran ketat) atau pada peringkat domain organisasi (penjajaran longgar, lalai yang lebih biasa) (dmarcian, "DMARC Alignment"). Tanpa penjajaran, DMARC gagal walaupun SPF dan DKIM masing-masing lulus — dan inilah langkah yang paling kerap tertinggal dalam persediaan e-mel perniagaan kecil, kerana ia memerlukan ketiga-tiga rekod dikonfigurasikan supaya benar-benar sepadan antara satu sama lain, bukan sekadar wujud.

Sebab "dulu ia berfungsi baik" tidak bermakna ia akan terus begitu

Gmail dan Yahoo menjadikan pengesahan hampir wajib bagi sesiapa yang menghantar mel dalam jumlah bermakna. Garis panduan penghantar rasmi Google menghendaki mel disahkan dengan SPF dan DKIM yang dijajarkan pada peringkat organisasi, dan bahawa rekod DMARC wujud untuk domain penghantar, sekurang-kurangnya ditetapkan pada mod pantau-sahaja (p=none) (Google, "Email sender guidelines"). Penghantar yang melepasi lebih kurang 5,000 mesej sehari kepada alamat Gmail peribadi berdepan keperluan tambahan — dasar DMARC yang diterbitkan, kadar aduan spam yang kekal jauh di bawah 0.3%, dan sokongan berhenti langgan sekali klik pada mel pemasaran — dan kedua-dua Google serta Microsoft telah beralih kepada menolak secara kekal mel pukal yang tidak mematuhi, bukan sekadar memasukkannya ke folder spam (Google, "Email subscription guidelines for senders"; ringkasan industri di PowerDMARC, "Bulk Email Sender Rules"). Yahoo menjalankan set peraturan yang hampir sama — SPF, DKIM dan DMARC diperlukan, aduan spam dihadkan, berhenti langgan sekali klik dihormati dalam masa dua hari.

Kebanyakan laman perniagaan tidak menghantar 5,000 e-mel sehari dan tidak akan sampai ke ambang penghantar-pukal secara langsung. Tetapi jangkaan asas pengesahan — SPF dan DKIM yang sah dan terjajar, serta rekod DMARC yang diterbitkan — semakin terpakai kepada mana-mana domain penghantar, bukan sekadar penghantar pukal, kerana penapis spam menggunakan isyarat ini sebagai faktor kepercayaan am tanpa mengira jumlah. Domain tanpa rekod SPF, tanpa DKIM, dan tanpa rekod DMARC langsung kini dibaca sebagai bendera merah ringan oleh penapisan moden, walaupun untuk satu e-mel transaksi sehari.

Bahaya terus melompat ke "tolak"

Tetapan paling ketat DMARC, p=reject, memberitahu pelayan penerima menolak terus apa sahaja yang gagal penjajaran. Itulah tetapan yang benar-benar menghentikan penyamaran — dan ia juga tetapan yang, jika digunakan secara cuai, senyap-senyap menyekat mel sah anda sendiri. Laluan standard yang lebih selamat ialah bermula pada p=none (laporan sahaja, tiada apa disekat) untuk tempoh pemantauan, membaca laporan yang dijana DMARC untuk mencari setiap sumber sah yang menghantar bagi pihak anda — borang hubungi laman web anda, alat invois, CRM, penyedia gaji, platform surat berita — pastikan setiap satu disahkan dengan betul, dan hanya kemudian naik ke kuarantin dan akhirnya tolak, selalunya menggunakan pelancaran berperatusan (pct=) untuk mengesan masalah sebelum ia menjejaskan semua mel (Valimail, "DMARC Reject Policy"). Langkau tempoh pemantauan itu dan terus melompat ke tolak, dan tanda pertama masalah selalunya pelanggan memberitahu e-mel set semula kata laluan mereka tidak pernah sampai — kerana ia senyap-senyap dibuang oleh penyedia mel mereka sendiri, atas arahan anda. Subdomain mewarisi dasar DMARC domain induk melainkan dasar subdomain berasingan (sp=) ditetapkan, yang merupakan cara biasa dasar ketat pada domain utama tanpa disangka menyekat mel daripada subdomain yang jarang digunakan yang tiada siapa ingat masih menghantar.

Asingkan mel transaksi daripada identiti penghantar utama anda

Satu amalan praktikal yang berbaloi diamalkan awal: hantar e-mel transaksi — resit, set semula kata laluan, pengesahan pesanan — daripada subdomain khusus (sesuatu seperti mail.perniagaananda.com atau notify.perniagaananda.com) berbanding domain utama anda, dan pastikan mel pemasaran atau pukal pada subdomain berasingan lagi. Setiap subdomain membawa reputasi penghantar sendiri, konfigurasi SPF, DKIM dan DMARC sendiri, dan tempoh "pemanasan" (warm-up) sendiri dengan penyedia peti mel. Mengasingkannya bermakna kempen pemasaran yang ditandakan kerana aduan spam tidak menjejaskan kebolehsampaian resit yang sedang ditunggu pelanggan anda, dan aliran transaksi yang bermasalah juga tidak meracuni penempatan peti masuk surat berita anda (Suped, "Should I use subdomains for transactional and promotional emails"). Ini corak yang benar-benar berguna bagi perniagaan Malaysia yang sedang berkembang, tetapi ia menambah kerja persediaan — tidak berbaloi dilakukan untuk satu borang hubungi bervolum rendah sahaja, hanya apabila jumlah dan variasi e-mel mula penting kepada perniagaan.

Di mana ini biasanya tersasar dalam praktik

Mod kegagalan yang wajar dirisaukan jarang sekali dasar DMARC yang tersalah konfigurasi — lebih kerap ia langsung tiada rekod DMARC, rekod SPF yang tertinggal daripada penyedia hosting atau e-mel yang bertukar bertahun-tahun lalu, dan tiada penandatanganan DKIM dikonfigurasikan pada perkhidmatan penghantar sejak awal lagi. Tiada satu pun daripada ini kelihatan daripada laman web itu sendiri; ia hanya terserlah apabila anda menyemak rekod DNS secara langsung dan menguji penghantaran mesej sebenar. Jika anda tidak pasti status semasa SPF, DKIM dan DMARC domain anda, ketidakpastian itu sendiri jawapan yang wajar ditindaklanjuti.

Pilihan jujur, bukan jaminan

Membetulkan pengesahan e-mel tidak menjamin setiap mesej sampai ke peti masuk — kebolehsampaian bergantung pada reputasi penghantar, kandungan, sejarah penglibatan dan banyak lagi, dan tiada siapa boleh menjanjikan penempatan peti masuk. Apa yang semakan yang betul boleh lakukan ialah mengesahkan asas-asas peringkat DNS benar-benar tersedia dan dijajarkan dengan betul, iaitu asas kepada segala-galanya yang lain. Semakan Sistem Penting JagaWeb (RM1,500, kini RM999 sehingga 16 September 2026) merangkumi pengesahan e-mel sebagai salah satu daripada lapan titik kawalannya, bersama laporan sedia-keputusan dan pelan tindakan 30 hari untuk satu laman sehingga 25 halaman. Hubungi kami di sales@jagaweb.my, WhatsApp di jagaweb.my, atau jagaweb.my.