Kenapa e-mel anda masuk spam — dan empat rekod DNS yang menentukannya

Hampir setiap tiket “e-mel kami masuk spam” yang kami buka berakhir sama: tiada apa yang rosak dari segi teknikal, tiada salah tetapan dalam klien mel, namun separuh mesej tetap tidak masuk peti masuk. Puncanya hampir tidak pernah baris subjek. Puncanya ialah pelayan penerima tidak dapat menjawab satu soalan — betulkah ini daripada domain itu? — dengan “ya”.

Panduan ini ialah senarai semak yang kami jalankan sebelum memberi sebut harga bagi pembaikan kebolehhantaran, ditulis supaya anda boleh jalankannya sendiri dalam kira-kira sepuluh minit. Syaratnya satu: anda boleh mengubah DNS.

Penerima bertanya empat soalan, bukan sepuluh

Gmail, Outlook dan Yahoo tidak menilai HTML anda. Mereka bertanya empat soalan ya/tidak, setiap satu dijawab oleh satu rekod DNS:

Soalan	Rekod	Apa yang dibuktikan
Ke mana e-mel domain ini dihantar?	MX	Domain itu boleh menerima — MX rosak menyebabkan batal kelihatan seperti penolakan spam
IP mana yang boleh menghantar sebagai domain ini?	SPF (TXT)	IP penghantar ada dalam senarai anda
Adakah mesej meninggalkan dengan tandatangan anda utuh?	DKIM (selector._domainkey)	Mesej tidak diubah dalam perjalanan, dan domain mana yang menandatangani
Apa perlu saya buat apabila dua yang pertama bercanggah?	DMARC (_dmarc)	Dasar anda, dan ke mana laporan dihantar

Selebihnya — kandungan, pautan, imej, subjek — ialah isyarat sekunder. Membaiki rekod tidak menjamin peti masuk, tetapi tiada teks yang bagus mampu bertahan daripada kegagalan penjajaran.

Penjajaran ialah bahagian yang selalu terlepas pandang

SPF dan DKIM kedua-duanya menghasilkan “lulus”, dan kedua-duanya boleh jadi tidak berguna. Yang sebenarnya diperiksa DMARC ialah penjajaran: adakah domain yang lulus SPF atau DKIM sepadan dengan domain dalam header From yang dilihat penerima?

Perbezaan ini penting sebaik sahaja relay terlibat. Apabila pelayan anda menyerahkan mesej kepada perkhidmatan penghantaran, pengirim sampul biasanya menjadi seperti em1234.domainanda.com — subdomain milik penyedia. SPF kemudian lulus untuk nama itu. Jika DMARC ditetapkan aspf=s (ketat), em1234.domainanda.com tidak sejajar dengan domainanda.com, dan mesej gagal DMARC walaupun setiap semakan individu kelihatan sihat. Gunakan adkim=r dan aspf=r sehingga anda mengesahkan semua penghantar, kemudian ketatkan hanya jika anda mengawal setiap sampul.

Logik sama berlaku pada DKIM: tandatangan dengan d=domainanda.com yang masih utuh selepas transit itulah yang menyelamatkan mesej yang SPF-nya gagal. Kerana itu kami menuntut kedua-dua kaki, bukan yang lebih mudah.

Empat kegagalan yang paling kerap kami lihat

1. Tiada rekod SPF langsung. Domain boleh menghantar dari klien yang mengabaikan rekod itu, dan gagal di semua tempat yang tidak mengabaikannya. Jawapan kosong bukan kebenaran.
2. SPF tidak meliputi penghantar sebenar. Rekod yang hanya menyenaraikan mx sedangkan invois keluar melalui API pihak ketiga ialah janji yang tidak ditepati. Setiap penyedia yang ditambah mesti ada dalam senarai.
3. DKIM diputuskan oleh laluan. Pelayan sendiri menandatangani, relay menulis semula pengaki badan, tandatangan mati. Anda kemudian bergantung pada penjajaran SPF yang tidak pernah meliputi domain itu.
4. DMARC kekal pada p=none. Laporan tiba, tiada apa dikuatkuasakan, dan pemalsu boleh menghantar sebagai anda tanpa akibat. p=none ialah titik permulaan, bukan tempat berehat.

Ada juga rekod yang tidak kelihatan dari luar: dua rekod SPF pada nama yang sama. Penerima menganggapnya ralat kekal, bukan gabungan. Jika anda pernah menampal v=spf1 kedua di sebelah yang pertama, setiap semakan SPF untuk domain itu gagal sejak hari itu.

Jalankan semakan sebelum mengubah apa-apa

Taip domain anda dalam semakan kesihatan e-mel percuma kami. Ia menanyakan MX, SPF, DKIM dan DMARC dari pelayar anda kepada resolver awam — tiada pendaftaran, tiada pelayan di tengah, tiada apa dihantar ke pelayan mel anda — dan memberitahu mana satu yang hilang atau lemah, berserta rekod yang perlu ditambah.

Baca dalam urutan ini:

• MX hilang atau menunjuk ke tempat kosong → baiki penerimaan dahulu; yang lain tidak bermakna.
• SPF hilang atau berbilang → satu rekod, senaraikan setiap penghantar sah, akhiri dengan -all setelah pasti.
• DKIM hilang → terbitkan selector yang diberikan penyedia, dan pastikan domain d= sepadan dengan domain From.
• DMARC hilang atau p=none → terbitkan atau ketatkan dasar, dan tambah alamat rua= yang benar-benar anda baca.

Urutan pembaikan

Rekod dahulu, dasar kemudian. Mengubah DMARC sebelum SPF dan DKIM betul hanya mengajar penerima menolak e-mel anda sendiri.

1. Terbitkan atau baiki SPF: satu rekod, senaraikan semua penghantar.
2. Terbitkan DKIM untuk setiap penghantar, sahkan mesej sebenar lulus dengan tandatangan utuh.
3. Terbitkan DMARC pada p=none dengan peti rua= yang dipantau.
4. Baca laporan agregat selama satu hingga dua minggu. Ia XML, hodoh, dan satu-satunya jawapan jujur kepada “siapa menghantar sebagai kami”.
5. Naikkan dasar secara berperingkat — p=quarantine; pct=25, kemudian pct=100, kemudian p=reject — dan terus pantau antara peringkat.

Setiap langkah boleh dibalikkan. Satu-satunya kesilapan yang tidak boleh dibalikkan ialah melompat terus ke peringkat terakhir.

Apa yang rekod tidak boleh baiki

Kami lebih suka menyatakannya terus daripada menjual pembaikan yang tidak mungkin berkesan. Jika rekod betul dan e-mel masih masuk spam, puncanya bersifat tingkah laku:

• Reputasi IP penghantar, terutamanya IP dikongsi yang anda tidak kawal.
• Penyenaraian senarai hitam — semak yang besar dahulu sebelum menyalahkan Gmail.
• Corak kandungan dan pautan yang mencetuskan penapis, termasuk pemendek pautan dan domain pautan yang tidak sepadan.
• Jumlah dan kelajuan — domain baharu yang menghantar 2,000 mesej pada hari pertama kelihatan sama seperti serangan spam.
• Kadar aduan — satu pembelian senarai kotor boleh menghapuskan berbulan-bulan penghantaran bersih.

Semua itu dibaiki dengan sejarah penghantaran, kebersihan senarai dan masa. Rekod hanya membuang alasan: dengan SPF, DKIM dan DMARC sejajar, penerima berhenti menilai anda berdasarkan reputasi IP orang lain dan mula menilai tingkah laku sebenar anda — satu-satunya isyarat yang boleh anda tingkatkan.

Jika anda mahu serahkan kepada kami

Kami lakukan ini sebagai kerja berskop tetap: audit rekod semasa, terbitkan set yang betul, uji dengan mesej sebenar ke Gmail, Outlook dan Yahoo, kemudian pantau laporan minggu pertama dan beritahu apa yang berubah. Atau ambil senarai semak di atas dan lakukan sendiri — semakan percuma itu akan memberitahu bila anda sudah selesai.