Rekonsiliasi nama Pepipost dengan akun sebenarnya
Label Pepipost dalam integrasi lama atau catatan DNS tidak cukup untuk memilih prosedur pengaturan saat ini. Dokumentasi Netcore Email API yang disimpan masih berisi referensi Pepipost saat menjelaskan verifikasi domain Netcore Email API. Identifikasi akun, titik akhir aplikasi, domain pengiriman, dan versi dokumentasi sebelum mengubah DNS . Artikel ini membahas autentikasi yang dikeluarkan akun untuk rangkaian produk yang terdokumentasi tersebut; itu tidak menjanjikan bahwa setiap akun lama menggunakan catatan atau antarmuka yang identik.
Mulailah dengan bukti pemilik aplikasi. Catat apakah aplikasi dikirimkan melalui konfigurasi SMTP atau integrasi API, akun atau sub-akun mana yang memilikinya, dan alamat Dari mana yang dapat digunakan. Pertahankan titik akhir dan kredensial yang berfungsi saat ini di penyimpanan rahasia yang disetujui. Penelitian autentikasi tidak memerlukan penyalinan kunci API ke lembar kerja atau melampirkannya ke permintaan dukungan.
Selesaikan konflik jenis rekaman yang terdokumentasi
Itu Panduan Netcore SPF dan DKIM menggambarkan dua catatan TXT. Pihak pertama lainnya artikel verifikasi domain memperkenalkan dua CNAME catatan, namun juga membahas penggantian yang sudah ada SPF kebijakan TXT . Halaman-halaman ini tidak membuat satu resep pencatatan yang jelas untuk setiap akun. Perlakukan konflik tersebut sebagai alasan untuk mendapatkan catatan lengkap yang dikeluarkan dari akun live, bukan izin untuk memilih jenis hanya dengan menebak-nebak.
Di akun yang dituju, kumpulkan pemilik rekaman, jenis dan nilai untuk domain yang tepat. milik Netcore Dapatkan referensi API Domain pengambilan dokumen SPF , DKIM dan catatan DNS amplop khusus untuk domain milik klien yang meminta. Ini juga membedakan permintaan yang dibuat untuk sub-akun. Dasbor atau administrator resmi dapat memberikan bukti akun yang setara tanpa mengungkapkan kredensial dalam catatan perubahan.
Jika data yang dikeluarkan bertentangan dengan panduan publik atau catatan yang ada, tanyakan kepada dukungan Netcore terverifikasi konfigurasi mana yang berlaku. Simpan jawabannya dan jangan publikasikan kedua jenis yang tidak kompatibel pada satu pemilik. Mengonfirmasi identitas akun sangat penting ketika integrasi lama dan sub-akun baru menggunakan domain bisnis yang sama.
Publikasikan tanpa mengganti otorisasi yang tidak terkait
Siapkan tiket perubahan yang berisi kumpulan catatan lengkap yang diterbitkan dan ekspor sebelum negara bagian. Tinjau nama pemilik terhadap perilaku nama relatif editor DNS . Untuk CNAME , periksa apakah pemiliknya belum ditempati oleh data yang tidak kompatibel. Untuk SPF berbasis TXT , pertahankan satu kebijakan SPF pada pemilik tersebut dan pertahankan layanan pengiriman sah lainnya. Jangan pernah mengganti otorisasi email organisasi hanya karena dasbor menampilkan contoh sederhana.
Evaluasi kebijakan SPF secara penuh, termasuk penyertaan tersarang, terhadap RFC 7208. Itu Batas pencarian DNS berlaku untuk evaluasi, jadi menghitung kata-kata yang terlihat di catatan tingkat atas tidaklah cukup. Jika otorisasi baru melebihi batas, selesaikan desain dengan pemilik domain sebelum aktivasi. Jangan mengonversi otorisasi yang dikelola penyedia ke daftar IP berkode keras sebagai pintasan yang belum ditinjau.
Periksa jawaban DNS otoritatif untuk setiap catatan yang dikeluarkan. Catatlah secara lengkap pemilik, jenis, jawaban dan waktu revisi perubahannya. Penyelesai publik masih dapat mengembalikan nilai cache setelah rekaman otoritatif berubah, jadi bedakan kesalahan publikasi dari cache. Hindari menjanjikan waktu penyebaran yang tetap yang tidak dapat dibuktikan dengan bukti yang ada.
Pisahkan verifikasi DNS dari izin mengirim
milik Netcore panduan otentikasi menjelaskan pemeriksaan DNS dan proses persetujuan domain terpisah, termasuk tinjauan manual untuk beberapa domain. Catat negara bagian tersebut secara terpisah. Domain terotentikasi yang menunggu persetujuan penyedia tidak boleh didiagnosis sebagai kegagalan DNS hanya karena pengiriman belum tersedia. Sebaliknya, akun yang disetujui tidak membuktikan setiap domain Dari diverifikasi.
Setelah akun mengizinkan rute yang dimaksud, kirimkan pesan terkontrol yang tidak berbahaya dari jalur aplikasi sebenarnya. Bandingkan Dari yang dikonfigurasi dengan Dari yang diterima, Return-Path, DKIM d= dan s=, serta hasil autentikasi tepercaya penerima. Jangan menyimpulkan fitur amplop khusus dari keberadaan CNAME pelacakan atau berasumsi bahwa SPF milik penyedia secara otomatis selaras dengan domain Anda.
Hasil SPF atau DKIM yang selaras dapat memuaskan DMARC di bawah yang berlaku penyelarasan mode. RFC 6376 menyediakan semantik tanda tangan dan RFC 9989 menyediakan kerangka penyelarasan. Catat mekanisme yang benar-benar lolos daripada melaporkan status hijau umum dari verifikasi domain.
Lembar kerja penerimaan Pepipost dan Netcore
Buat satu entri untuk setiap akun atau sub-akun dan domain pengirim:
- Pengidentifikasi akun dan label produk saat ini: ____; aplikasi dan pemilik: ____.
- Rute pengiriman dan referensi titik akhir: ____; kredensial dikecualikan dari bukti: ____.
- Dari domain dan alamat yang disetujui: ____; instruksi lama masih digunakan: ____.
- Kumpulan catatan dan revisi yang diterbitkan akun: ____; Konflik TXT atau CNAME diselesaikan dengan: ____.
- Tabrakan DNS yang ada: ____; Pelestarian SPF dan tinjauan pencarian: ____.
- Bukti DNS resmi: ____; status verifikasi dasbor: ____.
- Negara persetujuan domain dan referensi penyedia: ____.
- Uji ID Pesan, waktu dan penerima: ____; Dari dan Return-Path : ____.
- DKIM d= dan s=: ____; hasil yang tepercaya dan mekanisme yang selaras: ____.
- Keputusan percontohan bisnis, pemilik pemulihan, dan pengecualian yang belum terselesaikan: ____.
Pertahankan verifikasi dan persetujuan di bidang yang berbeda meskipun antarmuka menampilkan keduanya berdekatan. Hal ini membuat eskalasi menjadi spesifik: pemilik dapat mengetahui apakah masalahnya menyangkut catatan, tinjauan penyedia, atau pesan benar-benar dikirimkan.
Diagnosis fiktif dari domain yang disetujui dengan email yang gagal
Hanya contoh fiktif: Alder Billing mengonfirmasi domain Netcore barunya telah diverifikasi dan disetujui, namun pengujian faktur masih membawa identitas penandatanganan rute lama. Pemilik aplikasi menemukan bahwa pekerjaan produksi menggunakan konfigurasi akun yang berbeda dari dasbor yang diperiksa. Tim berhenti memperlakukan status hijau dasbor sebagai bukti untuk pekerjaan tersebut, merekonsiliasi rute pengiriman sebenarnya dan mengulangi pengujian dengan catatan yang dikeluarkan akun yang benar.
Jika rutenya cocok tetapi tanda tangannya gagal, selidiki yang dipublikasikan pemilih dan penanganan pesan sebelum mengubah DMARC . Jika autentikasi lolos namun pesan ditolak, pertahankan respons SMTP dan selidiki penolakan spesifik tersebut secara terpisah. Tidak ada akun Alder, titik akhir, tugas produksi, atau faktur yang diterima yang diuji di sini.
Lingkup dan gerbang yang tersisa
Perbedaan TXT-versus-CNAME publik dan penerapan akun lama tetap berlaku hingga cakupan terselesaikan untuk penyewa yang dituju. Ini adalah metode konfigurasi dan penerimaan, bukan pemilih universal atau resep penyertaan. Inspeksi akun live, konfirmasi catatan yang diterbitkan, pemeriksaan DNS , persetujuan penyedia, pengujian penerima, tinjauan yang diberikan, persetujuan dan publikasi UKM manusia masih tertunda.
Selesaikan konflik dokumentasi dalam keputusan tertulis
Resolusi yang diusulkan harus mengidentifikasi akun atau sub-akun, domain pengirim, versi dokumen sumber, kumpulan pemilik/jenis/nilai yang diterbitkan secara lengkap, dan konfirmasi penyedia dari cabang yang berlaku. Pertahankan contoh kontradiktif di depan umum sebagai konteks, bukan sebagai catatan tambahan untuk dipublikasikan. Jika bukti akun saat ini tidak tersedia, biarkan baris konflik tersebut ditahan. Lembar kerja yang ada adalah bahan persiapan dan tidak berisi catatan akun yang baru diambil.