Pilih rute dan identitas Postmark
Panduan ini mencakup pesan keluar yang sebenarnya dikirimkan ke Postmark , bukan situs web yang hanya menggunakan Postmark untuk pemrosesan masuk. Catat aplikasi, server Postmark dan aliran pesan, domain Dari yang dituju, dan administrator DNS . Tanda terima yang dikirim melalui aplikasi berbeda harus diuji secara terpisah meskipun mereknya terlihat sama. Sebelum mengubah DNS , simpan catatan yang ada dan pesan dasar dari alur kerja yang sebenarnya.
Alur kerja verifikasi domain Postmark menyediakan a DKIM catatan TXT dan adat Return-Path CNAME. Domain terverifikasi mengizinkan pengiriman dari alamat di seluruh domain tersebut, sehingga verifikasi domain harus dimiliki oleh tim yang berwenang untuk mewakilinya. Gunakan nilai yang ditampilkan untuk domain Anda, bukan nilai dari penyewa lain. Verifikasi domain Postmark.
Aktifkan penandatanganan sebelum mengubah kebijakan
Buka Tanda Tangan Pengirim, pilih domain dan masuk ke Pengaturan DNS . Salin nama host dan nilai DKIM ke data TXT di penyedia DNS resmi. Periksa apakah editor DNS menambahkan nama zona; akhiran yang digandakan akan meletakkan kunci di lokasi yang salah. Kembali ke Postmark dan verifikasi catatannya. Dokumen Postmark pemeriksaan otomatis dalam waktu 48 jam dan kontrol Verifikasi manual. Penandatanganan dimulai setelah verifikasi. pengaturan DKIM.
Jangan perlakukan status hijau sebagai ujian penerimaan akhir. Ini menetapkan bahwa penyedia menemukan sebuah rekor, bukan karena aplikasi produksi Anda menggunakan alamat Dari yang dimaksudkan atau gateway berikutnya mempertahankan tanda tangannya. Jadwalkan pengiriman terkontrol setelah verifikasi dan pertahankan pesan asli penerima, termasuk semua tanda tangan DKIM .
Tambahkan Return-Path yang didukung secara terpisah
Gunakan nama host Return-Path yang ditampilkan dalam pengaturan domain yang sama dan target CNAME nya, yang didokumentasikan sebagai pm.mtasv.net . Cadangan nama host yang tidak digunakan untuk tujuan ini. Jangan letakkan SPF Data TXT bersama CNAME dengan nama pemilik yang sama, dan jangan ganti data apex Anda dengan CNAME pentalan. Dokumentasi Postmark menunjukkan ejaan nama host default yang berbeda, sehingga nilai akun live lebih diutamakan daripada contoh yang disalin. Verifikasi domain.
Postmark tidak memerlukan pencantumannya di puncak pelanggan Catatan SPF. Pemeriksaan SPF mengikuti domain amplop sebenarnya. Menambahkan apex include tidak dapat mengubah Return-Path milik penyedia menjadi milik pelanggan. Return-Path kustom yang terdokumentasi adalah subdomain; Postmark menyarankan SPF yang santai penyelarasan untuk rute ini. Persyaratan SPF yang ketat tidak dapat diperbaiki dengan menambahkan lebih banyak penyertaan. Pertahankan kebijakan domain yang disetujui dan gunakan jalur DKIM yang terverifikasi dan selaras jika diperlukan. Panduan SPF Postmark.
Buktikan hasil aplikasinya
Berikut ini adalah desain penerimaan sintetis, bukan pengiriman yang diambil. Ganti setiap contoh dengan nilai yang diamati dan pertahankan stempel waktu pengujian dan ID pesan.
- Bukti: Terlihat Dari; Nilai ilustratif: receipts@example.com ; Pertanyaan penerimaan: Apakah ini identitas lamaran yang disetujui?
- Bukti: Domain amplop; Nilai ilustratif: pm-bounces.example.com ; Pertanyaan penerimaan: Apakah Return-Path khusus diaktifkan pada pesan ini?
- Bukti: domain penandatanganan DKIM ; Nilai ilustratif: example.com ; Pertanyaan penerimaan: Apakah penerima tepercaya memvalidasi tanda tangan ini?
- Bukti: DMARC; Nilai ilustratif: lulus; Pertanyaan penerimaan: Metode passing selaras manakah yang menghasilkan hasil ini?
- ra Dari domain example.com dan subdomain pentalan di bawahnya, penyelarasan SPF yang santai dapat berfungsi sedangkan penyelarasan SPF yang ketat tidak. Sebuah passing domain yang tepat tanda tangan DKIM masih bisa memuaskan DMARC . Evaluasi tanda tangan yang diamati, bukan janji bahwa setiap pesan ditandatangani. Penyelarasan DMARC.
Uji tanda terima nyata dan peristiwa pengaturan ulang kata sandi melalui jalur aplikasi masing-masing. Bandingkan aliran dan konfigurasi pengirimnya. Jika salah satu lolos dan yang lainnya gagal, selidiki rute yang berbeda sebelum mengubah DNS bersama. Jangan mengirimkan kembali tanda terima keuangan asli kepada pelanggan sebagai ujian.
Diagnosis dan pulihkan
Jika DKIM tidak ada, konfirmasikan domain Dari aplikasi cocok dengan domain terverifikasi dan penandatanganan aktif. Jika tanda tangan ada tetapi gagal, simpan alasan penerima dan periksa persisnya pemilih pencarian dan relai pengubah konten apa pun. Jika SPF lolos tetapi tidak selaras, periksa aktivasi Return-Path daripada menambahkan izin apex. Jika verifikasi DNS gagal, bandingkan jawaban resmi, lengkapi nama host, dan jenis catatan dengan nilai akun.
Jeda hanya aliran aplikasi yang terpengaruh jika penerimaan gagal. Pulihkan rekaman tersimpan atau pengaturan pengirim melalui pemilik perubahan, lalu uji ulang peristiwa yang dikontrol. Jangan menghapus pemilih lama saat email dalam antrean mungkin masih memerlukannya. Hentikan delegasi pentalan yang tidak digunakan dan catatan penandatanganan hanya setelah mengonfirmasi tidak ada aplikasi Postmark lain yang membagikannya. Naskah ini didasarkan pada dokumentasi; tidak ada penyewa, perubahan DNS , atau pengiriman langsung yang diuji.
Bandingkan hasil yang ketat dan santai secara eksplisit
Untuk kasus tertulis PM-01, asumsikan From receipts@example.com , KIRIM DARI bounce@pm-bounces.example.com dan izin SPF tepercaya untuk pm-bounces.example.com . Di bawah penyelarasan santai domain organisasi yang sama, jalur SPF tersebut selaras; dengan aspf=s itu tidak sama persis dengan example.com . Secara terpisah asumsikan tanda tangan yang lewat d=example.com, s=demo1: jalur tersebut sejajar dengan tepat dan dapat memenuhi DMARC bahkan dalam kasus SPF yang ketat. Jika DKIM menjadi tidak diketahui dan bukannya lolos, jangan simpan izin berdasarkan premis sebelumnya. Ini adalah masukan yang ditetapkan, bukan pengiriman cap Postmark atau saran untuk melemahkan suatu kebijakan.
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.