Pilih identitas bisnis sebelum mengubah DNS
Email EngageLab memiliki pengiriman domain khusus dan rute domain bersama yang dihosting. Itu adalah pilihan identitas yang berbeda, bukan jalan pintas yang bisa dipertukarkan. Putuskan apakah penerima harus melihat domain organisasi Anda. Pengujian yang berhasil dari alamat milik penyedia tidak menunjukkan bahwa domain bisnis Anda diautentikasi. Catat aplikasi yang tepat, alamat pengirim yang terlihat, dan jenis pesan sebelum membuka pengaturan DNS .
Dokumentasi Pengaturan Pengiriman menjelaskan domain pengujian awal, fitur domain bersama terpisah, dan domain bisnis khusus. Rute bersama menggunakan subdomain base.engagelab.com , dengan alamat yang terlihat pada namespace yang dihosting tersebut. Untuk peluncuran domain bisnis, gunakan alur kerja domain kustom. Jangan menganggap klaim layanan mengenai reputasi bersama atau kuota gratis sebagai jaminan pengiriman atau hak kontrak. Konfirmasikan batasan komersial secara terpisah.
Tangkap konfigurasi khusus domain
Di Pengaturan, domain, buat atau pilih domain pengirim dan dapatkan instruksi DNS saat ini. Daftar EngageLab SPF, DKIM dan MX sesuai kebutuhan, dengan DMARC opsional untuk status validasinya. Belum diverifikasi berarti cek yang diperlukan tidak ada; Dapat digunakan berarti lulus cek yang diperlukan; Terverifikasi berarti semua cek yang ditampilkan lulus. Label ini menjelaskan validasi produk, bukan keputusan pesan yang diterima.
Mintalah pemilik DNS meninjau seluruh kumpulan data yang diusulkan sebelum dipublikasikan. Perubahan MX memengaruhi perutean masuk pada nama pemiliknya. Jika nama yang diusulkan sudah menerima surat staf, jeda dan selesaikan konflik tersebut daripada mengganti penukar suratnya. Namespace pengiriman khusus dapat mengurangi tabrakan, namun kesesuaiannya harus dikonfirmasi terhadap konfigurasi akun sebenarnya. Catat nama pemilik, jenis, nilai, TTL, nilai lama dan alasan setiap perubahan.
Dokumentasi Domain API memaparkan nilai konfigurasi SPF , DKIM , MX dan DMARC serta hasil verifikasi per data. Hal ini berguna untuk memeriksa ulang apa yang diharapkan oleh akun, bukan sebagai sumber sampel kredensial atau kunci DNS yang dapat digunakan kembali. Salin nilai dari objek domain Anda sendiri. Jangan pernah menggunakan kembali kunci publik domain contoh, asumsikan itu pemilih berlaku untuk Anda, atau menerapkan kebijakan penolakan sampelnya tanpa meninjau aliran email sah lainnya.
Publikasikan tanpa mengganti izin yang tidak terkait
Di host DNS otoritatif, tambahkan jenis catatan dan nama pemilik yang diperlukan. Panel DNS berbeda dalam hal penambahan nama zona, jadi periksalah nama yang dihasilkan sepenuhnya memenuhi syarat. Pemilih yang salah tempat dapat meninggalkan rekaman yang tampak masuk akal dan tidak pernah ditanyakan oleh penerima. Pertahankan data kunci yang lengkap dan hindari penambahan data lain pada a CNAME pemilik.
Jika SPF sudah ada, rekonsiliasi otorisasi baru tersebut ke dalam kebijakan SPF tunggal tersebut. Jangan membuat kebijakan v=spf1 kedua dengan nama yang sama. Evaluasi ketergantungan pencarian DNS dari kebijakan gabungan, bukan hanya menghitung penyertaan yang terlihat. Pertahankan pengirim aktif dan kualifikasi akhir yang ditetapkan kecuali pemilik domain telah menyetujui perubahan secara terpisah. Tidak satu pun dari langkah-langkah ini yang mengizinkan perluasan izin ke layanan email yang tidak terkait.
Kueri catatan resmi dan bandingkan dengan instruksi akun yang disimpan. Kemudian jalankan kembali validasi EngageLab setelah cache memiliki waktu kedaluwarsa. Perkiraan penundaan DNS dalam dokumentasi bukanlah tenggat waktu universal. Jawaban otoritatif yang salah tidak akan memperbaiki dirinya sendiri dengan menunggu. Jika platform dan tanggapan resmi tidak setuju, simpan keduanya dengan stempel waktu sebelum memecahkan masalah cache penyelesai.
Ikat aplikasi ke rute yang dituju
EngageLab juga menginstruksikan pengguna untuk menggunakan domain pengirim yang berbeda dengan domain primer yang berbeda untuk pemicu dan email massal, untuk menjaga pembatasan massal agar tidak menunda pesan pemicu. Konfirmasikan pemisahan ini dengan pemilik akun sebelum mengikat rute API_USER; dua subdomain dari domain primer yang sama tidak memenuhi instruksi yang disebutkan. Catat domain yang disetujui untuk setiap jenis pesan.
Penyiapan API_USER yang terdokumentasi mengaitkan domain pengirim dan jenis pesan batch atau pemicu. Verifikasi bahwa aplikasi menggunakan asosiasi yang dimaksud. Menguji satu kredensial sementara produksi menggunakan kredensial lain dapat menghasilkan hasil ramah lingkungan yang menyesatkan. Simpan rahasia di penyimpanan rahasia yang disetujui, bukan catatan bukti, tangkapan layar, atau lampiran dukungan ini.
Buat lembar kerja rute kecil: aplikasi, lingkungan, transportasi API atau SMTP , jenis pesan, domain terikat, alamat Dari yang terlihat, pemilik dan rute rollback. Uji jalur kode yang setara dengan produksi dengan penerima yang dikontrol. Jangan menyimpulkan bahwa pratinjau, akun pengujian, atau aplikasi yang tidak terkait membuktikan integrasi tersebut. Untuk email transaksional yang sensitif terhadap waktu, uji alur kerja pemicu secara eksplisit daripada mengandalkan kampanye massal yang berhasil.
Buktikan keselarasan dengan pesan yang diterima
Simpan pesan asli yang diterima dan penerima tepercaya Authentication-Results. Rekam Dari, domain amplop, setiap nilai DKIM d= dan s=, hasil SPF , hasil DKIM dan hasil DMARC . SPF mengautentikasi domain amplop; DKIM mengautentikasi domain penandatanganannya. DMARC memerlukan setidaknya satu jalur terotentikasi yang selaras dengan domain Dari yang terlihat dalam mode yang berlaku. Otentikasi tidak menjamin penempatan kotak masuk.
Contoh penalaran sintetis, bukan default EngageLab: Dari receipts@example.com , amplop bounce@other.example.net dan tanda tangan lewat dengan d=example.com. SPF untuk other.example.net tidak selaras dengan example.com , tetapi tanda tangannya memberikan DKIM yang sama persis penyelarasan. Jika tanda tangan tersebut tidak ada atau tidak valid, pass DMARC yang diasumsikan tidak didukung. Tuliskan identitas di samping putusan sehingga kata sederhana seperti pass tidak dapat menyembunyikan domain yang salah.
Tutup perubahan dan pertahankan pemulihan
Jika verifikasi gagal, isolasi apakah masalahnya adalah DNS , asosiasi domain, atau penandatanganan pesan. Pulihkan rute aplikasi yang dikenal baik daripada melemahkan kebijakan DMARC seluruh domain. Jangan hapus kunci yang masih digunakan oleh pesan yang masuk antrean. Setelah berhasil, pertahankan perbedaan DNS yang disetujui, validasi akun, lembar kerja rute, dan bukti pesan, serta jadwalkan pemeriksaan ulang setelah perubahan transportasi atau domain.
Ini adalah panduan konfigurasi dokumenter. Tidak ada penyewa EngageLab yang diubah, tidak ada DNS produksi yang diukur, dan tidak ada tabel identitas pesan yang diterima yang dikumpulkan untuk draf ini. Pengecekan di atas merupakan pekerjaan penerimaan bagi operator, bukan hasil yang diklaim. Persetujuan manusia dan pengujian khusus rute tetap diperlukan sebelum peluncuran produksi.
Selesaikan ketidakcocokan pengikatan domain sebelum rilis
Kasus tertulis EL-01 mengasumsikan konsol menandai notify.example.com Dapat Digunakan, sedangkan aplikasi pemicu produksi tetap terikat pada API_USER domain bersama yang dihosting. Dari yang dimaksudkan adalah receipts@notify.example.com ; hasil asli Dari, identitas amplop dan tanda tangan belum dikumpulkan. Status DNS yang dapat digunakan tidak dapat membuktikan identitas aplikasi yang dimaksud. Pemilik aplikasi harus merekonsiliasi domain terikat dan jenis pemicu dengan rute yang disetujui sebelum pengujian penerimaan terkontrol yang tidak berbahaya. Jangan membuat kredensial atau mengubah MX hanya untuk membuat lembar kerja menjadi hijau. Tidak ada panggilan API, rahasia, edit DNS , atau pesan yang dieksekusi.
Pertahankan batas penegakan hukum
RFC 9989 Bagian 7.4 memerlukan DKIM yang valid, bukan SPF saja, untuk penerbitan domain p=reject, dan memperingatkan tentang interoperabilitas surat tidak langsung dan milis. Sebuah uji coba pesan langsung yang sukses bukanlah bukti bahwa setiap jalur yang sah siap untuk menerapkan kebijakan yang lebih kuat. Pertahankan perlindungan yang disetujui saat mendiagnosis kesenjangan yang sebenarnya; setiap perubahan kebijakan memerlukan keputusannya sendiri.