Perlakukan Email dan SMTP sebagai pengujian terpisah atas pengaturan bersama
SendPulse mendokumentasikan daftar domain terotentikasi bersama untuk Email dan SMTP . Tunjangan domain yang berlaku adalah batas tertinggi dari kedua paket, dan setiap subdomain dihitung secara terpisah; domain pelacakan tidak menggunakan izin autentikasi tersebut. Panduan saat ini memberikan contoh paket gratis dari satu domain Email dan dua domain SMTP , yang mengizinkan dua entri bersama. Konfirmasikan tunjangan akun live sebelum merencanakan beberapa merek atau subdomain. Otentikasi Email SendPulse, Hasilkan catatan DKIM dan SPF Anda.
Pengaturan bersama mengurangi pekerjaan duplikat DNS , namun tidak membuktikan bahwa setiap aplikasi memilih domain Dari yang dituju. Kampanye pemasaran inventaris, otomatisasi, dan pengiriman aplikasi melalui SMTP atau API. Tangkap akun dan domain yang dituju untuk setiap rute, pemilik bisnis, pemilik aplikasi, dan administrator DNS . Simpan kredensial pengiriman di luar lembar kerja ini.
Panduan ini mencakup alur kerja autentikasi Email dan SMTP publik penyedia. Itu tidak mengasumsikan tunjangan domain tidak terbatas, sebuah kebiasaan yang dapat dipilih secara independen Return-Path atau identitas akhir yang identik di setiap integrasi. Jika persyaratan bisnis tergantung pada ketat penyelarasan atau domain amplop tertentu, dapatkan desain yang didukung dari SendPulse sebelum berkomitmen padanya.
Periksa domain yang ada sebelum membuat catatan
Di Email, titik masuk yang didokumentasikan adalah Pengaturan > Pengaturan domain, diikuti dengan aktivasi di area domain yang diautentikasi. Di SMTP , gunakan Pengaturan SMTP > Pengaturan domain dan area domain pengirim. Kedua alur kerja menghasilkan SPF Dan DKIM catatan untuk domain yang dimasukkan. Dokumentasi SMTP menyatakan autentikasi Email yang ada tidak memerlukan penyiapan DKIM lain karena layanan berbagi setelan data. SendPulse SMTP DKIM , Pengaturan catatan bersama dan Menambahkan domain baru.
Buka terlebih dahulu domain yang ada jika sudah ada. Catat status koneksi saat ini dan nilai publiknya. Jangan membuat pengaturan kedua hanya karena aplikasi baru menggunakan SMTP . Jika dua akun atau tim mengklaim domain yang sama, bandingkan instruksi yang dikeluarkan penyedia mereka saat ini dan klarifikasi kepemilikan sebelum mengubah domain bersama pemilih.
Hitung domain yang diperlukan untuk peluncuran, termasuk subdomain yang diautentikasi secara terpisah. Jika akun berada pada batas yang diizinkan, jangan hapus domain yang berfungsi hanya untuk mengekspos kontrol Tambah. Identifikasi apa yang menggunakan domain tersebut dan pilih paket atau strategi domain dengan pemilik akun. Keputusan pemberian hak komersial terpisah dari kegagalan DNS .
Rekonsiliasi instruksi SPF dengan kebijakan yang ada
Panduan SendPulse SPF menginstruksikan pengguna dengan yang sudah ada Catatan SPF untuk menambahkan otorisasi penyedia ke data tersebut daripada membuat yang kedua. Nama panduan yang dikutip include:mxsspf.sendpulse.com sebagai tambahan pada kebijakan yang sudah ada. Konfirmasikan penerapan terhadap pengaturan domain akun saat ini; contoh suku a dan mx bukan merupakan penjumlahan otomatis. Jangan menyalin contoh kebijakan lengkap dari kebijakan yang sudah ada. SendPulse SMTP SPF , Salin catatan SPF dan Tambahkan entri ke situs web penyedia DNS.
Ekspor jawaban TXT saat ini untuk pemilik sebenarnya sebelum mengedit. Cantumkan layanan lain yang bergantung pada kebijakan SPF -nya, dan identifikasi identitas amplop sebenarnya dalam pesan dasar jika memungkinkan. Domain Dari perusahaan dan domain yang diautentikasi SPF mungkin berbeda. Menerbitkan penyertaan pada puncak yang sewenang-wenang tidak dapat memperbaiki kegagalan yang dievaluasi di tempat lain.
Tinjau semua persyaratan SPF kueri DNS, termasuk penyertaan bertingkat, terhadap batas evaluasi sepuluh jangka waktu. Catatan DNS yang sesuai dengan batasan panjang editor masih dapat melebihi batas evaluasi protokol. Pertahankan otorisasi yang sah dan kualifikasi akhir yang disetujui. Jangan memperluas izin dengan contoh mekanisme a atau mx kecuali pemilik domain telah mengevaluasi apa yang mereka otorisasi. RFC 7208 , Memilih Catatan dan Batas Pencarian DNS.
Jika permintaan penyedia dan kebijakan organisasi yang ada tidak dapat diselaraskan dengan aman, hentikan sebelum dipublikasikan. Minta pemilik email untuk mengevaluasi subdomain pengiriman yang didukung atau desain lain yang sesuai. Jaga agar jalur kerja yang ada tetap tersedia saat keputusan itu dibuat.
Publikasikan kunci publik akun pada pemilik yang benar
Instruksi SendPulse menunjukkan DKIM sebagai a catatan TXT dan secara eksplisit membedakan kunci publik demonstrasi dari nilai akun itu sendiri. Panduan ini mengilustrasikan tanda. _domainkey sebagai pemilik TXT ; mengambil nama lengkap dan nilai publik saat ini dari pengaturan domain daripada memperlakukan ilustrasi sebagai bukti untuk setiap akun. Jangan menggunakan kembali contoh kunci panjang di artikel. SendPulse SMTP DKIM , Menyalin catatan domain yang ada.
Periksa semua rekaman yang ada pada pemilik pemilih yang diusulkan. Kunci yang sudah ada mungkin mendukung akun, penyedia, atau rute operasional yang berbeda. Mintalah resolusi yang didukung daripada menggantinya secara diam-diam atau membuat pemilih baru yang tidak akan digunakan oleh layanan. Menyimpan salinan catatan publik sebelumnya membantu peninjau menilai pemulihan, namun tidak mengizinkan pemulihan kunci usang tanpa mengoordinasikan status penandatanganan.
Gunakan penyedia DNS resmi, belum tentu pencatat domain. Konfirmasikan apakah editor mengharapkan host relatif atau nama yang sepenuhnya memenuhi syarat. Setelah menyimpan, tanyakan pemilik penuh dan bandingkan nilai publik lengkap dengan keluaran akun. String TXT dapat ditampilkan dalam segmen; bandingkan konten gabungannya daripada menyisipkan spasi di antara fragmen.
Hanya materi verifikasi publik yang termasuk dalam DNS atau lembar kerja implementasi. Kunci penandatanganan pribadi, kata sandi SMTP , dan rahasia API tidak diperlukan untuk peninjauan DNS . Berikan dukungan pada domain yang terpengaruh dan bukti catatan publik tanpa mengirimkan kredensial.
Verifikasi status koneksi dan pilihan pengirim
Dokumentasi Email menggunakan Periksa catatan DNS dan mengubah entri yang berhasil menjadi Tersambung. Petunjuk pengaturannya juga memerlukan domain yang diautentikasi agar cocok dengan domain alamat pengirim. Otentikasi Email SendPulse, Hasilkan catatan DKIM dan SPF Anda dan Periksa status entri.
Periksa status yang berlaku di tampilan layanan dan cap waktu rekaman. Jika satu tim melihat daftar domain yang berbeda, verifikasi bahwa kedua tim berada di akun yang dituju sebelum mengubah DNS . Jangan berasumsi status dari satu akun membuktikan akun lain sudah siap.
Kemudian periksa alamat pengirim yang dikonfigurasi dalam alur kerja pemasaran dan di setiap pengajuan aplikasi. Tinjau templat otomatis dan default aplikasi yang mungkin mempertahankan domain lama setelah migrasi. Pengirim yang dipilih di layar pratinjau dapat berbeda dari alamat yang digunakan oleh pekerjaan latar belakang. Tangkap pengaturan sebenarnya dari alur kerja seperti produksi yang sedang diuji.
Jaga agar konfigurasi domain pelacakan tetap berbeda. Domain pelacakan bermerek berguna untuk tautan, namun tidak menggantikan domain terotentikasi yang dipilih oleh pengirim. Catatan penerimaan tidak boleh menyimpulkan penyelarasan DKIM atau SPF dari nama host pelacakan atau pesan yang tampaknya bermerek.
Buktikan rute Email dan SMTP secara mandiri
Kirim pesan yang tidak berbahaya melalui satu kampanye representatif dan satu pengajuan aplikasi representatif. Tambahkan kasus lebih lanjut untuk domain Dari, penggantian aplikasi, atau pengaturan perutean yang berbeda. Gunakan penerima eksternal yang dikontrol dan pertahankan header asli, ID Pesan, waktu pengiriman, dan pengidentifikasi alur kerja.
Untuk setiap kasus, catat Dari yang terlihat, domain yang diautentikasi SPF, Return-Path , dan setiap nilai DKIM d= dan s=. Domain penandatanganan DKIM dan pemilih mengidentifikasi pencarian kunci publik; kunci yang valid di DNS saja tidak membuktikan pesan sebenarnya yang menggunakannya. RFC 6376 , Bidang Header DKIM-Signature dan Ekstrak Tanda Tangan dari Pesan.
Gunakan hasil penerima tepercaya untuk membedakan sandi kriptografi dengan sandi yang selaras. DMARC dapat melewati hasil SPF atau DKIM yang memenuhi syarat, dan mode penyelarasan memengaruhi perbandingan domain. Catat mekanisme mana yang memberikan hasil, bukan hanya menulis “otentikasi berhasil”. RFC 9989 , Penjelasan Penyelarasan Pengidentifikasi dan Evaluasi DMARC.
Jika kampanye lolos tetapi aplikasi tidak, bandingkan terlebih dahulu pengirim, akun, dan rute sebenarnya. Jangan memutar kunci bersama sebagai respons pertama. Perubahan tersebut mungkin memengaruhi aliran pemasaran yang berfungsi dan membiarkan alamat Dari aplikasi yang salah tidak tersentuh.
Diagnosis masalah rekaman bersama tanpa mengganggu kedua layanan
Untuk kegagalan verifikasi DNS , periksa pemilik yang dipublikasikan, jenis rekaman, nilai lengkap, dan penyedia resmi. Untuk tanda tangan yang hilang, konfirmasikan bahwa pengujian menggunakan domain yang diautentikasi dan akun SendPulse yang dimaksudkan. Untuk kegagalan tanda tangan, bandingkan pemilih dan kunci yang diamati dan periksa apakah gateway lain mengubah konten yang ditandatangani.
Jika SPF berhasil tetapi DMARC gagal, bandingkan identitas sebelum menambahkan otorisasi. Jika pengiriman SMTP ditolak sebelum pengiriman, pisahkan kesalahan pengiriman dari hasil autentikasi penerima. Masalah kredensial, kuota, atau format aplikasi tidak dapat didiagnosis hanya dari pemeriksaan DNS . Pertahankan kesalahan yang sebenarnya tanpa menyalin rahasia ke dalam paket dukungan.
Jika persyaratan amplop khusus masih belum terpenuhi, dapatkan opsi yang didukung SendPulse untuk akun yang tepat. Instruksi yang ditinjau tidak menetapkan bahwa setiap pelanggan dapat menetapkan domain Return-Path yang diinginkan. Jangan menciptakan MX atau CNAME pengaturan untuk memperkirakan fitur yang belum dikonfirmasi.
Pemulihan lembar kerja dan kegagalan tes fiktif
Lengkapi lembar kerja domain bersama SendPulse (buat catatan ulasan terpisah dengan bidang yang dijelaskan di sini) dengan satu grup baris per domain terautentikasi dan satu entri bukti per rute Email atau SMTP . Catat tunjangan paket, ketergantungan pemilih yang ada, hasil DNS , konfigurasi pengirim, dan hasil pesan yang diterima. Tandai yang tidak diketahui secara eksplisit.
Kasus tertulis fiktif SP-01: asumsikan kampanye Dari courses@example.org telah lulus d=example.org, tetapi aplikasi pelajaran mengirimkan Dari lessons@old.example dengan hasil DKIM / SPF tidak diketahui. Status terhubung misalnya example.org tidak menetapkan otentikasi old.example . Pemilik aplikasi harus mengonfirmasi pengirim yang disetujui, membandingkan inventaris domain bersama, dan menguji rute pelajaran tanpa memutar kunci yang berfungsi. Tidak ada akun atau pesan yang diakses dan tidak ada koreksi atau pengujian yang dilakukan.
Sebelum melakukan perubahan, putuskan cara menjeda setiap streaming yang terpengaruh dan memulihkan konfigurasi pengirim terakhir yang disetujui. Koordinasikan setiap penggantian kunci dengan semua layanan yang membagikannya. Saat pensiun, hentikan setiap aplikasi dan kampanye dependen sebelum menghapus catatan autentikasi. Tes ulang setelah perubahan paket, migrasi akun, perubahan hosting DNS , atau rute aplikasi baru.
Tutup hanya lingkup yang diuji
Penerimaan memerlukan kepemilikan domain yang benar, catatan yang dikeluarkan akun, DNS publik yang valid, status penyedia yang terhubung, pemilihan pengirim yang dituju, dan bukti penerima tepercaya untuk setiap rute material. Kampanye terverifikasi tidak menutup integrasi SMTP yang belum teruji. Akun live, pemeriksaan DNS dan pesan, tinjauan teknis independen, tinjauan visual, dan persetujuan UKM manusia masih menunggu keputusan; draf ini tidak dipublikasikan dan tidak mengklaim penerapan telah selesai.
Pisahkan pesan yang lewat dari kesiapan penegakan
RFC 9989 Bagian 7.4 memerlukan DKIM yang valid untuk penerbitan domain p=reject dan peringatan tentang interoperabilitas surat 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.