Pisahkan Keterlibatan Akun dari produk email Salesforce lainnya
Keterlibatan Akun Salesforce memiliki alur kerja manajemen domainnya sendiri. Mulailah dengan mengonfirmasi bahwa pesan dikirim melalui Keterlibatan Akun, yang sebelumnya disebut Pardot, bukan email inti Salesforce atau Marketing Cloud Engagement. Resep DNS untuk produk Salesforce lain dapat menggunakan kontrol yang berbeda dan tidak boleh diimpor hanya karena organisasi menggunakan vendor yang sama. Panduan ini mencakup verifikasi domain pengirim Keterlibatan Akun, DKIM dan jalur pengembalian kustom berbantuan dukungan opsional.
Cantumkan setiap unit bisnis, merek, dan domain tujuan yang digunakan oleh akun tersebut. Sertakan pengirim sebenarnya yang dipilih berdasarkan pengaturan kampanye dan otomatisasi. Domain yang muncul di alamat kotak surat pengguna tidak dikonfigurasi secara otomatis untuk setiap rute Keterlibatan Akun. Tetapkan pemilik pemasaran dan administrator DNS untuk meninjau inventaris bersama sebelum mengubah catatan domain bersama.
Sasaran penerimaannya adalah pesan diterima yang terkontrol dengan mekanisme autentikasi passing yang selaras. Validasi kepemilikan domain, publikasi DNS , dan status pengelolaan ramah lingkungan merupakan bukti perantara yang berguna. Tidak ada satupun yang membuktikan bahwa kampanye tertentu menggunakan identitas yang dimaksudkan atau bahwa server penerima menerima otentikasinya.
Pahami jalur SPF default sebelum mengedit root DNS
Salesforce's Panduan DNS Keterlibatan Akun menyatakan bahwa surat Keterlibatan Akun lolos SPF melalui infrastruktur pengirimannya yang terkontrol dan tidak memerlukan perubahan SPF pelanggan untuk pengaturan default tersebut. Jangan menambahkan penyertaan SPF Salesforce generik ke domain akar organisasi hanya karena nama produk muncul di a DMARC laporan. Konfirmasikan rute sebenarnya dan evaluasi identitas terlebih dahulu.
SPF mengautentikasi SMTP KIRIM DARI identitas, dengan penanganan tersendiri untuk HELO, di bawah RFC 7208. Hasilnya berbeda dari penyelarasan dengan Dari yang terlihat. Pemeriksaan SPF domain penyedia yang berhasil dapat terjadi bersamaan dengan SPF yang tidak selaras. Mengubah kebijakan domain lain tidak mengubah domain amplop mana yang digunakan pesan.
Pertahankan kebijakan SPF yang dibutuhkan oleh layanan organisasi lainnya. Jika penyiapan kustom yang diotorisasi secara terpisah memerlukan perubahan kebijakan, tinjau satu kebijakan lengkap di pemilik tersebut, termasuk ketentuan kueri DNS bertingkat dan batas pencarian protokol. Jangan membuat yang kedua Catatan SPF atau hapus pengirim yang tidak terkait untuk memberi ruang bagi persyaratan yang belum diverifikasi.
Verifikasi kepemilikan dan DKIM sebagai catatan terpisah
Gunakan Manajemen Domain untuk mengidentifikasi Domain Pengiriman Email yang dimaksudkan dan Entri DNS yang Diharapkan. Itu Panduan DNS membedakan kunci validasi domain dari DomainKey-nya. Nilai validasi menentukan kepemilikan pengiriman; nilai DKIM mendukung penandatanganan pesan. Pertahankan kedua tujuan tersebut di lembar kerja daripada memperlakukan salah satu tujuan tersebut catatan TXT berisi nilai Salesforce sebagai bukti yang dapat dipertukarkan.
Salin nilai dari akun sebenarnya. Simpan pemilik catatan lengkap, jenis, nilai dan tanggal instruksi sebelum melakukan perubahan DNS . Periksa apakah akun Keterlibatan Akun lain atau layanan lain sudah bergantung pada pemilik yang sama. Jangan menimpa catatan yang bertentangan, menggunakan kembali nilai pelanggan lain, atau mengubah a pemilih untuk nama yang diciptakan. Mintalah dukungan untuk resolusi yang didukung ketika pengaturan akun bertabrakan.
Jaga agar domain pengirim email berbeda dari domain pelacak. Salesforce secara eksplisit memperingatkan agar tidak menggunakan domain yang sama untuk kedua fungsi tersebut. Nama host pelacakan bermerek tidak sama dengan domain Dari, meskipun keduanya memiliki induk yang sama. Ketergantungan pelacakan inventaris secara terpisah sehingga pekerjaan autentikasi tidak mengubah URL aset atau tautan kampanye secara tidak sengaja.
Publikasikan DomainKey melalui alur kerja yang terdokumentasi
Salesforce's petunjuk pelaksanaan DKIM memerlukan peran Administrator Keterlibatan Akun. Di aplikasi Lightning, buka Pengaturan Keterlibatan Akun, lalu Manajemen Domain. Di antarmuka Keterlibatan Akun alternatif, titik awal yang didokumentasikan adalah Admin. Di bawah Domain Pengiriman Email, buka Entri DNS yang Diharapkan untuk domain yang dipilih dan salin nilai DomainKey untuk publikasi sebagai TXT .
Gunakan pemilik dan nilai yang ditampilkan untuk akun dan domain tersebut. Artikel saat ini mengatakan untuk memberikan waktu hingga 24 jam agar penandatanganan diterapkan setelah catatan ditambahkan. Perlakukan hal tersebut sebagai panduan waktu penyedia, bukan jaminan bahwa setiap cache atau penerima DNS akan diperbarui pada saat yang bersamaan. Catat waktu publikasi dan tunggu keadaan yang diharapkan sebelum menilai tes baru.
Konfirmasikan jawaban DNS publik, termasuk pemilik yang sepenuhnya memenuhi syarat. Editor DNS terkadang menambahkan nama zona ke kolom host, membuat akhiran duplikat ketika nama lengkap dimasukkan. Tinjau jawaban yang dihasilkan daripada mempercayai formulir masukan. Simpan kesalahan Manajemen Domain dan detailnya sehingga dukungan dapat menyelidiki kegagalan sebenarnya, bukan status yang diparafrasekan.
Putuskan apakah jalur pengembalian khusus diperlukan
Salesforce's Artikel dukungan DMARC menjelaskan selaras DKIM sebagai jalur DMARC normal dan menjelaskan bahwa default jalur kembali domain tidak sejajar dengan Dari yang terlihat. Ini juga mendokumentasikan permintaan jalur pengembalian kustom yang dibantu dukungan. Batasan yang dinyatakan adalah satu domain jalur pengembalian kustom tetap per unit bisnis, bukan domain variabel yang dipilih untuk setiap pesan.
Sebelum meminta opsi ini, identifikasi kebutuhan bisnis. Organisasi yang membutuhkan SPF dan DKIM yang selaras harus mengevaluasi pengaturan domain aktual dan mode penyelarasan dengan dukungan. Unit bisnis yang mengirimkan merek yang tidak terkait tidak boleh berasumsi bahwa satu jalur pengembalian tetap dapat selaras dengan setiap domain Dari. Biarkan pertanyaan desain tetap terbuka hingga identitas yang diamati dan konfigurasi yang didukung menyelesaikannya.
Dapatkan catatan DNS yang tepat dari kasus dukungan dan minta pemilik DNS meninjau konflik dan ketergantungan. Artikel ini tidak menyediakan target jalur pengembalian kustom universal atau sakelar aktivasi. Menerbitkan catatan dugaan atau menyalin konfigurasi domain pentalan produk lain dapat merusak rute kerja tanpa memenuhi persyaratan.
Uji pengirim yang dipilih melalui aliran pesan sebenarnya
Kirim pesan terkontrol yang tidak berbahaya melalui setiap domain pengirim dan rute unit bisnis yang berbeda. Gunakan pilihan pengirim yang sama dengan kampanye atau otomatisasi yang direncanakan. Catat referensi kampanye, ID Pesan, waktu UTC, dan penerima pengujian eksternal. Jika fitur pratinjau atau pengujian menggunakan jalur yang berbeda dari produksi, selesaikan perbedaan tersebut sebelum memperlakukannya sebagai bukti yang representatif.
Pada sistem penerima tepercaya, ambil Dari, Return-Path , dan semua domain dan penyeleksi penandatanganan DKIM . RFC 6376 mendefinisikan nilai d= dan s= yang digunakan untuk menemukan kunci verifikasi publik. Bandingkan domain penandatanganan yang diamati dengan domain pengirim yang dikonfigurasi. Catatan DNS bisa benar saat pesan masih menggunakan pengirim yang tidak terduga atau rute lain.
Menerapkan RFC 9989 terhadap hasil sebenarnya. DMARC dapat melewati passing selaras tanda tangan DKIM atau melewati SPF yang selaras. Catat mekanisme mana yang memberikan hasil dan mode penyelarasan mana yang diterapkan. Simpan autentikasi SPF , penyelarasan SPF , autentikasi DKIM , dan penyelarasan DKIM di kolom terpisah. Hal ini mencegah satu status hijau menyembunyikan persyaratan yang belum diuji.
Pecahkan masalah batas yang gagal alih-alih mengubah setiap kontrol
Jika domain pengirim belum terverifikasi, bandingkan kunci validasi dan pemilik DNS sebenarnya dengan Entri DNS yang Diharapkan. Jika DKIM hilang setelah periode aktivasi yang diharapkan, konfirmasikan Dari domain dan akun yang dipilih, lalu periksa kesalahan Manajemen Domain. Jika tanda tangan gagal, verifikasi pemilih dan nilai publik serta periksa sistem hilir apa pun yang mengubah pesan setelah penandatanganan.
Jika DMARC gagal saat SPF lolos, selidiki penyelarasan dan apakah DKIM yang selaras telah dikonfigurasi untuk pengirim tersebut. Jangan menganggap kesuksesan SPF default sebagai janji kesuksesan DMARC . Jika melibatkan jalur pengembalian khusus, bandingkan identitas amplop yang diamati dengan pengaturan unit bisnis tetap dan instruksi yang diberikan dukungan. Pertahankan pesan gagal yang representatif untuk diagnosis.
Pertahankan kebijakan DMARC organisasi dan tujuan pelaporan di bawah kepemilikannya saat ini. Artikel Salesforce menjelaskan kebutuhan pemantauan DMARC eksternal dibandingkan pengumpulan Keterlibatan Akun laporan kegagalan. Pekerjaan autentikasi DNS tidak boleh secara diam-diam menggantikan tujuan pelaporan atau menurunkan penegakan hukum di seluruh pengirim yang tidak terkait. Tinjau setiap perubahan kebijakan yang diusulkan secara terpisah dengan pemilik email dan keamanan.
Lembar kerja domain Keterlibatan Akun
- Akun, unit bisnis, merek, dan alur kerja pengiriman: ____.
- Alamat Dari yang dipilih dan Domain Pengiriman Email yang dikonfigurasi: ____.
- Pisahkan domain pelacak dan dependensinya yang ada: ____.
- Kunci validasi dan referensi data DKIM dari Entri DNS yang Diharapkan: ____.
- Jawaban DNS publik, waktu publikasi dan status manajemen: ____.
- Desain jalur pengembalian kustom default atau dengan bantuan dukungan: ____.
- Batasan jalur pengembalian khusus dan konfirmasi dukungan jika relevan: ____.
- Uji ID Pesan, waktu UTC, Dari, Return-Path , dan identitas DKIM : ____.
- Hasil autentikasi tepercaya dan mekanisme DMARC yang selaras: ____.
- Pengecualian, pemantauan pemilik dan pemulihan yang disetujui: ____.
Contoh fiktif keberhasilan SPF tanpa penyelarasan
Kasus tertulis fiktif saja: AE-01 mengasumsikan unit bisnis yang dikirim North sebagai news@example.org dan unit bisnis South yang dikirim sebagai news@example.net . Jalur pengembalian khusus tetap yang diusulkan pada bounce.example.org mungkin selaras dengan jalur pertama dalam penyelarasan SPF yang longgar, namun tidak dapat dianggap selaras dengan jalur kedua yang tidak terkait. Tanda tangan DKIM dan hasil SPF masih belum diketahui, sehingga tidak ada rute yang memiliki keputusan DMARC yang tegas. Pemilik pemasaran dan email harus memisahkan pengaturan unit bisnis dan memvalidasi DKIM yang selaras per domain Dari yang dipilih sebelum meminta pengeditan SPF akar apa pun. Semua identitas dan pengaturan diciptakan; tidak ada kasus dukungan, permintaan atau pesan DNS yang dieksekusi.
Jaga agar penyelesaian tetap terikat dengan bukti nyata
Alur kerja yang terdokumentasi tidak memverifikasi izin penyewa sebenarnya, nilai yang dihasilkan, atau kemampuan jalur kembali kustom. Pemeriksaan akun, DNS langsung dan verifikasi header, tinjauan visual, dan persetujuan UKM manusia masih menunggu keputusan. Panduan ini tidak dipublikasikan dan tidak boleh disajikan sebagai bukti bahwa kampanye suatu organisasi telah diautentikasi dalam produksinya.
Pisahkan pesan yang lewat dari kesiapan penegakan
RFC 9989 Bagian 7.4 memerlukan DKIM yang valid untuk penerbitan domain p=reject dan memperingatkan tentang interoperabilitas email tidak langsung. Satu hasil SPF yang selaras tidak dengan sendirinya membenarkan penerapan kebijakan penolakan. Tinjau semua rute dan kepemilikan kebijakan yang sah secara terpisah dari pengaturan penyedia ini.