Konfirmasikan pengaturan pengiriman Centercode
Pejabat Centercode panduan informasi teknis memberi label pada instruksinya yang berlaku untuk semua edisi. Ini menyatakan bahwa SPF otorisasi wajib bagi platform untuk mengirim atas nama domain email pelanggan, sementara itu DKIM bersifat opsional dan tersedia berdasarkan permintaan. Pertahankan perbedaan tersebut: alur kerja opsional DKIM penyedia tidak menghapus persyaratan organisasi atau penerima apa pun yang terpisah. Naskah ini menjelaskan rute layanan yang terdokumentasi, bukan konfigurasi penyewa yang diamati atau implementasi yang telah selesai.
Mulailah dengan mengidentifikasi penerapan Centercode, domain yang ditujukan untuk pesan keluar, dan pemilik domain yang bertanggung jawab. Jangan berasumsi bahwa nama host situs komunitas, alamat email terlihat dan sebenarnya pengirim amplop identik. Sebuah aplikasi dapat menggunakan alamat bermerek saat melakukan transmisi melalui infrastruktur yang dikendalikan oleh organisasi lain. Catatan penerimaan harus mengidentifikasi domain mana yang ingin dicakup oleh setiap bagian otentikasi sebelum siapa pun mengedit DNS .
Panduan umum tidak memaparkan tanggal publikasi petunjuk teknis dalam teks artikel yang disimpan. Oleh karena itu, penerapannya pada transaksi berjalan dan infrastruktur masih merupakan syarat pelepasan. Konfirmasikan instruksi saat ini dengan operator resmi, khususnya jika implementasi telah memindahkan infrastruktur atau mewarisi pengaturan dari komunitas sebelumnya. Baik tanggal footer maupun kampanye lama yang sukses tidak menunjukkan kompatibilitas teknis saat ini.
Pilih model otorisasi SPF yang terdokumentasi dengan sengaja
Contoh standar penyedia berisi include:_spf.centercode.com. Ia juga menawarkan model yang lebih sempit menggunakan alamat atau rentang IP khusus layanan yang diperoleh dari dukungan. Ini adalah pilihan perawatan yang berbeda. Penyertaan luasnya mengikuti ketergantungan otorisasi yang dipublikasikan penyedia; alamat dukungan yang dikeluarkan membatasi otorisasi pada infrastruktur yang teridentifikasi namun memerlukan perhatian ketika infrastruktur tersebut berubah. Panduan ini secara eksplisit memperingatkan bahwa peningkatan infrastruktur memerlukan pembaruan alamat resmi. Informasi teknis kode tengah
Jangan menyimpulkan alamat khusus implementasi dari situs web penyedia, URL komunitas, atau masuk data MX. Dapatkan nilai resmi aktual melalui proses dukungan terdokumentasi saat model tersebut diperlukan. Artikel ini tidak meminta alamat, menghubungi dukungan, atau mempublikasikan tebakan IP. Keputusan untuk menggunakan model yang lebih sempit harus melibatkan pemilik untuk pemberitahuan perubahan dan sebuah rekor implementasi yang alamat yang diberikan berlaku.
Sebelum menyetujui salah satu model, inventarisasi pengirim sah domain yang ada. Kebijakan ilustratif Centercode bukanlah pengganti lengkap kebijakan produksi perusahaan. Pertahankan otorisasi yang diperlukan, evaluasi pemesanan dan kualifikasi terminal, dan dokumentasikan perubahan yang sebenarnya. Layanan yang ditambahkan ke kebijakan seluruh domain dapat memengaruhi grup pesan yang berbeda dari yang diperkirakan pemilik kampanye pada awalnya.
Terapkan aturan protokol SPF daripada menyalin seluruh contoh
RFC 7208 , bagian 3.2 melarang beberapa catatan yang menyebabkan SPF memilih lebih dari satu kebijakan. Gabungkan mekanisme yang disetujui ke dalam satu kebijakan TXT yang koheren di pemilik yang relevan, alih-alih menambahkan kebijakan kedua yang bersaing. Contoh penyedia juga mencakup mx dan akhiran soft-fail; kehadirannya dalam sebuah contoh tidak membuktikan bahwa keduanya sesuai untuk setiap domain yang ada. Pertahankan keputusan pemilik kebijakan daripada mengubah perilaku yang tidak terkait sebagai efek samping.
Bagian 4.6.4 membatasi evaluasi persyaratan SPF yang bergantung pada DNS, termasuk evaluasi bertingkat. Ini bukan sekadar penghitungan string penyertaan, paket DNS , atau kesalahan cache yang terlihat. Menambahkan penyertaan Kode Tengah memerlukan peninjauan jalur yang berlaku di seluruh kebijakan. Mekanisme ip4 atau ip6 yang dikeluarkan dukungan memiliki perilaku pencarian yang berbeda, namun memilihnya masih menciptakan ketergantungan pemeliharaan yang dijelaskan di atas. Jumlah pencarian yang lebih rendah tidak cukup untuk membenarkan penyalinan alamat yang belum diverifikasi.
SPF mengevaluasi identitas yang ditentukan oleh transaksi SMTP . RFC 7208 , bagian 2.4 menjelaskan MAIL FROM, termasuk penanganan khusus pada jalur balik yang kosong. Catatan di domain Dari yang terlihat bukanlah bukti bahwa pesan tertentu menggunakan domain tersebut untuk evaluasi SPF . Catat identitas amplop sebenarnya selama pelaksanaan penerimaan resmi secara terpisah dan bandingkan dengan kebijakan yang sedang ditinjau.
Minta materi DKIM khusus implementasi
Rute DKIM yang didokumentasikan Centercode dimulai dengan permintaan dukungan dari obrolan implementasi atau saluran dukungan yang dinyatakan. Tim IT-nya mengembalikan kunci publik untuk administrator DNS pelanggan. Panduan ini menjelaskan tentang cc. _pemilik _domainkey di bawah domain pelanggan dan nilai TXT DKIM yang dibuat dari kunci publik yang disediakan. Gunakan instruksi spesifik implementasi dan domain yang dituju secara tepat; jangan menyalin domain placeholder panduan atau membuat materi kunci. Meminta dukungan DKIM
Kunci verifikasi publik bukanlah kunci penandatanganan pribadi. Alur kerja ini tidak mengharuskan pelanggan untuk mendapatkan atau mendistribusikan materi penandatanganan pribadi penyedia. Simpan kunci publik yang diterima, nama pemilik, dan referensi akun bersama-sama sehingga peninjau DNS dapat membedakan konfigurasi yang diminta dari kunci tidak terkait yang sudah ada di zona tersebut. Jika sudah ada pemilih pemilik bertentangan dengan nilai yang diusulkan, berhenti untuk transisi terkoordinasi daripada menimpanya tanpa menilai penggunaan aktif.
Panduan ini menetapkan cara meminta dan mempublikasikan materi yang disediakan, namun tidak membuktikan bahwa penandatanganan telah diaktifkan untuk akun tertentu. Catat konfirmasi penyelesaian penyedia apa pun secara terpisah dari perubahan DNS . RFC 6376 , bagian 3.5 mendefinisikan domain tanda tangan dan bidang pemilih. Bidang-bidang tersebut dalam sampel pesan diterima yang sah mengidentifikasi kunci mana yang sebenarnya digunakan oleh pesan tersebut; kunci yang dipublikasikan saja tidak menunjukkan bahwa penandatangan menggunakannya.
Pisahkan DMARC dan penerimaan pengiriman
Panduan Centercode menetapkan DMARC kepada pemilik domain pelanggan. Tinjau rute platform bersama pengirim organisasi lainnya sebelum mengubah kebijakan. Permintaan dukungan untuk kunci DKIM tidak mengizinkan tujuan pelaporan baru atau perubahan penerapan di seluruh domain. Simpan keputusan tersebut pada pemilik yang sesuai dan dokumentasikan cakupannya secara independen.
RFC 9989 , bagian 4.4 menjelaskan bahwa DMARC memerlukan hubungan antara domain penulis yang terlihat dan pengidentifikasi yang diautentikasi lewat. Hasil SPF yang selaras atau hasil DKIM yang selaras dapat memenuhi kondisi autentikasi tersebut. Jangan menerjemahkan prasyarat SPF wajib Centercode menjadi klaim protokol yang secara universal DMARC memerlukan kedua mekanisme tersebut untuk dapat dilewati. Demikian pula, tanda tangan penyedia yang tidak terkait tidak dibuat penyelarasan dengan domain pelanggan.
Penyedia menyarankan pencarian SPF publik sebagai satu pemeriksaan. Hal ini dapat membantu menetapkan publikasi, namun tidak dapat menentukan penandatanganan aktual, penerimaan penerima, atau penempatan kotak masuk. Tinjauan penerimaan lengkap yang diusulkan memisahkan DNS publik, konfigurasi penyedia, dan observasi penerima tepercaya. Gunakan konten pengujian yang tidak berbahaya daripada masukan peserta, deskripsi produk rahasia, atau data anggota komunitas. Tidak ada pengiriman, kueri, atau pesan pemeriksa eksternal yang dilakukan untuk panduan ini.
Diagnosis fiktif dan lembar kerja penerimaan kosong
Tim perangkat keras fiksi, Harbour Finch, menggunakan alamat dukungan yang dikeluarkan untuk implementasi Centercode-nya. Setelah pemindahan infrastruktur yang direncanakan, tim tetap mempertahankan otorisasi lama karena situs komunitas masih memuat secara normal. Peninjaunya mengidentifikasi ketergantungan yang hilang: ketersediaan situs web bukanlah bukti bahwa alamat layanan keluar tetap sama. Solusi yang diusulkan adalah mengkonfirmasi rute baru dengan operator yang bertanggung jawab, meninjau perubahan resmi dan mengumpulkan bukti pesan baru. Ini adalah kasus fiktif, bukan insiden terukur atau migrasi yang dilakukan.
- Implementasi, edisi dan konfirmasi instruksi saat ini: ______
- Domain penulis yang dituju dan identitas amplop yang diamati: ______
- Standar termasuk atau dukungan yang dikeluarkan alamat keputusan dan pemilik: ______
- Kebijakan TXT yang ada, perubahan yang disetujui, dan tinjauan evaluasi: ______
- Pemberitahuan migrasi infrastruktur dan tanggung jawab pemeliharaan: ______
- Referensi permintaan DKIM , pemilik publik, kunci dan konfirmasi penandatanganan: ______
- Identitas pesan yang diterima dan hasil penyelarasan: ______
- Pemilik kebijakan DMARC , ketergantungan yang belum terselesaikan dan keputusan rilis: ______
Bukti implementasi katalog yang tepat, penerapan saat ini, tinjauan materi pelajaran oleh manusia, jalur produksi, aksesibilitas visual, dan rilis pemilik tetap terbuka. Artikel ini merupakan draf dokumenter, bukan bukti bahwa penyewa, zona DNS , atau aliran pesan telah dikonfigurasi atau diuji.