Asingkan kegagalan menerima dan menghantar
Apabila e-mel perniagaan terganggu, soalan pertama ialah sama ada mesej gagal diterima, gagal dihantar atau hanya bermasalah bagi penerima tertentu. Penerimaan banyak bergantung pada penghalaan MX serta perkhidmatan peti mel penerima. Penghantaran pula melibatkan platform penghantar, pengesahan, polisi penerima dan kadangkala tetapan aplikasi pengguna. DNS boleh mempengaruhi kedua-duanya, tetapi mesej hilang tidak membuktikan DNS menjadi punca. Kumpulkan contoh tepat bersama penghantar, penerima, anggaran masa dan ralat pemulangan tanpa mendedahkan kandungan pelanggan. Gejala yang jelas mengelakkan perubahan DNS rambang yang mungkin memburukkan gangguan kecil.
Cari zon DNS berautoriti sebelum menyunting
Perniagaan mungkin mendaftarkan domain dengan satu syarikat, menempatkan laman web di tempat lain dan menerima e-mel melalui pembekal ketiga. Papan pemuka DNS yang biasa dilihat tidak semestinya berautoriti. Penyelesai DNS awam mengikuti pelayan nama yang diwakilkan, maka menyunting salinan zon yang terpisah mungkin tidak memberi kesan. Kenal pasti pelayan nama berautoriti semasa dan bandingkan jawapan awam dengan rekod pembekal yang dimaksudkan. Simpan zon sedia ada serta sejarah perubahan sebelum sebarang pindaan diluluskan. Jangan menukar pelayan nama semata-mata untuk membaiki satu rekod mel kerana perubahan itu boleh menjejaskan laluan laman, rekod pengesahan dan perkhidmatan lain serentak.
Fahami fungsi sebenar rekod MX
Rekod mail exchanger mengenal pasti tempat sistem mel lain patut cuba menyerahkan e-mel masuk bagi sesuatu domain. Rekod ini tidak mencipta peti mel pengguna atau membenarkan penghantar keluar dengan sendirinya. MX lazimnya menamakan hos mel serta mempunyai nombor keutamaan; nombor lebih rendah diberi keutamaan apabila beberapa destinasi sah wujud. Menyalin nama hos daripada akaun tidak berkaitan boleh menghala mesej ke infrastruktur salah. Bandingkan jawapan MX awam dengan arahan semasa pembekal mel bagi domain sebenar. Sahkan juga destinasi tersebut boleh dicari melalui DNS dan perkhidmatan penerima mengenali domain serta peti mel yang dimaksudkan.
Elakkan mencampurkan pembekal MX yang tidak berkaitan
Kesilapan migrasi yang lazim ialah membiarkan rekod MX lama bersama rekod pembekal baharu tanpa reka bentuk penghalaan yang disengajakan. Sesetengah penghantar mencuba destinasi utama dahulu dan yang lain menggunakan laluan sandaran apabila ia tidak tersedia. Jika sandaran menuju kepada pembekal lama tanpa peti mel terkini, mesej mungkin dipulangkan, tersimpan dalam giliran atau sampai ke tempat salah. Beberapa rekod MX tidak semestinya ralat; yang penting ialah sama ada set lengkap melaksanakan seni bina penerimaan yang dimaksudkan. Tanya pembekal destinasi serta keutamaan yang sah untuk akaun dan buang entri usang hanya melalui pelan pertukaran yang diluluskan.
Semak nama hos mel dan rekod alamat
Destinasi MX perlu menuju kepada nama pelayan mel yang boleh digunakan. Kesilapan ejaan nama hos, rekod alamat yang tiada atau subdomain diwakilkan secara salah boleh memutuskan laluan walaupun baris MX kelihatan munasabah. Cloudflare mendokumentasikan keadaan apabila MX menuju subdomain yang rekod alamatnya diurus penyedia DNS lain. Semak keseluruhan rantaian penyelesaian nama, bukan jawapan pertama sahaja. Rekod A laman web dan rekod A atau AAAA pelayan mel mungkin berbeza dan tidak patut diubah bersama tanpa bukti. Ujian berkaitan ialah sama ada perkhidmatan penerima yang dinamakan benar-benar boleh menerima mesej bagi domain tersebut.
Jangan proksikan protokol mel biasa melalui proksi HTTP
Proksi HTTP biasa Cloudflare yang ditandakan awan jingga tidak membawa trafik SMTP, IMAP atau POP3 biasa. Jika nama hos mel menuju kepada alamat proksi dan bukannya destinasi mel sebenar pembekal, aplikasi atau sistem penghantar mungkin gagal bersambung. Rekod MX sendiri tidak diproksikan melalui awan jingga, tetapi rekod alamat bagi nama hos sasarannya boleh tersalah konfigurasi. Sahkan sama ada hos berkaitan mel perlu menggunakan mod DNS-only mengikut seni bina pembekal. Jangan mematikan proksi bagi rekod laman web yang tidak berkaitan hanya kerana e-mel gagal. Dokumentasi penyelesaian masalah Cloudflare menerangkan perbezaan ini serta pengecualian bagi perkhidmatan khusus.
Fahami penghalaan mel setempat dan jauh dalam cPanel
Panel hosting boleh mempunyai tetapan penghalaan mel yang berasingan daripada rekod MX awam. cPanel membezakan tingkah laku Local Mail Exchanger, Backup Mail Exchanger dan Remote Mail Exchanger. Jika laman web berada pada satu pelayan tetapi peti mel menggunakan pembekal luar, tetapan penghalaan setempat yang salah mungkin menyebabkan aplikasi web cuba menyerahkan mesej secara setempat dan bukannya kepada perkhidmatan luar. cPanel menyatakan pengesanan automatiknya menggunakan zon setempat dan tidak menjalankan carian DNS awam secara langsung. Sahkan DNS awam serta konfigurasi penghalaan pelayan sebenar dengan hos yang dibenarkan; jangan anggap satu pemeriksaan membuktikan yang lain.
Bezakan SPF daripada laluan menerima e-mel
SPF ialah polisi kebenaran penghantar keluar, bukan alamat pelayan peti mel masuk. Domain boleh menerima e-mel melalui satu pembekal sementara beberapa perkhidmatan sah menghantar bagi pihaknya. Menyalin SPF yang hanya menyenaraikan hos peti mel mungkin mengecualikan pemberitahuan invois atau aplikasi sokongan. Sebaliknya, menambah destinasi MX masuk kepada SPF tanpa memastikan ia menghantar e-mel keluar boleh membenarkan infrastruktur yang tidak perlu. Inventorikan setiap sumber penghantaran sebenar dan ikuti arahan SPF rasmi pembekal. Nilai TXT yang kelihatan sah tidak mencukupi: polisi SPF berkesan mesti mempunyai sintaks betul, mematuhi had carian dan sepadan dengan tingkah laku penghantaran sebenar.
Awasi polisi SPF TXT yang berganda
Semasa pertukaran pembekal, pentadbir mungkin menambah rekod TXT v=spf1 kedua dan bukannya mengemas kini polisi sedia ada. RFC 7208 tidak membenarkan beberapa rekod SPF bagi nama domain sama, dan penerima boleh menghasilkan permerror. Domain boleh mempunyai beberapa rekod TXT untuk tujuan lain, jadi penyelesaiannya bukan memadam semua entri TXT. Kenal pasti nilai khusus SPF dan gabungkan semua sumber penghantaran yang dibenarkan ke dalam satu rekod tersusun. Uji jawapan awam berkesan selepas perubahan diluluskan. Jangan menggabungkan rekod secara membuta tuli; include bersarang boleh melebihi bajet carian DNS spesifikasi walaupun teks akhir kelihatan pendek.
Semak pemilih DKIM dan sasaran rekod
DKIM mengesahkan tandatangan kriptografi menggunakan kunci awam yang diterbitkan di bawah domain penandatangan serta pemilih. Rekod pemilih yang tiada, nilai TXT salah atau sasaran CNAME rosak boleh menyebabkan mesej gagal DKIM walaupun penghantar sah. Sesetengah pembekal memerlukan kunci TXT, manakala yang lain meminta pelanggan menerbitkan CNAME kepada kunci yang diurus pembekal. Gunakan kaedah yang didokumentasikan bagi akaun sebenar. Cloudflare memberi amaran bahawa CNAME flattening boleh mengganggu jawapan CNAME DKIM atau autodiscover yang diperlukan sesetengah pembekal. Semak jawapan DNS awam serta pengepala mesej bertandatangan sebenar dan jangan menganggap nilai yang disimpan dalam panel sudah mencukupi.
Jangan kelirukan polisi DMARC dengan penghantaran peti mel
DMARC menerbitkan polisi pengendalian yang diminta bagi mesej yang gagal pemeriksaan SPF atau DKIM sejajar. Ia bukan rekod MX dan tidak mencipta peti mel. Perniagaan boleh mempunyai penghalaan MX masuk yang betul sedangkan mesej keluar gagal DMARC kerana penghantar pihak ketiga menggunakan domain tandatangan tidak berkaitan. Begitu juga, polisi reject yang agresif sebelum penghantar sah diuji boleh mengganggu pemberitahuan sebenar. Periksa domain From yang dipaparkan, domain sampul dan domain penandatangan DKIM, kemudian nilai hasil pengesahan mesej. Destinasi laporan serta perubahan polisi memerlukan pemilik dan pelan berperingkat. Jangan gunakan DMARC sebagai pengganti siasatan peti mel masuk yang hilang.
Berhati-hati dengan nama rekod dan format panel DNS
Antara muka DNS berbeza dalam cara mentafsir medan nama hos. Sesetengahnya menjangka label relatif seperti _dmarc atau pemilih DKIM, manakala yang lain menerima nama domain lengkap. Memasukkan domain penuh ke medan yang menambah nama zon secara automatik boleh menghasilkan nama berganda yang tidak dimaksudkan. Tanda petikan tambahan, pemisah hilang atau ruang yang disalin juga boleh mengubah nilai TXT berkesan. Sebelum menyimpan, semak arahan pembekal serta pratonton nama DNS lengkap yang akan terhasil. Selepas suntingan diluluskan, buat carian rekod awam pada nama tepat yang dimaksudkan. Tangkapan layar borang sebelum disimpan bukan bukti penerbitan.
Ambil kira caching DNS dan TTL
Jawapan DNS disimpan sementara oleh penyelesai mengikut nilai time-to-live dan tingkah laku caching lain. Selepas perubahan, satu penyelesai mungkin menunjukkan MX atau TXT baharu sedangkan yang lain masih memaparkan nilai lama. Keadaan ini tidak semestinya bermaksud pembekal mengabaikan suntingan. Rekodkan masa perubahan, nilai terdahulu, TTL dijangka dan pelayan nama berautoriti yang menjawab rekod baharu. Elakkan suntingan berulang tanpa rancangan sementara menunggu cache tamat kerana setiap perubahan menyukarkan diagnosis. Jadual migrasi selamat merangkumi pertindihan, pemantauan serta tempoh pemulihan dipersetujui. Penyebaran DNS bukan janji bahawa semua sistem mel akan bertukar pada saat sama.
Asingkan perubahan laman web daripada e-mel
Memindahkan laman web tidak semestinya memerlukan pemindahan e-mel perniagaan. Rekod A atau CNAME bagi laman boleh berubah sedangkan MX, rekod alamat mel dan TXT pengesahan kekal bersama pembekal sedia ada. Sebaliknya, menukar pelayan nama berautoriti semasa migrasi laman boleh menjejaskan e-mel jika zon baharu tidak menyalin rekod diperlukan. Sediakan inventori yang membezakan laluan web, mel masuk, pengesahan penghantar keluar dan entri pengesahan pihak ketiga. Bandingkan zon lama dengan cadangan sebelum pertukaran pelayan nama. Jangan anggap sebut harga hosting web memberi izin menggantikan perkhidmatan peti mel atau mengubah DNS aktif. Ini keputusan pemilik yang berasingan.
Contoh andaian gangguan selepas pemindahan laman
Bayangkan pembekal kecil yang laman baharunya dimuat dengan baik selepas pertukaran hosting tetapi pelanggan melaporkan e-mel sebut harga dipulangkan. Pasukan mendapati zon DNS baharu mengandungi rekod A laman tetapi tidak mempunyai MX serta rekod pengesahan pembekal e-mel lama. Siasatan sesuai bermula dengan zon berautoriti dan inventori rekod yang disimpan, bukan tekaan bahawa kata laluan peti mel salah. Pelan pemulihan terkawal memerlukan kelulusan, pengesahan pembekal serta ujian masuk dan keluar. Senario ini andaian; ia menunjukkan bahawa migrasi laman yang kelihatan berjaya tidak membuktikan semua komunikasi perniagaan masih berfungsi.
Uji kedua-dua arah penghantaran dengan bukti sebenar
Selepas pembetulan DNS dicadangkan diluluskan serta dilaksanakan pengendali yang dibenarkan, uji penerimaan daripada peti mel luar dan penghantaran kepada lebih daripada satu destinasi berkaitan. Semak pengepala mesej, hasil pengesahan dan butiran pemulangan. Mesej daripada akaun sendiri kepada akaun sendiri dalam pembekal sama mungkin tidak melalui laluan awam, maka ia membuktikan sedikit tentang penghantaran internet. Uji laluan penghantar pihak ketiga sebenar bagi invois, pertanyaan laman dan pemberitahuan jika termasuk dalam skop. Pastikan mesej ujian tidak mengandungi rahsia pelanggan dan rekodkan masa serta hasil. Pemeriksa DNS hijau berguna tetapi tidak menggantikan ujian aliran mel lengkap.
Kenal pasti masalah yang bukan berpunca daripada DNS
Rekod MX awam serta pengesahan yang betul tidak menjamin peti mel individu wujud, mempunyai ruang simpanan atau dibenarkan menghantar. Pembekal mungkin menolak mesej kerana alamat tidak dikenali, kuota penuh, akaun digantung atau pelayan penerima menggunakan polisi keselamatan. Aplikasi e-mel setempat juga boleh gagal log masuk walaupun DNS domain sihat. Baca kod ralat tepat dan rujuk pentadbir mel yang bertanggungjawab sebelum menyunting rekod. Bezakan kegagalan carian DNS daripada penolakan penghantaran dan masalah log masuk aplikasi. Setiap masalah mempunyai pemilik serta langkah pembetulan yang berbeza.
Simpan rekod perubahan dan pelan pemulihan
Sebelum sebarang pindaan DNS aktif, rekodkan nama pemilik, jenis, nilai lama, nilai dicadangkan, perkhidmatan terjejas serta pelulus dibenarkan. Simpan salinan lengkap zon dan kenal pasti cara memulihkan keadaan asal. Jadualkan perubahan ketika orang bertanggungjawab boleh memantau e-mel masuk serta keluar dan elakkan migrasi tidak berkaitan yang bertindih. Jika pembekal mengesyorkan menggantikan semua rekod, minta penerangan bertulis tentang entri usang dan entri yang mesti dikekalkan. Rekod perubahan membantu membezakan insiden baharu daripada kegagalan sedia ada. Senarai pendidikan ini tidak memberi kebenaran mengakses atau mengubah sistem produksi OnHypp atau pelanggan.
Urutan keputusan penyelesaian masalah yang ringkas
Mulakan dengan arah kegagalan, contoh mesej serta ralatnya. Kenal pasti perkhidmatan DNS berautoriti, kemudian bandingkan MX awam, alamat hos mel, SPF, DKIM dan DMARC dengan arahan pembekal sebenar. Semak sama ada penghalaan setempat hos web, status proksi atau subdomain diwakilkan mempengaruhi laluan. Teliti perubahan terkini dan ambil kira caching DNS sebelum membuat kesimpulan. Jika rekod awam betul, siasat kewujudan peti mel, status akaun, peraturan penghantaran dan pengesahan aplikasi bersama pembekal. Hanya pengendali dibenarkan patut membuat perubahan berskop, menyimpan bukti pemulihan dan menguji kedua-dua arah selepas itu. Elakkan pembaikan menyeluruh berdasarkan satu tangkapan layar.
Sumber & bacaan lanjut
Bersedia melihat perkhidmatan berkaitan?
Lihat perkhidmatan OnHypp yang berkaitan dan tentukan sama ada ia sesuai dengan keperluan perniagaan anda.
E-mel & hostingPenjagaan webDomain