Bangun dari pengirim yang disetujui, bukan daftar penyedia yang dapat ditebak
Sebuah SPF pembangun harus mempertahankan keputusan eksplisit organisasi tentang sistem mana yang dapat menggunakan identitas SMTP tertentu. Daftar penyedia populer yang mudah dipahami tidak dapat memastikan bahwa layanan tersebut diotorisasi untuk domain tersebut, bahwa mekanisme yang direkomendasikan adalah yang terbaru, atau bahwa data yang dihasilkan sesuai dengan batas pencarian. Outputnya harus berupa proposal beranotasi yang dikaitkan dengan kepemilikan pengirim, bukan otorisasi luas yang dikumpulkan dari pengenalan merek.
RFC 7208 mendefinisikan publikasi dan evaluasi SPF . Artikel ini mengusulkan persyaratan untuk pembuat dan proses peninjauannya. Itu tidak mengklaim bahwa EmailAuth menawarkan fitur pembuat tertentu, menghasilkan catatan produksi atau memodifikasi DNS . Tidak ada akun pemasok, kredensial pribadi, atau catatan domain pengguna yang diperiksa. Keluaran asli dan bukti pengujian tetap terbuka.
Inventarisasi identitas dan pemilik SMTP yang sebenarnya
Untuk setiap alur kerja, catat tujuan bisnis, pemilik layanan yang disetujui, layanan pengiriman, yang relevan KIRIM DARI atau Identitas HELO dan sumber izin yang diusulkan. SPF tidak secara langsung mengautentikasi nama tampilan Dari yang terlihat. Penyedia yang digunakan oleh satu tim tidak boleh secara otomatis ditambahkan ke setiap tim domain organisasi. Identitas dan hubungan layanan yang dimaksud memerlukan konfirmasi eksplisit dari pemilik yang bertanggung jawab.
RFC 9989 mendefinisikan penyelarasan hubungan yang diperlukan agar SPF dapat berkontribusi DMARC. Seorang pembangun harus menjelaskan bahwa otorisasi SPF dan penyelarasan DMARC saling berkaitan namun merupakan keputusan yang terpisah. Menambahkan penyedia ke Catatan SPF tidak menjamin bahwa penyedia menggunakan identitas tersebut dalam surat yang sebenarnya. Pemilik integrasi harus menyediakan konfigurasi saat ini dan bukti pesan resmi saat memverifikasi alur kerja.
Gunakan instruksi penyedia saat ini tanpa memperluas cakupan
Target penyertaan atau rentang alamat yang tepat harus berasal dari dokumentasi resmi terkini atau konfigurasi resmi untuk layanan sebenarnya. Jangan menyimpulkannya dari catatan pelanggan lain, tutorial lama, atau produk dengan nama serupa. Catat tanggal bukti dan pemilik bertanggung jawab melacak perubahan penyedia. Naskah ini tidak menyertakan nilai penyedia penemuan karena tidak ada konfigurasi pengirim tertentu yang disetujui untuk konstruksi.
Mekanisme IP langsung dan ketergantungan yang didelegasikan mempunyai kewajiban pemeliharaan yang berbeda. Alamat statis dapat menghindari anggaran jangka pencarian yang sama seperti mekanisme penyebab permintaan DNS, namun menyalin alamat penyedia saat ini ke dalam sebuah rekor bisa menjadi basi ketika penyedia mengubah infrastruktur. Pembangun tidak boleh secara diam-diam meratakan ketergantungan sebagai pengoptimalan tanpa model pemeliharaan yang disetujui. Pertahankan trade-off dan keputusan pemilik dalam anotasi.
Menghasilkan satu kebijakan SPF yang koheren
RFC 7208 memerlukan satu catatan SPF untuk identitas yang dievaluasi; memublikasikan beberapa data SPF bukanlah cara yang valid untuk menggabungkan beberapa layanan. Oleh karena itu, perubahan yang diusulkan harus menjelaskan bagaimana pengirim resmi yang ada dipertahankan dalam satu kebijakan yang koheren. Seharusnya tidak hanya menginstruksikan operator untuk menambahkan data v=spf1 lain di samping data yang sudah ada. Tidak berhubungan catatan TXT tidak boleh dihilangkan sebagai efek samping.
RFC 1035 mendefinisikan struktur data TXT . Beberapa string karakter dalam satu data TXT berbeda dengan beberapa data TXT , sehingga tampilan pembuat dan perlengkapan pengujian harus mempertahankan perbedaan tersebut. Editor dapat memformat nilai panjang secara berbeda dari representasi kawatnya. Perbedaan persis yang disetujui harus menentukan kumpulan data yang diinginkan, bukan mengandalkan tangkapan layar dari satu bidang.
Menjelaskan mekanisme, kualifikasi dan pengubah
Setiap istilah yang dihasilkan harus memiliki pemilik dan alasan. Melibatkan delegasi dalam melakukan evaluasi sesuai dengan pemetaan hasil standar; redirect adalah pengubah dengan semantik berbeda dan diabaikan jika semua mekanisme ada. Seorang pembangun tidak boleh menukarnya hanya karena keduanya mereferensikan domain lain. Kualifikasi mempengaruhi hasil yang terkait dengan mekanisme pencocokan dan harus dipilih melalui keputusan kebijakan yang eksplisit.
Jangan menyiratkan bahwa menambahkan semua membuat setiap konfigurasi aman. Penempatan dan kualifikasi penting, dan otorisasi yang terlalu luas dapat menggagalkan batasan yang dimaksudkan. Sebaliknya, akhiran yang membatasi dapat memengaruhi pengirim sah yang dihilangkan dari inventaris. Pembangun harus menampilkan alur kerja yang belum terselesaikan dan memerlukan persetujuan sebelum dipublikasikan daripada memilih postur risiko bisnis secara otomatis dari template.
Periksa batas evaluasi tanpa membingungkan penghitungan
RFC 7208 bagian 4.6.4 membatasi evaluasi istilah penyebab kueri DNS seperti include, a, mx, ptr, ada dan pengalihan ke sepuluh. Ini bukan batasan sepuluh nama penyedia yang terlihat atau sepuluh paket mentah. Ketergantungan bersarang dan jalur pencocokan sebenarnya penting. Pembangun harus memberikan tinjauan ketergantungan dan mengidentifikasi apa yang belum dievaluasi, daripada mengesahkan setiap masukan yang mungkin dari penghitungan yang dangkal.
Standar ini juga merekomendasikan batas pencarian kosong sebanyak dua dengan perilaku yang dapat dikonfigurasi, dan menentukan batas tambahan untuk mekanisme tertentu. Output statis generator tidak menentukan bagaimana semua penerima akan mengevaluasi setiap jalur dalam status DNS di masa depan. Pisahkan pengujian jalur dari pengujian pemformatan. Seorang pembangun dapat menjelaskan kemungkinan ketergantungan tanpa mengklaim bahwa pemeriksaan sintaksis yang berhasil membuktikan keberhasilan SPF secara universal.
Lembar kerja keluaran yang mempertahankan kepemilikan
Buat lembar kerja dengan domain identitas, alur kerja, pemilik bisnis, pemilik teknis, bukti pengirim yang disetujui, jangka waktu yang diusulkan, alasan dan tanggung jawab pemeliharaan. Tambahkan referensi rekaman yang ada, perbedaan yang diinginkan, pengirim yang belum terselesaikan, tinjauan jalur pencarian, rencana verifikasi, dan kriteria pengembalian. Outputnya harus menjelaskan mengapa setiap otorisasi ada dan siapa yang dapat menyetujui penghapusan atau perluasannya.
Set pengujian harus mencakup proposal positif yang valid, sintaksis yang tidak valid, data SPF duplikat, dan kasus dengan istilah yang tidak didukung. Bedakan mekanisme yang tidak diketahui dari pengubah yang tidak diketahui karena RFC 7208 memperlakukannya secara berbeda. Kata-kata dalam katalog memerlukan kasus tag yang tidak didukung; untuk SPF , petakan persyaratan tersebut secara eksplisit ke mekanisme protokol dan kosakata pengubah daripada membuat pengurai tag umum. Tidak ada pengujian yang dilakukan untuk draf ini.
Diagnosis fiktif: pemasok lama tetap berwenang
Sebuah organisasi fiksi meminta pembangun untuk menambahkan layanan pengiriman surat baru. Catatannya saat ini juga merujuk pada pemasok yang sudah pensiun, namun tidak ada yang mendokumentasikan apakah alur kerja lain masih menggunakan ketergantungan tersebut. Seorang pembangun sederhana menggabungkan istilah baru dan mempertahankan segala sesuatu yang lain tanpa penjelasan. Tinjauan sadar kepemilikan yang diusulkan justru menandai otorisasi lama yang belum terselesaikan dan meminta pemilik bisnis dan teknis yang bertanggung jawab untuk menentukan statusnya.
Tim tidak akan menghapus istilah lama hanya untuk mengurangi jumlah, atau menambahkan pemasok baru ke identitas yang tidak terkait. Ini akan menyiapkan perubahan yang disetujui secara pasti setelah menyelesaikan ketergantungan dan merencanakan verifikasi perwakilan. Ini adalah latihan siklus hidup fiktif, bukan catatan yang diamati, penghentian pemasok, atau perubahan DNS yang telah selesai. Hal ini menggambarkan mengapa kepemilikan pengirim merupakan bagian dari pembuatan catatan, bukan dokumen administratif setelahnya.
Verifikasi alur kerja yang dimaksudkan sebelum menyatakan selesai
Setelah publikasi resmi, tim operasional akan menyimpan pengamatan DNS yang tepat dan perwakilan bukti pesan yang diterima untuk setiap alur kerja yang relevan. Pengamatan tersebut harus menunjukkan identitas dan keselarasan sebenarnya, bukan hanya string yang dihasilkan muncul di editor. Sampel yang berhasil tetap terbatas pada pengirim, waktu, dan penerimanya; itu tidak menentukan hasil setiap pesan di masa depan.
Katalog memerlukan catatan beranotasi dan kasus uji tag positif, tidak valid, duplikat, dan tidak didukung. Artefak asli tersebut tetap terbuka. Tinjauan spesialis manusia, penerapan sumber, jalur produksi, aksesibilitas, dan pelepasan pemilik juga tetap terbuka. Draf ini menyediakan lembar kerja yang diusulkan dan diagnosis fiktif, bukan kebijakan produksi yang dihasilkan, rangkaian pengujian yang dijalankan, atau klaim fitur EmailAuth yang diverifikasi.