Rute failover dapat mempertahankan pengiriman pesan sambil mengubah identitasnya SPF mengautentikasi. Hanya menguji apakah IP cadangan diotorisasi akan melewatkan kegagalan penting: SPF mungkin lolos untuk domain amplop milik penyedia yang tidak selaras dengan domain Dari yang terlihat. Desain yang tangguh harus menentukan ketersediaan rute dan hasil autentikasi.
Tentukan kontrak identitas
Untuk jalur utama dan cadangan, catat kumpulan IP pengirim, KIRIM DARI domain, HELO perilaku, terlihat Dari domain dan DKIM penandatanganan domain. Sertakan apa yang terjadi ketika DNS domain khusus tidak tersedia atau penyedia kembali ke domainnya sendiri. Dapatkan detail ini dari konfigurasi layanan sebenarnya dan dokumentasi penyedia saat ini, daripada berasumsi kedua jalur memiliki default yang sama.
SPF mengevaluasi identitas SMTP , sementara DMARC membandingkan domain SPF yang diautentikasi dengan Domain Penulis di Dari. Ketat penyelarasan memerlukan pencocokan domain yang tepat di bawah RFC 9989 §3.2.10.2. Penyelarasan yang santai mengikuti penemuan domain organisasi di bawah RFC 9989 §4.10.2. Sufiks bersama yang ditebak dari dua label terakhir bukanlah implementasi tujuan umum yang dapat diandalkan. RFC 7208 §2.3, RFC 7208 §2.4; RFC 9989 §3.2.4, RFC 9989 §4.4.
Uji saklar sebagai transaksi yang lengkap
Gunakan pesan pengujian aman melalui rute utama dan ulangi melalui rute failover. Simpan transaksi pengirim dan hasil autentikasi penerima terpercaya. Catat hasil SPF mentah, domain terautentikasi, penyelarasan SPF , setiap hasil DKIM dan domain penandatanganan, hasil DMARC keseluruhan, penerimaan SMTP , dan penempatan yang diamati secara terpisah. Pesan yang diterima bukan merupakan bukti autentikasi yang benar atau penempatan kotak masuk di tempat lain.
Skenario ilustratif, dengan asumsi kebijakan DMARC yang berlaku: penggunaan email normal From billing@example.com dan MAIL FROM bounce.example.com . Cadangan menggunakan bounce.vendor.example.net . Dengan asumsi example.com adalah yang relevan domain organisasi, identitas SPF normal disejajarkan dalam mode santai; identitas cadangan tidak. Keduanya bisa lolos SPF . Jika cadangan juga menghasilkan lewat tanda tangan DKIM dengan d=example.com, DMARC masih memiliki jalur autentikasi yang selaras. Tanpa jalur tersebut, failover dapat menyebabkan kegagalan DMARC .
Sertakan jalur luar biasa
Uji failover paksa, pemulihan ke percobaan utama, percobaan ulang yang tertunda, dan email status pengiriman dari mana sistem Anda berasal. Untuk jalur balik yang kosong, SPF membuat identitas MAIL FROM menggunakan postmaster dan domain HELO . Tiket HELO mandiri pada lalu lintas MAIL FROM non-null biasa bukanlah pengganti identitas SPF yang digunakan DMARC . RFC 9989 §3.2.4.
Jaga agar matriks pengujian cukup kecil untuk diulang tetapi cukup luas untuk mencakup setiap konfigurasi yang berbeda. Jika penyedia tidak dapat menyimpan amplop khusus yang diselaraskan, putuskan apakah DKIM yang diselaraskan menyediakan ketahanan yang diperlukan dan apakah persyaratan penerima terpisah terpenuhi. Jangan melemahkan penyelarasan atau menambahkan domain yang tidak terkait ke SPF sebagai pengganti pemahaman desain.
Tetapkan kondisi pemulihan yang aman
Dokumentasikan kegagalan autentikasi mana yang memblokir peralihan dan siapa yang dapat mengotorisasi pengecualian. Pulihkan perutean utama jika sudah sehat dan perubahannya aman, dengan mempertahankan log dari kedua arah. Tutup latihan hanya ketika identitas yang diharapkan cocok dengan bukti yang diterima dan perilaku percobaan ulang dapat dipahami. Hasilnya adalah kontrak fallback yang teruji, bukan klaim bahwa semua penerima di masa depan akan menerima email.
Gunakan catatan keputusan yang konkret
Catat jalur utama, cadangan, dan pemulihan sebagai baris terpisah: IP penghubung, konteks MAIL FROM/ HELO , identitas/hasil SPF , mode/hasil penyelarasan, setiap identitas/hasil DKIM , dan keseluruhan DMARC . Untuk From= example.com dan MAIL FROM= bounce.example.com , penyelarasan SPF yang ketat gagal meskipun SPF lolos; tanda tangan d=example.com yang terverifikasi tetap dapat memberikan izin DMARC berdasarkan kebijakan yang berlaku. Ini adalah hasil hipotetis yang diharapkan, bukan kegagalan yang dilakukan.