Identifikasi Netcore CE atau Netcore Email API terlebih dahulu
Label akun Netcore tidak cukup untuk memilih resep DNS . Netcore menerbitkan instruksi penyiapan domain terpisah untuk platform Customer Engagement (CE) dan API Emailnya. Halaman login produk mengidentifikasi Email API sebagai sebelumnya Pepipost. Catat produk, penyewa, atau sub-akun mana yang mengirimkan pesan dan apakah aplikasi tersebut menggunakan SMTP , integrasi API, atau kampanye CE. Jangan terapkan artikel Pepipost lama ke layar CE hanya karena keduanya membawa nama Netcore. Login produk Netcore, Penyiapan domain CE, Verifikasi API email.
Inventarisasi aliran nyata yang dihadapi pelanggan sebelum menambahkan domain pengirim. Tanda terima, tautan masuk, dan kampanye pemasaran mungkin memiliki pemilik aplikasi dan domain Dari yang berbeda. Untuk masing-masingnya, pertahankan pesan dasar atau kegagalan pengiriman, pengirim yang dikonfigurasi, status domain saat ini, dan siapa yang mengontrol DNS otoritatif. Langkah-langkah di bawah ini menjelaskan cabang yang terdokumentasi; nama host dan nilai yang dibuat akun lebih diutamakan daripada contoh.
API Email: pisahkan verifikasi DNS dari persetujuan
Panduan penyiapan API Email yang dipertahankan menjelaskan penerbitan dasbor yang disediakan SPF TXT dan unik DKIM catatan TXT, lalu gunakan Periksa Catatan DNS . Jika kebijakan sudah ada di pemilik SPF , gabungkan otorisasi yang diperlukan ke dalam kebijakan tersebut daripada menambahkan kandidat lain Catatan SPF. Jangan tempelkan contoh kebijakan lengkap di atas izin pengirim sah lainnya. Setelah verifikasi DNS , domain memasuki proses persetujuan yang dapat mencakup pemeriksaan otomatis dan peninjauan manual. Catatan DNS yang terverifikasi tidak dengan sendirinya menetapkan bahwa domain tersebut disetujui untuk dikirim. Verifikasi dan persetujuan domain API email.
Simpan kedua hasil di bidang lembar kerja terpisah. Jika DNS sudah benar namun persetujuan masih tertunda, selidiki status peninjauan akun dan minta informasi bisnis. Pengeditan DNS yang berulang dapat mengaburkan konfigurasi yang berfungsi tanpa memberikan persetujuan. Sebaliknya, akun yang aktif tidak membuktikan bahwa domain atau sub-akun pengirim tertentu sudah siap.
Panduan penjelasan Netcore juga menjelaskan revisi nilai SPF yang harus dipublikasikan oleh operator ketika kebijakan yang ada terdeteksi. Bandingkan nilai yang diusulkan dengan catatan otoritatif saat ini: tim lain mungkin telah mengubah DNS sejak dasbor pertama kali membacanya. Pertahankan izin yang disengaja dan nilai jalur pencarian lengkap. Untuk DKIM , gunakan nama host dan nilai yang terkait dengan domain yang dipilih. Penyeleksi terpisah dapat menyajikan layanan yang berbeda, namun memiliki nilai yang bertentangan pada satu layanan pemilih tidak diselesaikan dengan menumpuk kunci arbitrer. Email API SPF dan penjelasan DKIM, Aturan pemrosesan SPF.
CE: verifikasi setiap baris DNS yang dihasilkan
Dokumentasi CE menentukan Pengaturan → Domain email → Tambahkan domain. Setelah memasukkan domain, layar Konfigurasi DNS menyediakan tujuan, jenis, nama host, nilai, dan status setiap catatan. Jenis rekaman dapat mencakup TXT , CNAME dan MX ; salin baris yang sebenarnya disediakan untuk penyewa daripada menerapkan model dua-TXT API Email. Panduan ini mengatakan semua catatan yang dihasilkan harus dikonfigurasi dan diverifikasi. Gunakan Verifikasi, lalu selesaikan alurnya jika berhasil. CE Tambahkan Domain Email.
Panduan CE yang sama membedakan Sukses, Tertunda, Kesalahan, dan Migrasi. Pending dan Error tidak mengizinkan pengiriman. Ini juga memperingatkan bahwa mengedit nama host setelah verifikasi membuat domain tidak aktif dan memerlukan verifikasi ulang semua catatan. Perlakukan pengeditan nama host sebagai perubahan terkendali dengan risiko gangguan. Ketersediaan Unduh Pengaturan DNS berguna untuk penyerahan bukti; ini bukan bukti bahwa catatan tersebut telah dipublikasikan atau bahwa penerima telah mengautentikasi suatu pesan.
Jangan mengulang kembali inbound biasa organisasi data MX hanya karena baris yang dihasilkan menggunakan MX . Identifikasi terlebih dahulu pemilik sebenarnya dan tujuan yang ditunjukkan oleh penyewa. Subdomain pengirim atau pentalan dapat memiliki konfigurasi DNS sendiri. Teks publik yang ditinjau tidak membenarkan nama host CE universal, target MX , atau pemilih DKIM .
Amplop khusus: publikasi dan aktivasi adalah langkah yang berbeda
Netcore Email API secara terpisah mendokumentasikan sebuah kebiasaan Return-Path proses. Ini menjelaskan pemilihan subdomain, memublikasikan pemetaan CNAME yang disediakan, dan meminta tim pengiriman untuk mengaktifkan amplop khusus/ Return-Path dan DKIM untuk akun tersebut. Proses yang terdokumentasi tersebut berarti bahwa CNAME yang dipublikasikan saja bukanlah bukti bahwa pesan telah berpindah identitas. Konfirmasikan instruksi penyewa saat ini dan status aktivasi sebelum mengandalkan opsi ini. Artikel tersebut tetap menggunakan penamaan era Pepipost, jadi jangan menggeneralisasi target atau proses dukungannya ke CE. Return-Path kustom API email.
Putuskan mengapa amplop khusus diperlukan. Ini dapat memberikan jalur SPF yang selaras hanya jika domain amplop sebenarnya memenuhi domain Dari penyelarasan persyaratan dan izin SPF . Subdomain terkait dapat memenuhi penyelarasan yang santai, sedangkan penyelarasan ketat memerlukan kesetaraan domain yang tepat. Terverifikasi, selaras tanda tangan DKIM mungkin sudah menyediakannya DMARC jalur. Jangan menghapus data DNS yang diperlukan penyedia hanya karena DMARC hanya memerlukan satu mekanisme penerusan yang selaras. Aturan penyelarasan DMARC.
Isi lembar kerja Netcore khusus produk
Gunakan satu salinan per penyewa/sub-akun dan domain pengirim. Salin setiap baris DNS yang dihasilkan ke dalam entri bernomor terpisah daripada menciutkan beberapa tujuan menjadi satu.
- Produk: CE / API Email. Penyewa/sub-akun: ______. Lamaran atau kampanye: ______.
- Ditujukan Dari domain: ______. Pengirim yang dikonfigurasi saat ini: ______. Otoritas dan operator DNS : ______.
- Nomor baris yang dihasilkan: ______. Tujuan: ______. Pemilik: ______. Jenis: ______. Bukti nilai pasti: ______. Hasil resmi dan waktu UTC: ______.
- Izin SPF yang ada dipertahankan: ______. Penilaian pencarian DNS lengkap: ______.
- Status DNS domain: ______. Status persetujuan API, jika berlaku: ______. Tanggal bukti: ______.
- Perubahan nama host CE direncanakan? ______. Pemilik verifikasi ulang dan interupsi: ______.
- Amplop khusus diminta? ______. Pemilik yang diterbitkan: ______. Konfirmasi aktivasi penyedia: ______. Identitas amplop yang diterima: ______.
- Alur kerja pengujian dan ID pesan: ______. Dari domain: ______. Domain/hasil SPF : ______. Setiap DKIM
d=/s=/ hasil: ______. - Hasil DMARC penerima: ______. Mode penyelarasan dan jalur passing: ______.
- Pemeriksaan penanganan pentalan: ______. Rute pengembalian: ______. Pemberi persetujuan rilis: ______.
Aturan diagnostik: hilangnya data otoritatif adalah masalah publikasi; persetujuan API yang tertunda adalah masalah persetujuan layanan; amplop yang berbeda setelah publikasi adalah masalah aktivasi atau perutean. Tetapkan kegagalan kepada pemilik yang benar sebelum melakukan perubahan lainnya.
Diagnosis kerja fiktif: DNS terverifikasi, amplop lama
Contoh pelatihan fiktif, bukan hasil tes Netcore. Sebuah aplikasi mengirimkan tanda terima dari receipts.example. Pemiliknya telah mempublikasikan catatan DKIM akun tersebut dan meminta amplop khusus di bounce.receipts.example. Pesan yang diterima masih menggunakan amplop layanan yang tidak terkait, namun DKIM meneruskannya d=receipts.example. Penerima tepercaya melaporkan pass DMARC .
Lembar kerja ini menjelaskan kedua temuan tersebut: DKIM menyediakan jalur lalu lintas yang selaras; pemotongan amplop khusus masih belum terbukti. Administrator memeriksa apakah aktivasi penyedia terjadi dan apakah aplikasi menggunakan penyewa yang dituju. Menambahkan lebih banyak izin SPF ke receipts.example tidak akan mengubah amplop milik layanan dalam pesan itu. Setelah aktivasi dikonfirmasi, tanda terima baru harus menunjukkan amplop yang diharapkan dan penanganan pentalan yang berhasil.
Dalam kasus CE fiksi kedua, nama host terverifikasi diedit selama peluncuran kampanye dan domain menjadi tidak aktif. Respons yang benar adalah menyelesaikan verifikasi ulang yang diperlukan dan terus menunda pengiriman hingga CE mengizinkannya. Tiket persetujuan API Email akan mengatasi alur kerja produk yang salah.
Penerimaan dan pemulihan
Kueri pemilik rekaman yang tepat di DNS otoritatif, lalu bandingkan hasil rekursif dengan stempel waktu. Periksa tanda tangan yang diterima serta dasbor. Kunci DKIM yang diterbitkan membuktikan ketersediaan, bukan aplikasi yang menggunakan kunci tersebut; pengiriman API yang berhasil membuktikan penerimaan oleh suatu layanan, bukan penempatan kotak masuk. Gunakan transaksi dan penerima yang terkontrol, tanpa token reset nyata atau data pelanggan dalam paket ulasan. verifikasi DKIM.
Simpan DNS pra-perubahan dan pengaturan aplikasi. Jika rute baru gagal, jeda pengirim yang terpengaruh, pulihkan hanya konfigurasi yang diubah, dan uji pesan baru. Periksa pengiriman yang antri sebelum berpindah transportasi untuk menghindari duplikat. Jauhkan domain dan kampanye yang tidak terkait dari perubahan.
Tidak ada penyewa Netcore aktif, perubahan DNS , atau pesan yang diterima yang diuji untuk naskah ini. Lembar kerja dan contohnya merupakan bahan persiapan. Penerapan produk/penyewa saat ini, bukti aktivasi dan persetujuan, DNS resmi, pengujian pesan langsung, tinjauan visual, dan persetujuan UKM manusia tetap diperlukan sebelum dirilis.