Berhenti meneka DNS anda: jelajah mesra pembangun tentang MX, SPF, DKIM dan DMARC

Mengapa rekod DNS e-mel penting sekarang

Pengesahan e-mel dahulu bersifat pilihan. Pada 2026, ia menjadi keperluan asas. Gmail dan Outlook kedua-duanya menguatkuasakan SPF dan DKIM untuk penghantar pukal, dan DMARC semakin pantas menjadi wajib bagi mana-mana domain yang menghantar e-mel transaksi. Jika rekod DNS anda salah, e-mel anda tidak sampai—tiada bounce, tiada amaran, hanya senyap.

Masalahnya ialah rekod-rekod ini didokumenkan seperti RFC, bukan seperti alat. Kebanyakan pembangun menyalin dan menampal contoh daripada panduan persediaan penyedia e-mel mereka dan berharap semuanya baik-baik saja. Itu berkesan sehinggalah anda perlu menyelesaikan masalah, menambah perkhidmatan penghantaran kedua, atau menerangkan kepada klien mengapa e-mel borang hubungan mereka masuk ke spam.

Panduan ini menerangkan MX, SPF, DKIM dan DMARC mengikut urutan yang sebenarnya akan anda temui, dengan perincian yang cukup untuk mengkonfigurasikannya dengan betul dan konteks yang cukup untuk menyahpepijatnya apabila ia rosak.

Rekod MX: ke mana e-mel masuk pergi

Rekod MX memberitahu internet pelayan mel mana yang menerima e-mel untuk domain anda. Ia yang paling mudah antara empat ini, tetapi juga paling mudah tersalah konfigurasi.

Rekod MX mempunyai dua bahagian: nombor keutamaan dan nama hos. Nombor keutamaan yang lebih rendah akan dicuba dahulu. Jika anda menggunakan Google Workspace, rekod MX anda mungkin kelihatan seperti ini:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Titik di hujung itu penting—ia menandakan bahawa nama hos tersebut lengkap sepenuhnya. Kebanyakan penyedia DNS menambahnya secara automatik, tetapi bukan semuanya.

Kesilapan biasa: menghalakan rekod MX kepada rekod A dan bukannya nama hos, menetapkan semua keutamaan kepada nombor yang sama (yang menggagalkan tujuan mempunyai sandaran), atau terlupa membuang rekod MX lama apabila anda berpindah penyedia. Rekod MX basi bukan sekadar berada di situ tanpa bahaya—ia boleh menyebabkan gelung mel atau membahagikan penghantaran merentas dua peti masuk.

Jika anda menjalankan borang hubungan sendiri dan mahu mengelakkan spam tanpa bergantung pada perkhidmatan pihak ketiga, memahami bagaimana borang menjadi vektor spam ialah titik mula yang berguna.

SPF: pelayan mana yang dibenarkan menghantar sebagai anda

SPF (Sender Policy Framework) ialah rekod TXT yang menyenaraikan alamat IP dan domain yang dibenarkan menghantar e-mel bagi pihak domain anda. Ia semakan pertama yang dilakukan oleh kebanyakan pelayan mel apabila menerima mesej yang mendakwa datang daripada anda.

Rekod SPF asas kelihatan seperti ini:

v=spf1 include:_spf.google.com ~all

Pecahannya:

• v=spf1 mengisytiharkan versi SPF
• include:_spf.google.com menyerahkan kepada rekod SPF Google
• ~all ialah kegagalan lembut—tolak mel daripada sumber yang tidak disenaraikan, tetapi jangan terlalu ketat

Anda juga boleh menggunakan ip4: atau ip6: untuk membenarkan alamat tertentu, atau a dan mx untuk merujuk rekod A dan MX domain anda. Mekanisme all di hujung mengawal apa yang berlaku kepada mel daripada sumber yang tidak anda senaraikan: -all ialah kegagalan keras (tolak), ~all ialah kegagalan lembut (tandakan sebagai mencurigakan), ?all ialah neutral (tiada pendirian), dan +all ialah bebas untuk semua (jangan gunakan ini).

SPF mempunyai dua sisi tajam. Pertama, ia rosak apabila e-mel dimajukan, kerana pelayan pemajuan tidak berada dalam rekod SPF anda. Kedua, rekod SPF mempunyai had carian sebanyak sepuluh pertanyaan DNS. Jika anda memasukkan terlalu banyak perkhidmatan pihak ketiga, anda akan melebihi had tersebut dan SPF akan berhenti berfungsi. Penyelesaiannya ialah meratakan rekod SPF anda—gantikan arahan include: dengan julat IP sebenar—tetapi ini memerlukan penyelenggaraan apabila penyedia menukar IP mereka.

DKIM: bukti kriptografi identiti penghantar

DKIM (DomainKeys Identified Mail) menambahkan tandatangan digital pada e-mel keluar anda. Pelayan penerima menyemak tandatangan itu terhadap kunci awam yang diterbitkan dalam DNS anda. Jika tandatangan sah dan mesej tidak diusik, DKIM lulus.

Tidak seperti SPF, DKIM bertahan apabila dimajukan, kerana tandatangan bergerak bersama mesej. Ia juga lebih fleksibel—anda boleh mempunyai berbilang kunci DKIM untuk perkhidmatan penghantaran yang berbeza, setiap satu dengan selector tersendiri.

Rekod DNS DKIM kelihatan seperti ini:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Selector (default dalam contoh ini) adalah sewenang-wenangnya—penyedia e-mel anda yang memilihnya. Nilai p= ialah kunci awam, biasanya rentetan panjang yang dikodkan base64. Penyedia e-mel anda menjana kunci peribadi dan menggunakannya untuk menandatangani mesej keluar.

Persediaan DKIM hampir selalu dikendalikan oleh penyedia e-mel anda. Tugas anda ialah menyalin rekod TXT yang mereka berikan dan menampalnya ke dalam DNS anda. Bahagian yang rumit ialah sesetengah penyedia DNS tidak mengendalikan rekod TXT yang panjang dengan baik—mereka sama ada memotongnya atau memerlukan anda memecahkan nilai itu kepada beberapa rentetan berpetik.

Untuk mengesahkan DKIM berfungsi, hantar e-mel ujian ke alamat Gmail dan semak pengepala. Cari dkim=pass dalam pengepala Authentication-Results.

DMARC: penguatkuasaan dasar dan pelaporan

DMARC (Domain-based Message Authentication, Reporting and Conformance) mengikat SPF dan DKIM bersama-sama dan memberitahu pelayan penerima apa yang perlu dilakukan apabila pengesahan gagal. Ia juga membolehkan pelaporan, supaya anda dapat melihat siapa yang menghantar e-mel sebagai domain anda—sama ada sah atau dipalsukan.

Rekod DMARC minimum kelihatan seperti ini:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none bermaksud pantau sahaja—jangan tolak atau kuarantin mesej yang gagal
• rua=mailto:[email protected] menentukan tempat laporan agregat dihantar

Apabila anda yakin SPF dan DKIM berfungsi, anda boleh mengetatkan dasar kepada p=quarantine (hantar kegagalan ke spam) atau p=reject (bounce terus). Anda juga boleh menetapkan dasar subdomain dengan sp= dan menentukan peratusan mesej untuk dikenakan dasar tersebut dengan pct=.

Laporan DMARC ialah fail XML yang dihantar setiap hari oleh penerima utama. Ia bertele-tele dan sukar dibaca secara mentah, tetapi ia memberitahu anda dengan tepat mesej mana yang lulus atau gagal pengesahan dan sebabnya. Jika anda melihat mel yang sah ditolak, laporan tersebut akan menunjukkan semakan SPF atau DKIM mana yang gagal.

Satu perkara yang mudah terlepas: DMARC memerlukan penjajaran. Untuk SPF, domain dalam pengepala Return-Path mesti sepadan dengan domain dalam pengepala From (atau menjadi subdomain). Untuk DKIM, domain d= dalam tandatangan DKIM mesti sepadan dengan domain From. Jika anda menggunakan perkhidmatan penghantaran pihak ketiga, mereka perlu menyokong laluan pulangan tersuai atau penandatanganan DKIM dengan domain anda, bukan domain mereka.

Cara mengaudit persediaan semasa anda

Kebanyakan isu DNS tidak kelihatan sehinggalah ia menyebabkan masalah. Berikut cara menyemak rekod anda sebelum sesuatu rosak:

1. Tanya rekod MX anda: dig MX example.com sepatutnya mengembalikan nama hos dan keutamaan pelayan mel anda. Sahkan ia sepadan dengan dokumentasi penyedia e-mel anda.

1. Semak sintaks SPF: dig TXT example.com dan cari rekod v=spf1. Jalankannya melalui pengesah SPF untuk mengesan ralat sintaks dan pelanggaran had carian.

1. Sahkan kunci DKIM: Hantar e-mel ujian dan periksa pengepala DKIM-Signature. Ekstrak selector dan domain, kemudian tanya dig TXT selector._domainkey.example.com untuk mengesahkan kunci awam wujud.

1. Sahkan dasar DMARC: dig TXT _dmarc.example.com sepatutnya mengembalikan rekod DMARC anda. Pastikan rua= menunjuk kepada alamat yang benar-benar anda pantau.

1. Uji hujung ke hujung: Gunakan perkhidmatan seperti mail-tester.com atau hantar ke alamat Gmail dan semak pengepala penuh. Cari spf=pass, dkim=pass, dan dmarc=pass dalam pengepala Authentication-Results.

Jika anda menyahpepijat sebab e-mel tidak sampai, pengepala ialah alat terbaik anda. Kebanyakan klien mel membenarkan anda melihat pengepala mentah—dalam Gmail, buka mesej, klik tiga titik, dan pilih 'Show original'. Pengepala Authentication-Results akan memberitahu anda dengan tepat semakan mana yang gagal dan sebabnya.

Bila perlu menggunakan dasar subdomain

Jika anda menghantar e-mel daripada berbilang subdomain—contohnya, newsletter.example.com untuk pemasaran dan app.example.com untuk mel transaksi—anda boleh menetapkan dasar DMARC bagi setiap subdomain. Ini membolehkan anda menguatkuasakan dasar ketat pada subdomain yang anda kawal sambil mengekalkan dasar yang lebih longgar pada domain utama anda.

Tolak ansurnya ialah kerumitan. Setiap subdomain memerlukan rekod SPF, DKIM, dan DMARC sendiri, dan anda perlu menjejaki perkhidmatan penghantaran mana yang dibenarkan untuk subdomain mana. Bagi kebanyakan pasukan kecil, satu domain yang dikonfigurasi dengan baik adalah lebih mudah dan sama selamat.

Apa yang perlu dilakukan apabila pengesahan rosak

Mod kegagalan paling biasa ialah menambah perkhidmatan penghantaran baharu tanpa mengemas kini DNS. Jika anda mula menggunakan penyedia e-mel transaksi baharu, anda perlu menambah include SPF atau julat IP mereka, mengkonfigurasi penandatanganan DKIM dengan domain anda, dan mengesahkan penjajaran DMARC.

Isu kedua paling biasa ialah pemajuan. Jika pengguna memajukan e-mel anda ke alamat lain, SPF akan gagal kerana pelayan pemajuan tidak berada dalam rekod SPF anda. DKIM biasanya bertahan apabila dimajukan, jadi selagi DKIM lulus dan dasar DMARC anda membenarkan penjajaran separa, mesej itu masih sepatutnya dihantar. Jika anda melihat mel yang dimajukan ditolak, semak dasar DMARC anda—p=reject dengan penjajaran ketat akan merosakkan pemajuan.

Isu ketiga ialah penyebaran DNS. Perubahan pada rekod DNS boleh mengambil masa berjam-jam untuk tersebar, dan pelayan mel yang berbeza menyimpan cache rekod untuk tempoh masa yang berbeza. Jika anda baru mengemas kini rekod dan ia belum berfungsi, tunggu beberapa jam dan uji semula. Anda boleh menyemak penyebaran dengan alat seperti whatsmydns.net.

Perkara utama

• Rekod MX menghala mel masuk; SPF, DKIM dan DMARC mengesahkan mel keluar. Ia menyelesaikan masalah yang berbeza dan anda memerlukan keempat-empatnya.
• SPF rosak apabila dimajukan dan mempunyai had sepuluh carian. DKIM bertahan apabila dimajukan tetapi memerlukan konfigurasi bagi setiap perkhidmatan. DMARC mengikat kedua-duanya dan membolehkan pelaporan.
• Mulakan dengan p=none dalam DMARC, pantau laporan selama beberapa minggu, kemudian ketatkan kepada p=quarantine atau p=reject apabila anda yakin mel sah lulus.
• Ralat DNS bersifat senyap. Uji konfigurasi anda dengan e-mel sebenar dan periksa pengepala untuk mengesahkan SPF, DKIM dan DMARC lulus.
• Jika pengesahan rosak selepas menambah perkhidmatan penghantaran baharu, semak include SPF, selector DKIM, dan penjajaran DMARC. Pengepala akan memberitahu anda semakan mana yang gagal.

FAQ

Q: Bolehkah saya mempunyai berbilang rekod SPF?

A: Tidak. Berbilang rekod SPF akan menyebabkan semuanya diabaikan. Jika anda perlu membenarkan berbilang perkhidmatan, gunakan arahan include: dalam satu rekod SPF, atau senaraikan julat IP secara langsung. Perhatikan had sepuluh carian.

Q: Adakah saya memerlukan DMARC jika saya hanya menghantar beberapa e-mel sehari?

A: Ya. DMARC bukan tentang volum—ia tentang membuktikan anda ialah siapa yang anda dakwa. Domain kecil sekalipun mendapat manfaat daripada DMARC kerana ia menghalang pemalsuan dan memberi anda keterlihatan terhadap isu penghantaran. Mulakan dengan p=none dan alamat pelaporan.

Q: Apa yang berlaku jika DKIM dan SPF kedua-duanya gagal tetapi e-mel kelihatan sah?

A: Ia bergantung pada dasar DMARC anda. Jika p=none, mel dihantar dengan amaran. Jika p=quarantine, ia masuk ke spam. Jika p=reject, ia dibounce. Inilah sebabnya anda patut memantau laporan DMARC sebelum menguatkuasakan dasar yang ketat—anda mungkin mempunyai penghantar sah yang tidak anda ketahui.

Q: Bolehkah saya menggunakan kunci DKIM yang sama untuk berbilang domain?

A: Secara teknikal ya, tetapi jangan. Setiap domain sepatutnya mempunyai pasangan kunci DKIM sendiri. Berkongsi kunci menjadikan putaran lebih sukar dan meningkatkan jejari impak jika kunci peribadi terkompromi.

Q: Berapa kerap saya patut memutar kunci DKIM?

A: Tiada peraturan sejagat, tetapi sekali setahun adalah munasabah untuk kebanyakan domain. Jika anda mengesyaki kunci telah terkompromi, putar dengan segera. Pastikan anda menerbitkan kunci awam baharu dalam DNS sebelum anda mula menandatangani dengan kunci peribadi baharu, dan biarkan kunci lama dalam DNS selama beberapa hari selepas putaran untuk mengendalikan mel yang tertangguh.

<!-- tool-cta:start -->

💡 Cuba ini: Periksa dasar yang diterbitkan bagi mana-mana domain dengan DMARC Lookup untuk melihat bagaimana rekod MX, SPF dan DMARC saling berkait dalam amalan.

<!-- tool-cta:end -->

Sumber

• RFC 7208: Sender Policy Framework (SPF) — Spesifikasi SPF, termasuk peraturan sintaks dan had sepuluh carian.
• RFC 6376: DomainKeys Identified Mail (DKIM) — Spesifikasi DKIM, meliputi penjanaan dan pengesahan tandatangan.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Spesifikasi DMARC, termasuk sintaks dasar dan format pelaporan agregat.
• Google Workspace: Prevent spoofing and spam — Panduan praktikal tentang konfigurasi SPF, DKIM dan DMARC untuk domain Google Workspace.