Security+ Academy · Pelajaran

Pengesahan E-mel: SPF, DKIM dan DMARC

Laksanakan dan sahkan dasar Sender Policy Framework, DomainKeys Identified Mail dan DMARC yang menghalang penyamaran domain serta pancingan data.

Pelajaran 1 daripada 413 langkah

Pengesahan E-mel: SPF, DKIM dan DMARC ialah pelajaran Security+ Academy percuma di CoddyKit. Ini ialah pelajaran 1 daripada 4. Sebanyak 3 pelajaran dalam laluan pembelajaran ini boleh dibaca sepenuhnya secara percuma — selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan praktikal dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Pelajaran ini merupakan sebahagian daripada laluan pembelajaran Security+ Academy, dan kemajuan anda disegerakkan merentas web serta aplikasi CoddyKit. Kursus Security+ Academy merangkumi sejumlah 4 pelajaran.

Masalah Pemalsuan E-mel

Protokol SMTP teras (direka pada tahun 1970-an) tidak mempunyai pengesahan pengirim terbina dalam. Mana-mana pelayan mel boleh mendakwa menghantar e-mel daripada mana-mana domain — teknik yang dipanggil email spoofing. Penyerang mengeksploitasi perkara ini untuk menghantar e-mel pancingan data yang kelihatan seolah-olah datang daripada organisasi yang sah (bank anda, CEO anda atau vendor yang dikenali). Tiga piawaian pengesahan e-mel berasaskan DNS dibangunkan untuk menangani masalah ini: SPF, DKIM dan DMARC. Setiap satunya menangani aspek pemalsuan yang berbeza dan berfungsi paling baik apabila digunakan bersama.

Sender Policy Framework (SPF)

SPF ialah rekod DNS TXT yang menentukan pelayan mel yang diberi kuasa untuk menghantar e-mel bagi pihak sesuatu domain. Apabila pelayan mel penerima menerima mesej yang mendakwa datang daripada example.com, pelayan itu mencari rekod SPF bagi example.com dan mengesahkan bahawa alamat IP pelayan penghantar disenaraikan. Jika IP tersebut tidak diberi kuasa, mesej itu boleh ditandakan sebagai spam atau ditolak. SPF menyemak envelope From address (arahan SMTP MAIL FROM), bukannya pengepala From paparan yang dilihat oleh pengguna.

# SPF DNS TXT record for example.com
# Authorize Google Workspace + SendGrid + company IP
example.com.  TXT  'v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all'

# Mechanism meanings:
# include:  authorize another domain's SPF record
# ip4:      authorize specific IPv4 address/range
# ip6:      authorize specific IPv6 address
# -all      FAIL (reject) mail from non-listed sources
# ~all      SOFTFAIL (accept but mark as spam)
# ?all      NEUTRAL (no policy stated)

Had SPF

SPF mempunyai dua had penting. Pertama, forwarding breaks SPF: apabila e-mel dimajukan, IP pelayan pemajuan tiada dalam rekod SPF domain asal, lalu menyebabkan SPF gagal pada e-mel sah yang dimajukan. Kedua, SPF hanya mengesahkan envelope From (tidak kelihatan kepada pengguna), bukannya From header yang kelihatan dalam klien e-mel. Penyerang masih boleh memalsukan pengepala From yang kelihatan sambil menggunakan envelope From yang lulus SPF — sebab itulah SPF sahaja tidak mencukupi. DKIM dan DMARC menangani jurang ini.

DomainKeys Identified Mail (DKIM)

DKIM menambahkan tandatangan kriptografi pada e-mel keluar. Pelayan mel penghantar menggunakan private key untuk menandatangani pengepala e-mel tertentu dan isi mesej, lalu menambahkan pengepala DKIM-Signature. public key diterbitkan sebagai rekod DNS TXT di bawah subdomain pemilih. Pelayan penerima mendapatkan public key dan mengesahkan tandatangan tersebut, sekali gus mengesahkan bahawa e-mel tidak diubah semasa penghantaran dan berasal daripada pelayan yang mempunyai akses kepada private key. Tidak seperti SPF, tandatangan DKIM kekal semasa pemajuan kerana dibawa dalam pengepala e-mel.

# DKIM DNS TXT record (selector: 'google')
google._domainkey.example.com.  TXT \
  'v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN...'

# DKIM-Signature header in email:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
  s=google; h=from:to:subject:date;
  bh=<body_hash>; b=<signature>

# Verification:
# 1. Extract 'b=' (signature)
# 2. Fetch public key at google._domainkey.example.com
# 3. Verify signature over 'h=' headers + body hash

Pemilih DKIM dan Putaran Kunci

DKIM menggunakan selectors untuk membolehkan beberapa public key digunakan serentak bagi satu domain — berguna untuk menjalankan berbilang perkhidmatan mel (Google Workspace + platform pemasaran) atau melakukan putaran kunci tanpa gangguan. Nama pemilih disertakan dalam pengepala DKIM-Signature supaya pelayan penerima mengetahui rekod DNS yang perlu ditanya. Organisasi hendaklah memutar kunci DKIM setiap tahun atau apabila kunci disyaki telah terjejas. Key length: kunci RSA minimum 2048-bit disyorkan; kunci 1024-bit tidak lagi disyorkan dan boleh dipecahkan dengan pengkomputeran moden.

DMARC: Pengesahan Mesej Berasaskan Domain

DMARC (Domain-based Message Authentication, Reporting, and Conformance) dibina berasaskan SPF dan DKIM dengan menambahkan: alignment check (domain dalam pengepala From yang kelihatan mesti sepadan dengan domain yang disahkan SPF atau DKIM) dan policy yang memberitahu pelayan penerima tindakan yang perlu diambil apabila mesej gagal. Dasar DMARC ialah none (pantau sahaja), quarantine (hantar ke folder spam) atau reject (jangan hantar). DMARC juga membolehkan aggregate reports (RUA) dan forensic reports (RUF) dihantar kembali kepada pemilik domain untuk mengetahui pihak yang menghantar bagi pihak anda.

# DMARC DNS TXT record
_dmarc.example.com.  TXT \
  'v=DMARC1; p=reject; sp=reject; \
   pct=100; \
   rua=mailto:dmarc-reports@example.com; \
   ruf=mailto:forensic@example.com; \
   adkim=s; aspf=s'

# p=reject   : reject failing messages (strongest)
# pct=100    : apply to 100% of messages
# adkim=s    : strict DKIM alignment
# aspf=s     : strict SPF alignment
# rua=       : aggregate report destination

Penjajaran DMARC

Penjajaran ialah perkara yang menjadikan DMARC berkuasa dalam menentang pemalsuan pengepala. Untuk penjajaran SPF, domain dalam SMTP envelope From mesti sepadan dengan domain dalam pengepala From yang kelihatan. Untuk penjajaran DKIM, domain penandatangan (d= dalam DKIM-Signature) mesti sepadan dengan domain pengepala From. Dalam mod ketat, domain mesti sepadan tepat. Dalam mod longgar, subdomain dibenarkan. Sesuatu email passes DMARC jika ia passes SPF ATAU DKIM dengan penjajaran yang betul — ia tidak perlu passes kedua-duanya. Gabungan ini menutup kelemahan yang ditinggalkan oleh SPF sahaja untuk pemalsuan pengepala yang kelihatan.

# DMARC alignment example
Envelope From: attacker@legit.com  <- SPF may PASS for legit.com
From header  : spoofed@example.com <- VISIBLE to user

# Without DMARC: SPF passes (envelope from legit.com)
# User sees spoofed@example.com and trusts it

# With DMARC on example.com:
# SPF alignment check: legit.com != example.com -> FAIL
# DKIM: attacker has no private key for example.com -> FAIL
# DMARC result: FAIL -> message rejected per policy

Melaksanakan DMARC Secara Berperingkat

Organisasi hendaklah melaksanakan DMARC secara berperingkat untuk mengelakkan gangguan terhadap email yang sah. Stage 1: Laksanakan SPF dan DKIM untuk semua aliran mel. Stage 2: Terbitkan rekod DMARC p=none dengan pelaporan RUA. Analisis laporan (alat: DMARC Analyzer, dmarcian) untuk mengenal pasti semua sumber penghantaran yang sah selama 2-4 minggu. Stage 3: Beralih kepada p=quarantine; pct=10, dengan meningkatkan pct secara beransur-ansur sehingga 100%. Stage 4: Beralih kepada p=reject selepas semua aliran yang sah passes. Tergesa-gesa beralih kepada reject sebelum mengenal pasti semua aliran mel akan menyebabkan email yang sah ditolak.

# DMARC rollout stages
Stage 1: p=none; pct=100  (monitoring only)
Stage 2: p=quarantine; pct=10  (10% to spam)
Stage 3: p=quarantine; pct=100 (all to spam)
Stage 4: p=reject; pct=100     (block at MTA)

# Monitor RUA reports between each stage
# Look for legitimate sources failing alignment
# Common gotchas:
# - Marketing platforms sending as your domain
# - IT ticketing systems
# - Automated notification services
# - Third-party CRM tools

BIMI: Penunjuk Jenama untuk Pengenalpastian Mesej

BIMI ialah standard baharu yang dibina berasaskan DMARC. Apabila sesuatu domain mempunyai polisi DMARC quarantine atau reject, klien email (Gmail, Apple Mail) boleh memaparkan logo jenama yang disahkan di sebelah nama pengirim dalam peti masuk. BIMI memerlukan Verified Mark Certificate (VMC) daripada penerbit yang diluluskan untuk mengesahkan pemilikan tanda dagangan. Walaupun BIMI belum lagi termasuk dalam peperiksaan Security+, ia menunjukkan hala tuju pengesahan email — menjadikan pengirim yang disahkan dapat dibezakan secara visual daripada pengirim yang dipalsukan dengan sekali pandang.

SPF+DKIM+DMARC Berfungsi Bersama

Ketiga-tiga standard ini membentuk sistem pengesahan email yang lengkap. SPF mengesahkan bahawa Server penghantaran diberi kuasa oleh pemilik domain. DKIM mengesahkan integriti mesej dan bahawa Organization penghantaran memiliki key peribadi. DMARC menghubungkan kedua-duanya dengan pengepala From yang kelihatan, menguatkuasakan policy terhadap kegagalan dan menyediakan Reporting. Tiada satu standard pun yang mencukupi: SPF sahaja tidak dapat menghalang pemalsuan pengepala yang kelihatan; DKIM sahaja tidak mewajibkan penolakan kegagalan; DMARC sahaja tanpa SPF atau DKIM tiada apa-apa untuk disemak. Ketiga-tiganya mesti dilaksanakan bersama untuk perlindungan penuh terhadap pemalsuan domain.

# Email authentication check order
1. Receiving MTA receives message
2. SPF check: is sending IP authorized? (envelope From)
3. DKIM check: is signature valid? (using public key DNS)
4. DMARC check:
   a. Did SPF pass with alignment? OR
   b. Did DKIM pass with alignment?
   -> If YES: PASS (deliver normally)
   -> If NO: apply DMARC policy (none/quarantine/reject)
5. Reporting: send aggregate data to rua= address

Sepanduk Email Luaran

Satu langkah pertahanan berlapis yang praktikal terhadap phishing dan BEC ialah menambahkan sepanduk amaran email luaran pada setiap mesej yang berasal dari luar Organization. Sepanduk ini — biasanya dimasukkan oleh SEG — memberi amaran kepada pekerja bahawa email tersebut datang daripada pengirim luaran, walaupun nama paparan kelihatan seperti nama rakan sekerja atau eksekutif. Sepanduk amat berkesan untuk menandakan cubaan BEC apabila penyerang menggunakan domain yang menyerupai domain sebenar atau memalsukan nama paparan. Sepanduk hendaklah mudah dibezakan secara visual (pengepala atau pengaki berwarna) dan hendaklah mengandungi arahan untuk melaporkan mesej yang mencurigakan.

# Example external email banner (SEG inserts this)
# --- EXTERNAL EMAIL ---
# This message was sent from outside the organization.
# Do not click links or open attachments unless
# you expected this email and trust the sender.
# Report suspicious email: phishing@company.com
# ----------------------

# Proofpoint SEG: add disclaimer via content filter
# Match: Header 'X-MS-Exchange-Organization-SCL' absent
# Action: Prepend HTML banner to message body

Semakan Pantas

Uji pemahaman anda tentang konsep CompTIA Security+ (SY0-701) daripada pelajaran ini.

Jawab dalam pelajaran interaktif

Imbas Kembali Pelajaran

Dalam pelajaran ini, anda telah mempelajari bahawa: SPF menggunakan rekod DNS TXT untuk membenarkan IP penghantaran tetapi hanya menyemak envelope From, bukan pengepala yang kelihatan; DKIM menambahkan tandatangan kriptografi yang mengesahkan integriti mesej dan kekal sah selepas penghantaran semula; dan DMARC menghubungkan SPF dan DKIM dengan pengepala From yang kelihatan melalui semakan penjajaran serta policy yang boleh dikuatkuasakan (none/quarantine/reject) bersama Reporting. Seterusnya, kita akan meneroka gerbang email selamat dan kawalan anti-spam.

Percuma untuk bermula

Pelajari Security+ Academy dengan tutor kecerdasan buatan — percuma

Tulis dan jalankan kod sebenar dalam pelayar anda, dapatkan bantuan segera daripada tutor kecerdasan buatan yang tersedia 24/7, dan sambung semula dari tempat anda berhenti di web atau dalam aplikasi.

Kursus: 30
Pelajaran: 120

Mula belajar secara percuma Lihat kursus penuh

Soalan Lazim

Adakah pelajaran “Pengesahan E-mel: SPF, DKIM dan DMARC” percuma?

Ya — sebanyak 3 pelajaran dalam laluan pembelajaran Security+ Academy, termasuk “Pengesahan E-mel: SPF, DKIM dan DMARC”, boleh dibaca sepenuhnya secara percuma di web ini. Selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan interaktif dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Kursus Security+ Academy merangkumi sejumlah 4 pelajaran.

Apakah yang akan saya pelajari dalam “Pengesahan E-mel: SPF, DKIM dan DMARC”?

Laksanakan dan sahkan dasar Sender Policy Framework, DomainKeys Identified Mail dan DMARC yang menghalang penyamaran domain serta pancingan data. Anda berlatih Security+ Academy menggunakan kod praktikal yang dijalankan terus dalam pelayar, manakala tutor kecerdasan buatan 24/7 menjawab soalan anda semasa anda mengikuti pelajaran.

Adakah saya memerlukan pengalaman untuk memulakan Security+ Academy?

Tiada pengalaman terdahulu diperlukan. Pembelajaran Security+ Academy di CoddyKit disusun untuk pelajar daripada peringkat pemula hingga lanjutan, jadi anda boleh bermula di sini atau dari awal dan belajar mengikut kadar anda sendiri. Ini ialah pelajaran 1 daripada 4.

Berapa lamakah pelajaran “Pengesahan E-mel: SPF, DKIM dan DMARC” diambil?

Kebanyakan pelajaran CoddyKit mengambil masa kira-kira 5–10 minit. Setiap pelajaran ringkas dan interaktif, jadi anda boleh membuat kemajuan secara berterusan dan menyambung tepat dari tempat anda berhenti di web atau aplikasi.

Bolehkah saya menulis dan menjalankan kod dalam pelajaran Security+ Academy ini?

Ya. Setiap pelajaran Security+ Academy menyertakan penyunting kod terbina dalam, jadi anda boleh menulis dan menjalankan kod sebenar terus dalam pelayar serta menerima maklum balas kecerdasan buatan serta-merta — tanpa memerlukan persediaan setempat.

Semua pelajaran dalam kursus ini

Pengesahan E-mel: SPF, DKIM dan DMARC
Gerbang E-mel Selamat dan Kawalan Antispam
Penapisan Kandungan Web dan Lubang Sink DNS
Pemeriksaan SSL/TLS dan Serangan Manusia dalam Penyemak Imbas

← Kembali ke Security+ Academy