Mulakan dengan satu contoh sebenar
Sebut harga yang masuk spam boleh melambatkan jualan. Invois yang tidak ditemui pula menambah kerja susulan. Sebelum menukar penyedia atau menghantar berulang kali, kumpulkan satu contoh: pengirim, penerima, masa penghantaran, tajuk dan sebarang mesej ralat. Tanya sama ada mesej ditolak, masuk spam atau langsung tidak ditemui. Keadaan ini berbeza.
Simpan mesej asal dan pengepala penuh jika tersedia. Kongsi maklumat diagnostik secara peribadi dengan penyedia, bukan dengan menyiarkan surat-menyurat pelanggan secara terbuka. Satu contoh khusus lebih membantu daripada laporan umum bahawa e-mel tidak berfungsi.
Kenal pasti semua sistem penghantar domain anda
Aplikasi e-mel pasukan mungkin bukan satu-satunya penghantar. Borang laman web, platform invois dan alat surat berita boleh menghantar secara berasingan. Senaraikan semuanya dan uji setiap laluan. Ujian berjaya daripada peti mel sendiri tidak membuktikan platform invois telah disediakan dengan betul.
Minta penyedia menyemak pengesahan bagi setiap laluan. SPF mengenal pasti infrastruktur penghantar yang dibenarkan, DKIM menambah tandatangan domain, dan DMARC menyemak penjajaran dengan domain pengirim yang dipaparkan. Google menyarankan ketiga-tiganya. Semak penghantar sedia ada sebelum mengetatkan dasar DMARC supaya mesej sah tidak terjejas tanpa dijangka.
Semak perkara selain kandungan mesej
Pengesahan penting, tetapi bukan jaminan masuk ke peti masuk. Panduan Google turut merangkumi infrastruktur penghantaran, reputasi dan aduan penerima. Penyedia pengehosan mungkin perlu menyiasat masalah alamat IP penghantar yang dikongsi. Menukar tajuk sahaja tidak membaiki masalah itu.
Gunakan nama pengirim tepat dan tajuk yang menerangkan tujuan sebenar mesej. Pastikan maklumat hubungan, pautan dan lampiran dijangka oleh penerima. Jangan gambarkan mesej baharu sebagai balasan kepada perbualan sedia ada. Jika PDF terlalu besar, pertimbangkan versi lebih kecil atau kaedah perkongsian dokumen yang dipersetujui.
Jalankan ujian terkawal
Hantar mesej perniagaan ringkas melalui sistem yang bermasalah kepada penerima ujian yang bersetuju membantu. Catat masa dan hasil, kemudian ubah satu tetapan berkaitan pada satu masa bersama penyedia. Ini memudahkan penilaian sama ada pembaikan berjaya.
Untuk surat berita berkala, gunakan senarai berasaskan persetujuan dan sediakan cara mudah berhenti melanggan. Keluarkan alamat yang berulang kali gagal. Urus surat-menyurat pelanggan biasa dan kempen pukal secara berasingan dengan alat sesuai serta tanggungjawab yang jelas.
Sediakan maklumat untuk penyedia
Sediakan domain, aplikasi penghantar, penyedia penerima yang terjejas, anggaran tarikh masalah bermula dan satu contoh terkini. Maklumkan perubahan DNS, pengehosan atau platform invois yang baru dibuat. Jangan hantar kata laluan peti mel melalui mesej sokongan biasa.
OnHypp boleh menyemak konfigurasi pengehosan dan domain mengikut skop yang dipersetujui serta membantu mengenal pasti tindakan seterusnya. Sesetengah isu memerlukan siasatan platform penghantar atau organisasi penerima. Matlamatnya ialah diagnosis yang direkodkan dan penambahbaikan yang boleh dinilai, bukan janji bahawa setiap mesej sentiasa sampai ke peti masuk.
Bezakan penapisan spam daripada penolakan mesej
Apabila pelanggan mengatakan e-mel tidak diterima, kenal pasti terlebih dahulu apa yang sebenarnya berlaku. Mesej mungkin diterima ke folder Spam, ditolak pelayan penerima, ditangguhkan untuk cubaan semula atau tidak berjaya dihantar oleh aplikasi asal. Setiap keadaan memerlukan bukti dan penyelesaian berbeza. Minta alamat penghantar, penerima, masa penghantaran tempatan serta teks ralat yang dipulangkan. Ketiadaan notis pantulan bukan bukti mesej sampai ke peti utama. Jangan menghantar semula invois sulit berkali-kali ketika menyiasat kerana pendua boleh mengelirukan pelanggan serta kelihatan mencurigakan. Mulakan dengan satu ujian terkawal yang dapat dijejak dari awal hingga akhir.
Senaraikan setiap perkhidmatan yang menghantar menggunakan domain
Domain perniagaan mungkin menghantar e-mel daripada akaun pekerja, borang hubungan laman, sistem perakaunan, notifikasi CRM, peringatan tempahan dan platform buletin. Sistem berlainan boleh menggunakan infrastruktur penghantaran berbeza walaupun alamat From kelihatan hampir sama. Bina inventori penghantar sebelum mengubah SPF atau DMARC; jika tidak, perubahan untuk meningkatkan penghantaran mungkin menyekat perkhidmatan sah. Rekodkan sama ada platform menggunakan SMTP berautentikasi, perkhidmatan sendiri atau penghantaran transaksi khusus. Minta pemilik aplikasi mengesahkan mesej ujian serta perubahan konfigurasi terkini. Ini mengelakkan pembangun laman dan pentadbir e-mel menyiasat sistem berlainan seolah-olah semuanya satu pelayan.
Fahami SPF tanpa menganggapnya jaminan penghantaran
SPF memberitahu sistem penerima infrastruktur yang dibenarkan oleh domain bagi identiti penghantar envelope tertentu. Ia tidak bermaksud mesej yang disahkan pasti masuk ke Inbox. Kesilapan lazim termasuk beberapa rekod TXT SPF bagi domain sama, tertinggal perkhidmatan penghantar sah atau rantaian carian yang melampaui had protokol. Jangan menyalin contoh SPF daripada perniagaan lain: rekod betul bergantung pada inventori penghantar sebenar dan domain yang digunakan ketika penghantaran SMTP. Minta pentadbir bertanggungjawab mengesahkan rekod akhir dan ujian terkawal, terutama selepas menukar sistem perakaunan atau memindahkan pelayan laman web.
Fahami perkara yang boleh dan tidak boleh dibuktikan DKIM
DKIM menambah tandatangan kriptografi pada pengepala dan kandungan terpilih supaya penerima boleh menyemak sama ada bahagian yang ditandatangani masih sepadan dengan kunci domain yang diterbitkan. Tandatangan sah ialah petunjuk pengesahan berguna, bukannya bukti penghantar itu jujur atau arahan pembayaran selamat. Beberapa aplikasi mungkin menandatangani mesej dengan pemilih dan kunci berbeza; kunci lama boleh dinyahaktifkan secara salah jika inventori penghantar tidak lengkap. Semak cara perkhidmatan menerbitkan dan menukar kunci. Ketika menyiasat aduan, teliti keputusan pengesahan pihak penerima, bukan sekadar menganggap kewujudan rekod DNS DKIM bermakna semua mesej ditandatangani.
Fahami penjajaran DMARC dan risiko pelaksanaannya
DMARC menilai penjajaran antara domain From yang dilihat pengguna dengan identiti SPF atau DKIM yang disahkan, kemudian membolehkan pemilik domain menerbitkan dasar pengendalian serta meminta laporan. Dasar ketat tidak patut terus digunakan semata-mata untuk mendapatkan skor sempurna pada alat semakan. Mulakan dengan mengumpul bukti penghantar sah, memahami kegagalan, membetulkan konfigurasi aplikasi dan meningkatkan dasar secara berhati-hati mengikut risiko organisasi. Pemajuan dan senarai mel boleh merumitkan keputusan penjajaran, jadi satu kegagalan bukan bukti automatik penghantar berniat jahat. DMARC mengurangkan beberapa risiko penyamaran tetapi tidak menghalang penyerang yang sudah mengawal akaun sah.
Semak reputasi penghantar dan corak penghantaran
Pengesahan ialah satu unsur penempatan peti masuk sahaja. Penyedia penerima mungkin turut menilai reputasi, aduan pengguna, konsistensi penghantaran, pautan mencurigakan, perisian berbahaya dan sama ada penerima benar-benar mahu mesej tersebut. Domain baharu perlu mengelakkan penghantaran promosi berskala besar secara mendadak tanpa persetujuan serta kaedah berhenti melanggan yang betul. Asingkan e-mel transaksi sah daripada pemasaran apabila aplikasi dan perkhidmatan menyokongnya. Menghantar mesej berulang kepada alamat tidak aktif atau tersalah taip menimbulkan masalah yang boleh dielakkan. Jika masalah hanya berlaku pada satu penyedia penerima, bandingkan bukti sebelum mengubah keseluruhan DNS. Tiada pihak boleh menjamin semua e-mel sah akan sentiasa melepasi penapis spam.
Semak pemformatan mesej serta lampiran berisiko
E-mel invois mungkin disahkan secara teknikal tetapi masih ditapis kerana lampiran mencurigakan, pautan mengelirukan atau perubahan arahan bayaran yang tidak dijangka. Gunakan tajuk tepat dan maklumat hubungan syarikat jelas, bukannya dakwaan mendesak yang sengaja memaksa penerima mengklik. Elakkan menghantar fail boleh laksana berpassword atau arkib asing tanpa persetujuan awal. Sahkan pautan yang dipaparkan benar-benar menuju ke domain rasmi yang dimaksudkan. Jika pembekal tiba-tiba meminta akaun bank baharu, sahkan melalui saluran dipercayai terdahulu dan bukan membalas e-mel sama sahaja. Amalan ini membantu mengurangkan risiko, tetapi mesej yang ditulis baik tidak menggantikan keselamatan akaun penghantar yang sudah digodam.
Kumpulkan bukti penghantaran tanpa mendedahkan rahsia
Minta mesej ujian yang mewakili masalah, masa tepat penghantaran serta keputusan diterima atau ditolak. Apabila dibenarkan, semak pengepala asal mesej dan keputusan Authentication-Results penerima bagi melihat sama ada SPF, DKIM dan DMARC lulus untuk mesej tersebut. Bandingkan penghantaran berjaya dengan yang gagal daripada aplikasi sama. Jangan masukkan alamat pelanggan, invois sulit, kuki sesi atau kata laluan pentadbir dalam tiket sokongan awam atau arahan AI; nyahkenal pasti maklumat sebelum berkongsi diagnostik. Aduan ringkas 'e-mel masuk spam' tidak cukup bukti. Garis masa dengan ID mesej dan kod ralat lebih mudah ditindaklanjuti.
Elakkan e-mel rosak ketika menukar hosting laman web
Pemindahan laman web ke persekitaran hosting terurus lain biasanya melibatkan DNS web dan fail aplikasi, bukan semestinya pemindahan semua peti mel perniagaan. Rekod MX serta rekod pengesahan e-mel perlu direkodkan, dikekalkan dan diuji secara berasingan. Sesetengah borang hubungan laman masih menghantar melalui pelayan lama atau peti mel SMTP; integrasi itu memerlukan rancangan penukaran sendiri apabila laman dipindahkan. Jangan membuang rekod DNS hanya kerana pembangun laman baharu tidak mengenalinya. Halaman utama yang berjaya dimuat dan sijil SSL sah bukan bukti e-mel sebut harga atau notifikasi tetapan kata laluan dihantar dengan betul. Uji aliran aplikasi-ke-e-mel penting secara tersendiri.
Asingkan insiden pancingan data daripada penapisan spam biasa
Apabila pekerja melaporkan e-mel mencurigakan, bezakan dua persoalan: adakah mesej luar yang tidak dikehendaki ditapis, atau seseorang benar-benar mengakses akaun syarikat yang sah? Bukti pencerobohan termasuk mesej dihantar tanpa diketahui, aturan pemajuan asing, amaran log masuk dan perubahan maklumat pemulihan. Keadaan ini memerlukan pengawalan akaun serta prosedur insiden, bukan hanya perubahan DNS. Lindungi rekod terjejas, batalkan sesi dan siasat bersama pentadbir yang dibenarkan. Menukar pelan hosting tidak membetulkan amalan berkongsi kata laluan, ketiadaan MFA atau kelulusan arahan pembayaran palsu. Jadikan kesedaran keselamatan pekerja dan pengesahan bayaran bebas sebahagian proses perniagaan.
Persetujui pihak yang mengurus DNS, peti mel dan aplikasi
Syarikat laman web, hos e-mel dan pembekal perisian perakaunan mungkin mengawal bahagian penghantaran yang berbeza. Catat pihak yang mengurus DNS, siapa meluluskan perubahan SPF, siapa boleh menetapkan semula akaun pekerja serta siapa menyiasat kegagalan notifikasi aplikasi. Produk hosting web terurus boleh mengurangkan kerja menyelenggara pelayan tanpa mengambil alih semua tanggungjawab platform e-mel luar. Rangkaian Biz/Power standard OnHypp memfokuskan e-mel profesional dan laman web biasa; pelan hosting aplikasi terurus tambahan tidak memasukkan kapasiti peti mel yang sama secara automatik. Pemisahan ini perlu jelas sebelum menyiasat masalah penghantaran atau mencadangkan naik taraf.
Gunakan senarai semak penyelesaian sebelum mengisytiharkan berjaya
Tutup tiket masalah penghantaran hanya apabila jenis kegagalan asal diuji melalui sistem yang bertanggungjawab. Bagi invois daripada perisian perakaunan, uji mesej templat invois yang dibenarkan kepada beberapa domain luar, semak keputusan pengesahan dan sahkan penerima boleh melihatnya. Untuk borang hubungan, uji penghantaran borang, respons pelayan dan penerimaan mesej secara berasingan. Simpan rekod nilai DNS sebelum dan selepas serta sebab setiap perubahan. Jangan menjanjikan penempatan Inbox untuk semua penerima kerana sistem penerima menentukan penapisan akhir. Jika masalah berterusan, eskalasikan bersama pengepala mesej yang dinyahkenal pasti dan bukti, bukannya mengubah rekod tidak berkaitan berulang kali.
Periksa hasil ujian mengikut penghantar yang sebenar
Semasa mengesahkan pembaikan, gunakan aplikasi yang menyebabkan masalah asal, bukan hanya menghantar e-mel ujian daripada akaun pentadbir. Notifikasi borang web, sistem invois dan mesej pekerja mungkin melalui pelayan serta pengesahan yang berbeza. Rekodkan masa, alamat ujian yang dibenarkan, keputusan mesej dan perubahan konfigurasi. Jika dua penghantar menggunakan domain sama tetapi hanya seorang gagal, jangan menganggap seluruh perkhidmatan e-mel telah rosak. Siasat aliran penghantaran khusus, semak log yang telah dinyahkenal pasti dan dapatkan persetujuan sebelum menukar rekod DNS.