Semak rekod e-mel sebelum hantar: SPF, DKIM, DMARC

Sebelum sebuah laman menghantar e-mel kepada pelanggan, tiga rekod dalam DNS menentukan sama ada penerima mempercayainya: SPF, DKIM dan DMARC. Kesemuanya boleh diperiksa dalam beberapa minit, dan kebanyakan masalah e-mel masuk spam bermula di situ.

Artikel ini menerangkan apa yang setiap rekod lakukan, cara memeriksanya tanpa alat berbayar, cara membaca hasilnya, dan had penting: rekod yang betul tidak menjamin e-mel sampai ke peti masuk.

Apa yang diperiksa

SPF menyatakan pelayan mana yang dibenarkan menghantar e-mel bagi pihak domain awak. Ia satu rekod TXT pada domain itu sendiri. Penerima menyemak sama ada pelayan pengirim tersenarai dalam rekod tersebut.

DKIM menambah tandatangan digital pada setiap e-mel. Kunci awamnya disimpan dalam DNS pada nama seperti mail._domainkey.domain.com. Penerima menyemak tandatangan itu, dan jika ia sah, mereka tahu mesej tidak diubah dalam perjalanan dan benar-benar datang daripada pengirim yang memegang kunci.

DMARC memberitahu penerima apa yang perlu dibuat apabila SPF atau DKIM gagal, dan ia mengikat kedua-duanya kepada domain yang muncul dalam medan From. Tanpa DMARC, kegagalan SPF dan DKIM hanya dicatat, bukan ditolak. DMARC juga menerima laporan, jadi awak boleh nampak siapa yang menghantar menggunakan domain awak.

MX bukan sebahagian daripada pengesahan, tetapi ia diperiksa bersama kerana domain tanpa MX yang betul tidak boleh menerima balasan, termasuk balasan daripada pelanggan dan laporan DMARC.

Cara memeriksa sendiri

Kalau awak mempunyai akses terminal, tiga arahan ini sudah cukup untuk melihat rekod mentah:

dig +short TXT domain-awak.com
dig +short TXT _dmarc.domain-awak.com
dig +short TXT mail._domainkey.domain-awak.com
dig +short MX domain-awak.com

Cara itu memberi jawapan mentah. Ia berguna apabila awak tahu apa yang dicari, tetapi sukar dibaca apabila ada beberapa rekod, banyak lompatan include, atau pemilih DKIM yang tidak biasa.

Untuk pemeriksaan pantas, ada alat dalam talian yang memanggil DNS dan memulangkan ringkasan. Salah satunya MailSenpai, yang menyediakan endpoint JSON percuma tanpa kunci: app.mailsenpai.com/tools/dns-check?domain=domain-awak.com. Ia memeriksa SPF, DKIM, DMARC dan MX, dan memulangkan label yang boleh dibaca manusia.

curl "https://app.mailsenpai.com/tools/dns-check?domain=domain-awak.com"

// jawapan mengandungi: summary, to_fix, to_check, checks.spf, checks.dkim, checks.dmarc

Alat itu membaca rekod awam sahaja. Ia tidak membuktikan e-mel ditandatangani dengan betul, tidak membuktikan ia sampai ke peti masuk, dan tidak tahu sama ada awak menghantar daripada pelayan yang salah. Ia titik permulaan, bukan pengesahan akhir.

Cara membaca hasilnya

• ▸ SPF ok: ada satu rekod SPF, dan ia menyenaraikan pelayan yang awak gunakan.
• ▸ SPF lembut: rekod berakhir dengan ~all. Kegagalan tidak ditolak, hanya ditanda. Ini pilihan sementara yang munasabah semasa berpindah, tetapi bukan keadaan akhir.
• ▸ DKIM ok: kunci awam ditemui untuk pemilih yang dicari. Kalau pemilih tidak diketahui, alat mungkin mencuba beberapa nama biasa dan tetap tidak menjumpainya walaupun ia wujud.
• ▸ DMARC tiada: penerima tidak mempunyai arahan. Mula dengan p=none untuk mengumpul laporan, bukan terus p=reject.
• ▸ DMARC p=reject: arahan paling tegas. Ia betul hanya apabila SPF dan DKIM sudah lulus untuk semua penghantar sah, termasuk sistem tempahan, surat berita dan e-mel daripada aplikasi.

Kesilapan yang berulang

• ▸ Dua rekod SPF pada domain yang sama. Penerima menganggapnya sebagai ralat, dan kesannya semua penghantar gagal. Gabungkan menjadi satu rekod.
• ▸ Terlalu banyak lompatan include. SPF mempunyai had bilangan carian DNS, dan melebihi had itu menghasilkan kegagalan walaupun setiap include kelihatan betul.
• ▸ DKIM ditandatangani dengan domain lain. Tandatangan sah tidak membantu jika domainnya tidak sejajar dengan medan From. DMARC memerlukan penjajaran, bukan sekadar tandatangan.
• ▸ DMARC ditinggalkan pada p=none selama-lamanya. Laporan dikumpul, tetapi tiada perlindungan. Tetapkan tarikh untuk naik ke quarantine, kemudian reject.
• ▸ Rekod diubah tanpa menunggu TTL. Perubahan DNS tidak serta-merta, jadi ujian yang dibuat terlalu awal kelihatan gagal sedangkan ia belum tersebar.
• ▸ Domain baharu diuji dengan menghantar kepada diri sendiri. Mel kepada diri sendiri selalunya melalui laluan dalaman yang berbeza, jadi ia lulus walaupun penghantaran sebenar gagal.

Urutan pembaikan yang selamat

Apabila beberapa perkara salah, jangan betulkan semuanya serentak. Setiap perubahan boleh menghentikan e-mel yang sebelum ini sampai, dan sukar untuk tahu perubahan mana yang menyebabkan masalah jika semuanya diubah pada hari yang sama.

• ▸ Betulkan SPF dahulu. Pastikan hanya satu rekod wujud, dan setiap pelayan penghantar tersenarai. Uji dengan menghantar satu mesej sebenar.
• ▸ Kedua, hidupkan DKIM pada setiap saluran dan sahkan tandatangan muncul dalam pengepala mesej yang diterima.
• ▸ Ketiga, tambah DMARC dengan p=none dan alamat laporan yang benar-benar dibaca. Biarkan dua hingga empat minggu untuk melihat siapa yang menghantar bagi pihak domain awak.
• ▸ Keempat, naikkan ke quarantine, kemudian ke reject, satu langkah pada satu masa, dengan ujian hantar selepas setiap langkah.

Kadar perubahan itu nampak lambat, tetapi ia mengelakkan kejutan. Domain yang terus melompat ke p=reject tanpa laporan selalunya kehilangan e-mel tempahan atau surat berita daripada sistem yang tidak pernah disenaraikan dalam SPF.

Bila alat automatik tidak mencukupi

Pemeriksaan rekod hanya menjawab satu soalan: adakah DNS menyatakan perkara yang betul. Ia tidak menjawab sama ada pelayan awak benar-benar menandatangani mesej, sama ada penerima menolaknya, atau sama ada kandungan mesej menyerupai spam.

Untuk itu, awak perlu menghantar mesej sebenar dan membacanya. Hantar ke alamat ujian yang memberi skor, kemudian periksa pengepala yang diterima: cari keputusan spf, dkim dan dmarc pada mesej itu, bukan pada rekod DNS sahaja. Kalau DMARC melaporkan kegagalan tetapi DNS kelihatan betul, masalahnya pada pelayan yang menghantar, bukan pada rekod.

Perkara yang sama berlaku pada e-mel transaksi daripada aplikasi. Sistem tempahan yang menghantar melalui pelayan berasingan perlu disenaraikan dalam SPF dan ditandatangani, atau ia akan gagal walaupun e-mel utama lulus.

Contoh membaca keputusan yang bercampur

Bayangkan satu domain yang memulangkan SPF ok, DMARC ok, tetapi DKIM tidak dijumpai. Kesimpulannya bukan bahawa e-mel pasti gagal. DMARC boleh lulus melalui penjajaran SPF sahaja, jadi mesej masih sampai selagi pelayan penghantar berada dalam SPF dan domain dalam medan From sejajar.

Tetapi tanpa DKIM, tiada perlindungan terhadap pengubahsuaian mesej dalam perjalanan, dan sesetengah penerima memberi penalti reputasi kepada domain yang tidak menandatangani. Jadi ia bukan kegagalan segera, ia kelemahan yang patut ditutup.

Contoh kedua: SPF gagal tetapi DKIM lulus. Ini biasa apabila e-mel dihantar melalui perkhidmatan pihak ketiga yang menandatangani mesej tetapi tidak disenarikan dalam SPF. Penyelesaiannya bukan mematikan DKIM, tetapi menambah perkhidmatan itu ke SPF atau memastikan penjajaran DMARC menggunakan DKIM.

Senarai semak ringkas sebelum menghantar

• ▸ Satu rekod SPF, dan ia menyenaraikan semua pelayan penghantar yang sah.
• ▸ DKIM aktif untuk setiap saluran, dengan pemilih yang betul.
• ▸ DMARC wujud, bermula dengan p=none dan laporan dihantar ke alamat yang benar-benar dibaca.
• ▸ Rekod DMARC dinaikkan ke quarantine dan kemudian reject selepas laporan bersih.
• ▸ Alamat balasan berfungsi, dan MX menerima mel.
• ▸ Satu ujian hantar sebenar dibuat ke alamat luar, dan pengepalanya diperiksa.

E-mel transaksi dan surat berita tidak sama

E-mel transaksi, seperti resit dan pengesahan tempahan, dihantar secara automatik daripada sistem. Ia biasanya melalui perkhidmatan penghantaran berasingan, jadi ia perlu disenaraikan dalam SPF dan ditandatangani sendiri. Ramai pemilik laman hanya menguji e-mel peribadi mereka, lalu terkejut apabila resit tidak sampai.

Surat berita pula dihantar secara pukal, dan penerima menilai reputasi domain serta sejarah penghantaran. Domain baharu yang tiba-tiba menghantar seribu mesej akan disekat walaupun rekodnya sempurna. Dalam kes itu, masalahnya bukan DNS, tetapi jumlah dan masa. Mulakan dengan kumpulan kecil, dan biarkan reputasi terbina.

Selepas semuanya lulus, simpan satu rekod ringkas: pelayan mana yang menghantar, pemilih DKIM yang digunakan, dan siapa menerima laporan DMARC. Rekod itu menjimatkan masa enam bulan kemudian, apabila seseorang menambah sistem baharu dan e-mel mula gagal tanpa sebab yang jelas.

Kesimpulan

Memeriksa SPF, DKIM dan DMARC mengambil masa beberapa minit, dan ia menyelesaikan sebahagian besar masalah e-mel masuk spam sebelum ia berlaku. Alat percuma mempercepatkan pemeriksaan rekod, tetapi keputusan sebenar tetap datang daripada mesej yang dihantar dan pengepala yang diterima.

Kalau awak menguruskan e-mel untuk beberapa domain atau beberapa aplikasi, jadikan pemeriksaan ini sebahagian daripada senarai semak pelancaran, bukan kerja kecemasan selepas pelanggan mengadu e-mel mereka tidak sampai.