Mulakan dengan tiga soalan yang berbeza
Pengesahan e-mel perniagaan mempunyai tiga tugas berkaitan tetapi berlainan. SPF memeriksa sama ada sistem penghantar dibenarkan menghantar bagi domain sampul mesej. DKIM memeriksa tandatangan kriptografi yang boleh disahkan daripada domain penandatangan. DMARC pula menyemak sama ada identiti SPF atau DKIM yang lulus sejajar dengan domain pada medan From yang dilihat penerima, kemudian menerbitkan polisi pengendalian serta pilihan laporan. Pemeriksaan ini mengurangkan sebahagian bentuk penyamaran domain, tetapi tidak mengesahkan bahawa individu yang menghantar mesej boleh dipercayai. Syarikat perlu memahami tiga soalan ini sebelum menyalin sebarang rekod ke DNS.
Bezakan alamat From yang dilihat dengan penghantar sampul
Satu e-mel mempunyai lebih daripada satu identiti penghantar. Pengepala From biasanya ialah alamat yang dilihat oleh orang yang membaca mesej. SMTP juga menggunakan penghantar sampul, sering disebut MAIL FROM atau return path, untuk penghantaran serta pengurusan mesej gagal. Domain ini boleh berbeza secara sah apabila aplikasi bil atau platform buletin menghantar bagi pihak perniagaan. SPF lazimnya memeriksa identiti sampul, bukan alamat From yang dipaparkan. Perbezaan ini menerangkan mengapa mesej boleh lulus SPF tetapi gagal penjajaran DMARC. Semasa menyiasat masalah, periksa pengepala mesej sebenar dan jangan menilai pengesahan melalui nama dalam peti masuk sahaja.
Perkara yang dibenarkan oleh SPF
Sender Policy Framework ialah polisi yang diterbitkan dalam DNS untuk menerangkan hos yang dibenarkan menghantar e-mel menggunakan domain sampul tertentu. Sistem penerima membandingkan alamat IP penghantar dengan mekanisme SPF domain lalu menghasilkan keputusan seperti pass, fail, softfail atau permerror. SPF tidak menandatangani mesej, membuktikan identiti penulis yang dipaparkan atau menyulitkan kandungan. Pemilik domain perlu mengambil kira semua infrastruktur penghantaran sah, bukan hanya penyedia peti mel pekerja. Sistem pemberitahuan laman, aplikasi perakaunan atau platform pemasaran boleh menghantar secara berasingan. Inventori yang tidak lengkap boleh menyebabkan mesej perniagaan sebenar gagal pemeriksaan.
Fahami satu polisi SPF dan mekanismenya
SPF lazimnya diterbitkan sebagai nilai TXT DNS yang bermula dengan v=spf1. Mekanisme boleh membenarkan julat IPv4 atau IPv6 tertentu, merujuk hos penghantar atau memasukkan polisi yang diterbitkan oleh domain lain. Mekanisme all pada penghujung menerangkan cara penghantar yang tidak sepadan dinilai, dengan penanda berlainan menghasilkan keputusan berbeza. Unsur ini tidak boleh dianggap sama, dan rekod yang disalin daripada perniagaan lain mungkin membenarkan infrastruktur salah. Domain tidak sepatutnya menerbitkan beberapa polisi SPF berasingan pada nama yang sama kerana penilai boleh menghasilkan ralat kekal. Gabungkan sumber sah dalam satu polisi yang disemak dengan mengambil kira had penilaian spesifikasi.
Patuhi had carian DNS SPF
RFC 7208 mengehadkan penilaian SPF kepada sepuluh mekanisme atau pengubah yang mencetuskan carian DNS, termasuk include, a, mx, ptr, exists dan redirect. Had ini berkaitan proses penilaian, bukan sekadar bilangan cebisan teks yang kelihatan dalam rekod. Include bersarang menggunakan bajet yang sama. Jika had dilepasi, keputusan permerror boleh terhasil; menambah semua include pembekal tanpa memeriksa rangkaian penuh boleh melemahkan polisi. Sesetengah mekanisme seperti ip4 dan ip6 tidak menggunakan bajet carian tersebut dengan cara sama. Sebelum meluluskan perubahan, dokumentasikan setiap penghantar sah, kira laluan carian berkesan dan sahkan rekod awam yang terhasil.
Mengapa pemajuan merumitkan SPF
Apabila penerima memajukan mesej secara automatik, pelayan yang menyerahkan salinan mungkin berbeza daripada penghantar asal. Penerima yang memeriksa SPF terhadap domain sampul asal boleh melihat alamat IP yang tidak pernah dibenarkan oleh domain tersebut. Ini batasan yang diketahui, bukan semestinya bukti bahawa mesej asal berniat jahat. Sesetengah sistem pemajuan menulis semula alamat penghantar untuk mengurangkan masalah, tetapi tingkah lakunya berbeza. DKIM mungkin masih boleh disahkan jika kandungan bertandatangan dikekalkan. Ketika menyiasat e-mel dimajukan, bandingkan hasil pengesahan sebelum dan selepas pemajuan dan jangan terus melemahkan polisi SPF domain.
Cara tandatangan DKIM berfungsi
DomainKeys Identified Mail menggunakan kunci peribadi yang disimpan oleh perkhidmatan penghantar dan kunci awam sepadan yang disediakan melalui DNS. Sistem keluar menambah pengepala DKIM-Signature yang menerangkan domain penandatangan, pemilih dan kandungan yang ditandatangani. Sistem penerima mendapatkan kunci awam lalu memeriksa kesahihan tandatangan. Keputusan ini membantu mengesan perubahan berkaitan pada pengepala dan badan mesej selepas ditandatangani. DKIM bukan penyulitan dan tidak menyembunyikan kandungan e-mel daripada sistem perantara. Ia juga tidak membuktikan bahawa domain From yang dilihat sepadan dengan domain penandatangan; DMARC menangani soalan penjajaran itu secara berasingan.
Fahami pemilih DKIM dan pemilikan kunci
Pemilih DKIM menentukan kunci awam yang perlu dicari oleh penerima, lazimnya pada subdomain selector._domainkey bagi domain penandatangan. Perniagaan mungkin mempunyai beberapa pemilih kerana perkhidmatan berbeza menandatangani mesej sendiri atau kunci sedang diganti. Kunci peribadi mesti kekal di bawah kawalan sistem penandatangan yang dibenarkan; menyiarkannya atau berkongsinya secara sembarangan merosakkan perlindungan. Rekod DNS yang mengandungi kunci awam adalah perkara biasa, tetapi mesti sepadan dengan penandatangan aktif. Semasa menukar penyedia, kenal pasti pemilih yang masih digunakan sebelum membuang rekod lama. Kehadiran satu pemilih sahaja tidak membuktikan perkhidmatan tersebut masih menghantar mesej.
Mengapa e-mel sah boleh gagal DKIM
Senarai mel, gerbang atau sistem perantara lain mungkin menambah nota kaki, mengubah tajuk atau menyunting bahagian mesej yang ditandatangani. Bergantung pada unsur yang ditandatangani dan kaedah penyeragaman, tandatangan mungkin tidak lagi sah. Kunci awam yang tiada, pemilih tidak sepadan atau ralat konfigurasi penandatangan juga boleh menyebabkan kegagalan. Jangan anggap setiap kegagalan DKIM membuktikan penipuan. Periksa domain tandatangan, pemilih, hasil pengesahan dan laluan mesej, kemudian rujuk pembekal yang bertanggungjawab tentang perubahan kandungan. Jika SPF lulus dengan penjajaran DMARC, mesej masih boleh memenuhi DMARC walaupun DKIM gagal, tertakluk pada pengendalian penerima.
DMARC menghubungkan pengesahan dengan domain yang dilihat
DMARC menilai domain pada medan RFC5322.From yang dilihat pembaca terhadap identiti yang telah disahkan. Mesej lazimnya lulus DMARC apabila sekurang-kurangnya satu daripada SPF atau DKIM lulus dan identiti yang lulus sejajar dengan domain From tersebut. SPF yang lulus bagi domain pemulangan berlainan tidak mencukupi dengan sendirinya. Tandatangan DKIM sah daripada domain lain yang tidak berkaitan juga tidak mencukupi. Inilah sebabnya ketiga-tiga mekanisme saling melengkapi. Pemilik domain menerbitkan DMARC sebagai polisi TXT di bawah _dmarc bagi domain berkaitan. Rekod itu menyatakan tindakan yang diminta dan boleh memohon laporan daripada penerima yang menyokongnya.
Penjajaran longgar dan ketat berbeza
DMARC menyokong penjajaran identiti longgar dan ketat. Dalam mod longgar, subdomain yang berkaitan dengan betul mungkin sejajar dengan domain organisasi pada From; mod ketat lazimnya memerlukan padanan domain tepat. Tetapan ini mempengaruhi sistem sah yang menghantar daripada subdomain atau menandatangani dengan domain induk berkaitan. Lebih ketat tidak semestinya lebih selamat jika aliran e-mel yang diluluskan terputus tanpa mengurangkan risiko sebenar. Semak domain From, MAIL FROM dan penandatangan DKIM sebelum memilih mod penjajaran. RFC memberikan takrif tepat; membandingkan rupa dua alamat e-mel sahaja tidak menggantikan penilaian hubungan antara domain.
Maksud DMARC none, quarantine dan reject
Tag p dalam DMARC menyatakan polisi yang diminta bagi mesej yang gagal pemeriksaan penjajaran. Polisi none terutama menyokong pemerhatian dan pelaporan tanpa meminta pengendalian khas. Quarantine meminta mesej dianggap mencurigakan, manakala reject meminta mesej yang gagal ditolak. Sistem penerima masih mempunyai polisi operasinya sendiri, maka nilai yang diterbitkan bukan jaminan tindakan sejagat. Beralih terus kepada reject sebelum mengenal pasti penghantar sah boleh mengganggu bil, pemberitahuan atau surat-menyurat perniagaan. Rancang perubahan berperingkat: dapatkan gambaran awal, betulkan penghantar yang diluluskan, nilai laporan dan hanya kemudian pertimbangkan penguatkuasaan lebih ketat bersama pelan pemulihan yang dibenarkan.
Laporan DMARC ialah bukti, bukan pembaikan automatik
Laporan agregat DMARC boleh memberikan maklumat tentang sumber penghantaran dan hasil pengesahan yang dilihat oleh penerima yang mengambil bahagian. Ia mungkin menunjukkan perkhidmatan sah yang terlupa semasa konfigurasi atau sumber tidak dikenali yang menggunakan domain. Pelaporan tidak semestinya lengkap bagi setiap penerima, dan alamat IP sahaja tidak membuktikan niat. Tafsirkan laporan sebagai penyiasatan: bandingkan sumber dengan inventori penghantar diluluskan, kenal pasti kegagalan penjajaran dan dokumentasikan cadangan pembaikan. Destinasi laporan mungkin menerima banyak data, jadi pilih peti mel atau perkhidmatan yang dibenarkan dengan kawalan akses serta tempoh simpanan sesuai. Laporan tidak mengubah rekod SPF, DKIM atau DMARC secara automatik.
Inventorikan semua perkhidmatan penghantar sah dahulu
Perniagaan kecil mungkin menghantar daripada peti mel pekerja, platform perakaunan, sistem tempahan, borang pertanyaan, alat sokongan pelanggan dan penyedia buletin. Setiap perkhidmatan boleh menggunakan laluan teknikal berbeza walaupun pelanggan melihat alamat syarikat yang sama. Sebelum mengubah DNS, senaraikan pemilik aplikasi, domain From, domain sampul, domain penandatangan DKIM, dokumentasi pembekal yang diperlukan serta mesej ujian diluluskan. Sahkan sama ada sistem menghantar terus, menggunakan pelayan perantara atau sekadar menyediakan draf untuk pekerja. Jangan meluluskan arahan DNS umum pembekal tanpa memastikan arahan itu sesuai dengan akaun dan kaedah penghantaran sebenar.
Contoh: invois dihantar melalui platform lain
Bayangkan syarikat andaian yang pekerjanya menggunakan perkhidmatan peti mel biasa, manakala platform perakaunan menghantar pemberitahuan invois dengan domain syarikat yang sama pada From. Mesej pekerja disahkan dengan baik tetapi invois gagal DMARC kerana platform menandatangani menggunakan domainnya sendiri yang tidak berkaitan serta laluan pemulangan yang tidak sejajar. Tindakan sesuai bukan mematikan semua pengesahan. Kenal pasti pilihan pengesahan domain khusus yang disokong platform, periksa pengepala mesej sebenar dan rancang konfigurasi yang disemak jika disediakan. Jika penjajaran tidak boleh dicapai, pertimbangkan aliran kerja alternatif yang diluluskan. Ini contoh diagnostik andaian, bukan dakwaan tentang produk perakaunan tertentu.
Cari lokasi DNS yang berautoriti
Rekod DNS mesti diterbitkan dalam zon yang dilayan oleh pelayan nama berautoriti bagi domain. Syarikat pendaftar domain, penyedia hosting web dan pembekal e-mel mungkin organisasi berlainan. Menyunting panel yang mudah dicapai tetapi tidak berautoriti mungkin tidak memberi kesan kepada pengesahan awam. Dokumentasi Email Deliverability cPanel membezakan cadangan setempat daripada rekod yang mesti diterbitkan pada perkhidmatan DNS berautoriti. Sebelum perubahan, kenal pasti pengawal zon aktif, simpan salinan nilai sedia ada dan sahkan pihak yang dibenarkan menyunting. Artikel ini bertujuan pendidikan; ia tidak memberikan kebenaran untuk mengubah sebarang domain.
Baca pengepala mesej untuk mengesahkan hasil
Carian DNS yang menunjukkan rekod TXT dengan sintaks sah hanyalah sebahagian pengesahan. Mesej ujian yang dibenarkan perlu dihantar melalui setiap perkhidmatan sebenar kepada penerima yang memaparkan hasil pengesahan. Periksa keputusan SPF, DKIM dan DMARC, domain penjajaran serta sebarang ralat penghantaran. Rekodkan aplikasi penghantar, masa dan destinasi tanpa mendedahkan kandungan pelanggan yang tidak perlu. Jika hasil berbeza daripada jangkaan, semak identiti sampul, pemilih DKIM dan DNS awam dan bukannya berulang kali menambah rekod. Ujian kepada satu penerima tidak menjamin layanan sama di semua tempat, tetapi memberikan bukti lebih kukuh daripada tangkapan layar konfigurasi sahaja.
Tafsir keputusan lulus, gagal dan ralat sementara
SPF pass bermaksud alamat IP penghantar memenuhi polisi yang dinilai bagi domain yang diperiksa; ia tidak bermaksud mesej selamat. DKIM pass bermaksud tandatangan tertentu dapat disahkan; ia tidak menjamin domain penandatangan sama dengan From yang dipaparkan. DMARC pass memerlukan syarat penjajaran yang berkaitan. Ralat kekal mungkin menunjukkan rekod tidak sah atau carian SPF berlebihan, manakala ralat sementara boleh berpunca daripada gangguan DNS. Teliti kod ralat tepat serta penerangan sistem penerima sebelum mengubah polisi. Hasil pengesahan perlu ditafsir bersama reputasi penghantar, kandungan mesej dan kawalan keselamatan di pihak penerima.
Jangan samakan pengesahan dengan jaminan peti masuk
Pengesahan yang betul menyokong penghantaran bertanggungjawab, tetapi penyedia penerima turut mempertimbangkan reputasi, aduan spam, kandungan, corak penghantaran dan polisi sendiri. SPF, DKIM dan DMARC tidak menjamin mesej sampai ke peti masuk utama atau semua mesej palsu akan disekat. Ketiga-tiganya juga tidak menghalang penyerang yang menguasai akaun yang benar-benar disahkan. Perniagaan masih memerlukan perlindungan log masuk, semakan akses, latihan pengguna serta prosedur menangani mesej mencurigakan. Jelaskan rekod ini sebagai satu lapisan perlindungan, bukan jaminan penghantaran. Rekodkan hasil penghantaran sebenar sebelum mendakwa berlaku peningkatan.
Urus subdomain dan domain tidak digunakan dengan sengaja
Perniagaan mungkin menghantar e-mel daripada domain utama, subdomain sokongan atau subdomain pemberitahuan khusus. Setiap identiti memerlukan semakan kerana polisi SPF dinilai bagi domain yang benar-benar digunakan, manakala domain tandatangan DKIM dan penjajaran organisasi DMARC boleh berbeza. Jangan anggap rekod SPF domain induk secara automatik membenarkan semua subdomain. Sebaliknya, domain atau subdomain tidak digunakan tidak patut dibiarkan mudah disalahgunakan akibat polisi kabur. Dokumentasikan nama yang dibenarkan menghantar e-mel dan nama yang tidak digunakan. Semak RFC serta arahan pembekal sebelum menerapkan polisi agresif, khususnya apabila sistem lama mungkin masih menggunakan subdomain yang terlupa.
Rancang migrasi pembekal dengan tempoh pertindihan
Apabila berpindah daripada satu pembekal e-mel kepada pembekal lain, sistem lama dan baharu mungkin kedua-duanya menghantar mesej sah semasa peralihan terkawal. Membuang kebenaran SPF lama atau kunci awam DKIM terlalu awal boleh mengganggu mesej yang masih dalam perjalanan atau dijana aplikasi lama. Mengekalkan kebenaran usang selama-lamanya juga tidak wajar. Sediakan inventori peralihan yang menyatakan perkhidmatan bagi setiap jenis mesej, masa pertukaran, ujian dan tarikh semakan pembuangan. Sahkan rekod serta mesej bertandatangan sebelum menarik balik entri tidak digunakan. Penyebaran dan caching DNS boleh melambatkan pemerhatian, jadi jangan isytihar kejayaan berdasarkan satu carian segera. Migrasi sebenar memerlukan izin pemilik berasingan.
Tetapkan tanggungjawab dan rekod kelulusan selamat
Pemilik domain perlu mengetahui siapa mengurus DNS berautoriti, siapa mengawal platform e-mel, siapa menjaga setiap penghantar pihak ketiga dan siapa menyemak laporan pengesahan. Minta pembekal menyatakan nama rekod, nilai, tujuan, laluan penghantaran terjejas serta kaedah pemulihan secara bertulis. Jangan simpan kelayakan akses atau kunci DKIM peribadi dalam dokumen editorial biasa. Rekodkan konfigurasi lama, perubahan dicadangkan, pelulus yang dibenarkan, hasil pengesahan serta tarikh susulan. Perunding teknikal boleh menerangkan risiko tanpa mendapat izin mengubah produksi. Hasil yang baik ialah keputusan yang boleh dijejaki serta konfigurasi diuji, bukan sekadar lencana hijau dalam panel hosting.
Senarai semak keputusan untuk pasukan kecil
Sebelum meminta kerja konfigurasi, sahkan domain serta pembekal DNS berautoriti, inventori semua penghantar sebenar dan dapatkan arahan rasmi pembekal berkaitan. Periksa supaya SPF menjadi satu polisi tersusun dalam had carian, tandatangan DKIM sepadan dengan kunci awam yang boleh dicapai dan sekurang-kurangnya satu mekanisme yang lulus sejajar dengan domain From. Pilih pendekatan pemantauan serta penguatkuasaan DMARC yang mampu diurus perniagaan, bersama destinasi laporan dan pelan pemulihan diluluskan. Uji setiap laluan penghantaran dan dokumentasikan pengecualian. Jika ada penghantar yang tidak dapat dikenal pasti atau diuji, tandakan perubahan sebagai menunggu semakan dan jangan membuat andaian tentang invois atau notis pelanggan.