Bedakan email sistem dari email pemasaran
Dokumentasi Otentikasi Email Sistem Spektrix mencakup pesan operasional seperti konfirmasi pesanan, tiket cetak di rumah, pengaturan ulang kata sandi, dan pemberitahuan keanggotaan. Ini membedakannya dengan email pemasaran yang ditangani oleh Dotdigital. Oleh karena itu, domain pemasaran yang diautentikasi tidak cukup menjadi bukti bahwa pemberitahuan sistem menggunakan identitas yang dimaksudkan.
Inventarisasi sistem Spektrix, kategori pesan, pengirim yang dituju dan tim yang bertanggung jawab. Menyertakan laporan atau daftar terjadwal hanya jika laporan atau daftar tersebut merupakan bagian dari cakupan sebenarnya; jangan berasumsi setiap fitur yang mungkin diaktifkan untuk organisasi. Tim dukungan pelanggan dan box office harus menyetujui alamat mana yang akan dilihat oleh penerima dan kotak surat mana yang akan menerima balasan.
Dokumentasi mendukung rencana konfigurasi, bukan pernyataan bahwa penyewa telah dikonfigurasi. Naskah ini tidak melakukan komunikasi dukungan, permintaan DNS , perubahan catatan atau pengiriman tes. Persyaratan penerapan awal dan penerapan akun tetap terbuka. Otentikasi Email Sistem
Pilih subdomain pengirim khusus dengan sengaja
Spektrix menginstruksikan klien untuk menggunakan subdomain untuk email sistem dan menempatkan konfigurasi yang relevan di sana, bukan di root. Ia juga menyarankan agar tidak menggunakan subdomain yang sama dengan integrasi web domain khusus Spektrix. Catat batas yang dipilih dan periksa apakah nama tersebut sudah memiliki tujuan lain.
Subdomain khusus dapat membantu memisahkan ketergantungan operasional, namun ini bukan jaminan bahwa dampak reputasi atau keamanan tidak akan pernah menjangkau organisasi yang lebih luas. Manfaat praktisnya adalah kepemilikan yang lebih jelas dan berkurangnya tumpang tindih dengan infrastruktur domain root. Pertahankan perbedaan tersebut daripada menjanjikan isolasi total.
Sebelum mengusulkan rekaman, identifikasi zona otoritatif yang ada, penggunaan MX saat ini, dan warisan atau eksplisit DMARC kebijakan. Nama yang tampak tidak digunakan dalam spreadsheet mungkin masih mendukung suatu layanan. Jangan mengganti catatan situs web produksi atau kotak surat hanya agar sesuai dengan contoh yang mudah digunakan. Konfirmasikan subdomain yang dimaksud dengan pemilik domain resmi dan alur kerja dukungan Spektrix yang terdokumentasi. Mengirim Subdomain
Tinjau SPF , DKIM dan MX sebagai dependensi yang berbeda
Nama panduan sistem-email SPF, DKIM Dan data MX untuk subdomain pengirim yang dipilih. Contoh SPF -nya mencakup mailgun.org . Jika kebijakan SPF sudah ada pada nama tersebut, tinjau satu kebijakan lengkap daripada menambahkan data kedua atau menempelkan seluruh sampel ke dalam nilai yang sudah ada. Pertahankan sumber yang sah dan tinjau batas evaluasi yang bergantung pada DNS.
DKIM dibantu oleh dukungan: panduan ini meminta klien untuk mengonfirmasi domain pengirim dengan Dukungan Spektrix, yang membantu menghasilkan kunci domain. Ini menjelaskan 2048-bit kunci. Menyimpan nama kunci dan nilai publik yang sebenarnya dikeluarkan; jangan menciptakan a pemilih atau menggunakan kembali kunci organisasi lain.
Data MX berkaitan dengan perutean email, bukan pengganti a tanda tangan DKIM. Panduan ini memberikan tujuan Mailgun MX yang berbeda untuk klien Inggris/Irlandia/Kanada dan AS. Gunakan wilayah akun yang dikonfirmasi penyedia dan instruksi lengkap, termasuk nilai apa pun yang tidak ditetapkan oleh kutipan yang disalin. Jangan pernah mengubah layanan email domain root yang ada hanya karena subdomain email sistem memerlukan konfigurasi MX . Menyiapkan Data SPF , DKIM dan MX; RFC 7208 , bagian 3.2; RFC 7208 , bagian 4.6.4
Pisahkan perutean pencatatan dan balasan dari autentikasi
Panduan ini menjelaskan ketergantungan logging email opsional menggunakan label email di bawah subdomain pengirim dan sesuai wilayah CNAME. Dikatakan bahwa klien tidak secara langsung mengakses pencatatan yang dihasilkan dan hal ini membantu mendukung penyelidikan pengiriman. Ini tidak sama dengan kunci DKIM atau bukti bahwa penerima telah membaca pesan.
Tinjau fitur pelacakan atau pencatatan berdasarkan persyaratan privasi dan komunikasi organisasi sebelum mengaktifkannya. Naskah ini tidak membuat catatan pelacakan atau mengumpulkan data interaksi penerima. Paket bukti yang diusulkan dapat mengidentifikasi apakah fitur tersebut berada dalam cakupan tanpa berasumsi bahwa pembukaan atau klik dapat mengukur perhatian manusia dengan andal.
Penyedia juga menjelaskan pengaturan alamat Balas-Ke melalui dukungan ketika alamat pengirim tidak memiliki kotak surat yang dipantau. Tinjau tujuan itu dengan tim box-office. Balasan yang berhasil diterima membuktikan hasil alur kerja, bukan penyelarasan dari pemberitahuan aslinya. Pencatatan Email; Balas Ke Alamat
Pertahankan niat DMARC domain induk
Spektrix memperingatkan bahwa subdomain dasar catatan DMARC dapat bertentangan dengan konfigurasi domain induk organisasi yang ada. Perlakukan setiap kebijakan pemantauan yang diberikan sebagai keputusan kebijakan yang diusulkan, bukan sebagai tanda verifikasi yang tidak berbahaya. Menerbitkan kebijakan subdomain yang eksplisit dapat mengubah hubungan kebijakan yang berlaku, sehingga pemilik domain harus meninjaunya sebelum memberikan persetujuan.
Gunakan semantik DMARC saat ini daripada pernyataan umum bahwa autentikasi selalu memastikan pengiriman atau bahwa nilai kebijakan menentukan hasil setiap penerima. DMARC mengevaluasi keselarasan dengan identitas autentikasi yang lewat, sementara penerima mempertahankan kebijakan penanganannya sendiri. Domain pengirim cadangan tidak dapat dianggap mengautentikasi domain penulis yang tidak terkait hanya karena email terus meninggalkan aplikasi.
Pemeriksaan akhir yang diusulkan adalah pesan sistem perwakilan resmi dengan domain penulisnya, identitas penandatanganan, pemilih, identitas amplop yang relevan, dan hasil penerima yang tepercaya. Pisahkan bukti pesan pemasaran. Jangan menurunkan kebijakan untuk menyembunyikan rute sistem yang belum terselesaikan atau mengklaim bahwa pemeriksaan DNS hijau membuktikan penerimaan tiket oleh pelanggan. DMARC ; Konflik; Domain cadangan; RFC 9989 , bagian 4.4; RFC 9989 , bagian 5.3
Lembar kerja penerimaan untuk tim box-office dan IT
Gunakan lembar kerja asli yang diusulkan ini untuk mengoordinasikan surat operasional tanpa mengganti bukti dengan asumsi.
- Cakupan pesan: pengidentifikasi sistem, kategori operasional, dan tanggung jawab pemasaran Dotdigital yang terpisah.
- Batas pengiriman: subdomain yang disetujui, penggunaan DNS yang ada, dan perbedaan dari integrasi web khusus.
- Permintaan penyedia: wilayah yang dikonfirmasi dukungan, detail kunci DKIM yang dikeluarkan, dan instruksi pencatatan lengkap.
- Tinjauan kebijakan: kebijakan SPF tunggal yang koheren, maksud DMARC yang eksplisit atau diwariskan, dan persetujuan pemilik domain.
- Perutean email: konfigurasi MX subdomain dan konfirmasi bahwa layanan kotak surat domain root tetap tidak terpengaruh.
- Fitur opsional: keputusan pencatatan atau pelacakan, pemilik privasi, dan tujuan Balas-Ke yang dipantau.
- Penerimaan: status penyedia jika tersedia, identitas pesan yang diterima dan hasil otentikasi tepercaya.
- Kontinuitas: pemilik rollback, ketergantungan pesan terjadwal, dan pertanyaan rilis produksi yang belum terselesaikan.
Lembar kerja kosong. Ini tidak mencatat alamat pelanggan sebenarnya, pembelian tiket, kunci pribadi, perubahan DNS , atau tindakan dukungan.
Diagnosis fiktif: domain pemasaran disalahartikan sebagai email sistem
Sebuah teater fiksi meluncurkan kampanye Dotdigital yang diautentikasi dan mengasumsikan konfirmasi tiketnya tercakup dalam pengaturan yang sama. Contoh pesan sistem selanjutnya menunjukkan jalur pengiriman yang berbeda. Tim box-office mengusulkan untuk mengubah data MX domain akar karena panduan email sistem menyebutkan MX .
Tinjauan yang diusulkan menghentikan perubahan yang tidak terkait tersebut. Ini memisahkan rute pemasaran dan operasional, mengidentifikasi subdomain email sistem khusus, dan meminta instruksi wilayah akun yang benar dan kunci dukungan yang dikeluarkan. Infrastruktur kotak surat perusahaan yang ada dipertahankan sementara rangkaian ketergantungan baru ditinjau.
Teater juga memeriksa kebijakan domain induk sebelum menerima data subdomain yang disarankan. Tidak ada keberhasilan yang dapat diklaim sampai terdapat bukti operasional yang sesuai. Skenario ini fiktif dan tidak menggambarkan kejadian Spektrix yang sebenarnya, pesan pelanggan, atau pengujian yang dilakukan.