Cakupan: Hosting bersama Afrihost dan cPanel
Afrihost menerbitkan instruksi terpisah untuk mendapatkan catatan otentikasi di cPanel dan menambahkannya melalui Editor DNS Hosting Bersama ClientZone. Panduan ini mengikuti rute yang terdokumentasi itu. Ini tidak berarti bahwa Afrihost Pure Mail, penyedia kotak surat eksternal, atau setiap paket hosting menggunakan catatan atau kontrol penandatanganan yang identik. Tetapkan produk email aktual dan layanan DNS resmi sebelum menyiapkan perubahan. Nilai khusus akun dan penerapan antarmuka saat ini masih belum diverifikasi.
Penyedia SPF instruksi pembuatan menggunakan area Keterkiriman Email cPanel: pilih Kelola di samping domain, temukan SPF , dan salin Nilainya. Dia DKIM instruksi menggunakan area yang sama dan tindakan Instal Catatan yang Disarankan. Ini adalah langkah-langkah operator yang diusulkan, bukan tindakan yang dilakukan untuk naskah ini. Generasi SPF Afrihost Afrihost generasi DKIM
Generasi terpisah, publikasi dan penandatanganan
Catatan yang disarankan adalah bukti dari apa yang direkomendasikan oleh antarmuka konfigurasi tertentu. Ini bukan bukti bahwa zona otoritatif publik mengandung nilai tersebut atau bahwa sebuah pesan telah ditandatangani dan berhasil diverifikasi. Pertahankan konteks domain di samping data yang disarankan. Administrator yang menyalin nilai dari akun hosting yang salah dapat menghasilkan permintaan perubahan yang tampak masuk akal namun tidak relevan.
Untuk DKIM , bedakan materi verifikasi publik dengan materi penandatanganan pribadi. Catatan DNS berisi informasi kunci publik. Kunci pribadi tidak boleh dikumpulkan di lembar kerja penerimaan atau ditempelkan ke dalam tiket. Protokol menghubungkan tanda tangan pesan ke domain penandatanganan dan pemilih; pengidentifikasi tersebut menentukan di mana verifikator mencari kuncinya. Domain atau label akun umum yang serupa secara visual tidak dapat menggantikannya. RFC 6376 , DKIM-Signature dan penyimpanan kunci
Artikel pembuatan DKIM Afrihost mengatakan bahwa catatan tersebut dapat disalin ke cluster DNS domain setelah catatan yang disarankan diinstal. Perlakukan ini sebagai alasan untuk menentukan siapa yang sebenarnya melayani DNS otoritatif. Tampilan hosting lokal dan zona publik yang dioperasikan secara eksternal mungkin memerlukan kepemilikan publikasi yang berbeda. Jangan menyimpulkan bahwa catatan publik berubah hanya karena antarmuka lokal menampilkan pemberitahuan sukses. Afrihost generasi DKIM
Siapkan perubahan SPF tanpa membuang pengirim lain
Jalur ClientZone yang terdokumentasi adalah Hosting, domain di bawah Hosting Bersama, Pengaturan Hosting, Editor DNS , lalu Buat Catatan Baru. Untuk SPF , artikel tersebut menentukan TXT , bidang prioritas kosong, konten SPF yang disalin, dan TTL 7200. Resep antarmuka tersebut tidak membenarkan pembuatan kebijakan SPF kedua jika sudah ada. Tinjau kebijakan yang ada dan gabungkan hanya perubahan otorisasi yang disetujui. Publikasi Afrihost SPF
SPF mengevaluasi identitas SMTP , termasuk KIRIM DARI, daripada hanya mempercayai bidang Dari yang dapat dibaca manusia. Aplikasi inventaris yang mengirimkan identitas yang relevan sebelum mengubah kebijakannya. Pengiriman kotak surat yang dihosting, pemberitahuan situs web, dan alat pemasaran luar mungkin memiliki cakupan dan infrastruktur yang berbeda. Jangan berasumsi bahwa cPanel default mencakup semua layanan yang diadopsi organisasi. RFC 7208 , HELO dan MAIL DARI identitas
Simpan satu kebijakan SPF yang berlaku atas nama pemilik. Tinjau penyertaan bertingkat dan persyaratan kueri DNS lainnya terhadap batas jangka waktu protokol yang dievaluasi. Kebijakan tingkat atas yang pendek masih dapat mempunyai jalur ketergantungan yang berlebihan. Catat metode peninjauan dan waktu pembuktian, namun jangan menyebut rencana yang belum dilaksanakan sebagai evaluasi langsung yang berhasil. Jawaban yang di-cache tidak mengesampingkan aturan evaluasi. RFC 7208 , beberapa catatan dan batas pencarian DNS
Selesaikan ambiguitas nama pemilik DKIM sebelum dipublikasikan
Halaman publikasi DKIM Afrihost menjelaskan rute ClientZone dan menempelkan nilai TXT DKIM . Namun, teksnya menyertakan judul instruksi berlabel SPF dan bidang nama domain umum, bukan pemilik pemilih khusus akun yang lengkap. Detail tersebut bukanlah dasar yang aman untuk membuat catatan puncak DKIM . Dapatkan dan tinjau nama dan nilai lengkap yang dihasilkan untuk domain sebenarnya, dan selesaikan konvensi penamaan editor sebelum mengizinkan publikasi. Publikasi Afrihost DKIM
Di bawah DKIM , domain pemilih dan penandatanganan membentuk nama pencarian kunci di bawah _domainkey . Pemilih sebenarnya harus berasal dari konfigurasi akun yang didukung dan cocok dengan pesan yang ditandatangani. Jangan berikan pemilih yang dapat ditebak hanya karena layanan lain menggunakannya. Aturan yang sama berlaku untuk kunci publik yang disalin: sintaksisnya saja tidak menetapkan bahwa penandatangan yang dituju memegang kunci pribadi yang sesuai. RFC 6376 , penyimpanan kunci
Konfirmasikan apakah editor mengharapkan label relatif atau nama pemilik lengkap. Konvensi file master DNS mencakup asal saat ini, namun editor grafis adalah antarmuka produk dan memerlukan interpretasinya sendiri. Kriteria penerimaannya adalah nama pemilik yang dihasilkan sepenuhnya memenuhi syarat, bukan apakah operator mengetikkan steno yang familiar. RFC 1035 , format file master
Menafsirkan hasil autentikasi secara sempit
Beberapa kata pengantar penyedia menjelaskan DKIM sebagai mencegah spam atau meningkatkan pengiriman. Jangan jadikan deskripsi itu sebagai jaminan. DKIM menyediakan tanda tangan kriptografi dan identitas penandatanganan yang dapat diatribusikan; ini bukan enkripsi isi pesan dan tidak menetapkan bahwa setiap instruksi bisnis dalam pesan aman. Tanda tangan yang sah juga berbeda dengan DMARC penyelarasan. RFC 6376 , pengantar
Untuk rute pengiriman sebenarnya, tinjauan penerimaan harus menghubungkan identitas SPF atau DKIM yang meneruskan ke domain penulis yang terlihat. DMARC dapat melewati mekanisme kualifikasi yang selaras. Catatan DNS yang ada secara terpisah tidak membentuk hubungan tersebut untuk sebuah pesan. Otentikasi juga tidak menjamin pengiriman, melewati pemfilteran penerima, atau membuktikan bahwa akun tidak disalahgunakan. RFC 9989 , penyelarasan dan cakupan pengidentifikasi
Diagnosis fiktif: pemilik publikasi yang salah
Bayangkan sebuah asosiasi fiksi bernama Cedar Trail Club. Relawannya memperoleh data DKIM yang disarankan dari domain cPanel yang benar, lalu hanya menyalin nilainya ke dalam permintaan perubahan DNS . Operator lain menganggap rekaman tersebut berada di akar karena permintaan tersebut tidak berisi pemilik pemilih. Ini adalah skenario perencanaan yang dibuat-buat, bukan klaim tentang pelanggan Afrihost atau pengujian yang dilakukan di sini.
Peninjau menolak permintaan yang tidak lengkap tanpa menebak pemilihnya. Pemilik aplikasi harus memberikan catatan publik lengkap yang dihasilkan dan mengidentifikasi rute penandatanganan yang dimaksudkan. Operator DNS harus mengonfirmasi zona otoritatif dan nama pemilik yang dihasilkan. Pemilik rilis kemudian memerlukan bukti pesan aktual, yang diperoleh melalui proses resmi, sebelum menerima penandatanganan dan penyelarasan. Pelajaran perbaikannya adalah menjaga hubungan antara konteks yang dihasilkan, lokasi kunci publik, dan identitas pesan daripada memperlakukan nilai yang ditempelkan sebagai konfigurasi lengkap.
Lembar kerja penerimaan operasional kosong
Lembar kerja ini adalah sebuah proposal. Tidak ada sel yang diisi sebelumnya dengan hasil akun yang diciptakan.
- Produk hosting, paket, dan konteks domain: ______
- Operator cPanel resmi dan referensi persetujuan: ______
- Penyedia DNS resmi dan pemilik zona: ______
- Kebijakan SPF yang ada dan inventaris pengirim yang sah: ______
- Nilai SPF yang disarankan dan meninjau kebijakan gabungan: ______
- Nama lengkap pemilik DKIM dan nilai publik yang dihasilkan: ______
- Interpretasi nama editor dan pemeriksaan konflik: ______
- Pengamatan catatan publik, stempel waktu dan ruang lingkup: ______
- Pemilih pesan aktual, domain penandatanganan, dan identitas amplop: ______
- Bukti otentikasi dan penyelarasan: ______
- Rollback, pemilik yang bertanggung jawab dan keputusan pelepasan: ______
Publikasi dan operasional ditahan
Penerapan akun, kontrol produk saat ini, publikasi DNS , aktivasi penandatanganan, dan verifikasi pesan yang diterima tetap terbuka. Tidak ada akun yang diakses, tidak ada catatan yang disarankan dipasang, tidak ada catatan DNS yang dibuat, dan tidak ada pesan pengujian yang dikirim. Tinjauan materi pelajaran manusia, penerapan sumber, bukti katalog asli, rute produksi, aksesibilitas visual, dan pelepasan pemilik juga terbuka. Draf tersebut tidak menggantikan bukti implementasi yang diperlukan dalam katalog dengan diagnosis fiktif ini atau dengan kata-kata keberhasilan instruksional dari penyedia layanan.