การยืนยันตัวตนอีเมล: SPF, DKIM และ DMARC
นำ Sender Policy Framework, DomainKeys Identified Mail และนโยบาย DMARC มาใช้และตรวจสอบความถูกต้อง เพื่อป้องกันการปลอมแปลงโดเมนและฟิชชิง
การยืนยันตัวตนอีเมล: SPF, DKIM และ DMARC เป็นบทเรียน Security+ Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Security+ Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน
ปัญหาการปลอมแปลงอีเมล
โพรโทคอล SMTP พื้นฐาน (ออกแบบขึ้นในทศวรรษ 1970) ไม่มีการยืนยันตัวตนผู้ส่งในตัว เซิร์ฟเวอร์อีเมลใด ๆ ก็สามารถอ้างว่าส่งอีเมลจากโดเมนใดก็ได้ เทคนิคนี้เรียกว่า การปลอมแปลงอีเมล ผู้โจมตีใช้วิธีนี้ส่งอีเมลฟิชชิงที่ดูเหมือนมาจากองค์กรที่ถูกต้อง เช่น ธนาคารของคุณ CEO ของคุณ หรือผู้จำหน่ายที่รู้จัก มีการพัฒนามาตรฐานการยืนยันตัวตนอีเมลที่อาศัย DNS สามมาตรฐานเพื่อแก้ปัญหานี้ ได้แก่ SPF DKIM และ DMARC แต่ละมาตรฐานจัดการปัญหาการปลอมแปลงคนละด้าน และทำงานได้ดีที่สุดเมื่อใช้งานร่วมกัน
Sender Policy Framework (SPF)
SPF คือระเบียน DNS TXT ที่ระบุว่าเซิร์ฟเวอร์อีเมลใดบ้างได้รับอนุญาตให้ส่งอีเมลในนามของโดเมน เมื่อเซิร์ฟเวอร์อีเมลปลายทางได้รับข้อความที่อ้างว่าส่งมาจาก example.com เซิร์ฟเวอร์จะค้นหาระเบียน SPF ของ example.com และตรวจสอบว่าที่อยู่ IP ของเซิร์ฟเวอร์ผู้ส่งอยู่ในรายการหรือไม่ หาก IP ไม่ได้รับอนุญาต ข้อความนั้นอาจถูกทำเครื่องหมายเป็นสแปมหรือถูกปฏิเสธ SPF ตรวจสอบ ที่อยู่ From ในซองจดหมาย (คำสั่ง SMTP MAIL FROM) ไม่ใช่ส่วนหัว From ที่แสดงให้ผู้ใช้เห็น
# 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)ข้อจำกัดของ SPF
SPF มีข้อจำกัดสำคัญสองประการ ประการแรก การส่งต่อทำให้ SPF ใช้งานไม่ได้ เมื่อมีการส่งต่ออีเมล IP ของเซิร์ฟเวอร์ที่ส่งต่อจะไม่อยู่ในระเบียน SPF ของโดเมนต้นทาง ทำให้ SPF ไม่ผ่านแม้จะเป็นอีเมลที่ส่งต่อโดยชอบ ประการที่สอง SPF ยืนยันเฉพาะ From ในซองจดหมาย (ผู้ใช้มองไม่เห็น) ไม่ใช่ ส่วนหัว From ที่แสดงในโปรแกรมอีเมล ผู้โจมตียังคงปลอมส่วนหัว From ที่มองเห็นได้ โดยใช้ From ในซองจดหมายที่ผ่าน SPF นี่จึงเป็นเหตุผลว่าทำไม SPF เพียงอย่างเดียวจึงไม่เพียงพอ DKIM และ DMARC ช่วยแก้ช่องว่างเหล่านี้
DomainKeys Identified Mail (DKIM)
DKIM เพิ่มลายเซ็นเข้ารหัสให้กับอีเมลขาออก เซิร์ฟเวอร์อีเมลผู้ส่งใช้ กุญแจส่วนตัว เพื่อลงลายเซ็นให้ส่วนหัวอีเมลและเนื้อความที่ระบุ จากนั้นเพิ่มส่วนหัว DKIM-Signature ส่วน กุญแจสาธารณะ จะเผยแพร่เป็นระเบียน DNS TXT ภายใต้โดเมนย่อยตัวเลือก เซิร์ฟเวอร์ปลายทางจะดึงกุญแจสาธารณะมาตรวจสอบลายเซ็น เพื่อยืนยันว่าอีเมลไม่ถูกแก้ไขระหว่างทางและมาจากเซิร์ฟเวอร์ที่เข้าถึงกุญแจส่วนตัวได้ ต่างจาก SPF ลายเซ็น DKIM ยังคงอยู่แม้มีการส่งต่อ เพราะลายเซ็นถูกส่งไปพร้อมกับส่วนหัวอีเมล
# 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ตัวเลือก DKIM และการหมุนเวียนกุญแจ
DKIM ใช้ ตัวเลือก เพื่อรองรับกุญแจสาธารณะหลายชุดของโดเมนเดียวกันในเวลาเดียวกัน ซึ่งมีประโยชน์เมื่อใช้งานบริการอีเมลหลายราย (Google Workspace และแพลตฟอร์มการตลาด) หรือเมื่อต้องหมุนเวียนกุญแจโดยไม่ให้บริการหยุดชะงัก ชื่อตัวเลือกจะอยู่ในส่วนหัว DKIM-Signature เพื่อให้เซิร์ฟเวอร์ปลายทางทราบว่าต้องค้นหาระเบียน DNS ใด องค์กรควรหมุนเวียนกุญแจ DKIM ทุกปี หรือเมื่อสงสัยว่ากุญแจถูกเจาะระบบ ความยาวกุญแจ: แนะนำให้ใช้กุญแจ RSA อย่างน้อย 2048 บิต ส่วนกุญแจ 1024 บิตถือว่าเลิกใช้แล้วและสามารถถอดรหัสได้ด้วยกำลังประมวลผลสมัยใหม่
DMARC: การยืนยันตัวตนข้อความตามโดเมน
DMARC (การยืนยันตัวตน การรายงาน และการปฏิบัติตามข้อกำหนดของข้อความตามโดเมน) ต่อยอดจาก SPF และ DKIM ด้วยการเพิ่ม การตรวจสอบความสอดคล้อง (โดเมนในส่วนหัว From ที่มองเห็นได้ต้องสอดคล้องกับโดเมนที่ผ่านการยืนยันด้วย SPF หรือ DKIM) และ นโยบาย ที่แจ้งเซิร์ฟเวอร์ปลายทางว่าควรทำอย่างไรเมื่อข้อความไม่ผ่านการตรวจสอบ นโยบาย DMARC ได้แก่ none (ตรวจสอบเท่านั้น) quarantine (ส่งไปยังโฟลเดอร์สแปม) หรือ reject (ไม่ส่งมอบ) DMARC ยังเปิดให้ใช้ รายงานสรุป (RUA) และ รายงานเชิงนิติวิทยาศาสตร์ (RUF) ซึ่งส่งกลับไปยังเจ้าของโดเมน เพื่อให้เห็นว่าใครกำลังส่งอีเมลในนามของคุณ
# 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 destinationDMARC Alignment
Alignment คือสิ่งที่ทำให้ DMARC มีประสิทธิภาพในการป้องกันการปลอมแปลงส่วนหัว สำหรับการทำ Alignment ของ SPF โดเมนใน SMTP envelope From ต้องตรงกับโดเมนในส่วนหัว From ที่ผู้รับมองเห็น สำหรับการทำ Alignment ของ DKIM โดเมนที่ใช้ลงลายเซ็น (d= ใน DKIM-Signature) ต้องตรงกับโดเมนในส่วนหัว From ในโหมดเข้มงวด โดเมนต้องตรงกันทุกประการ ส่วนในโหมดผ่อนปรน สามารถใช้โดเมนย่อยได้ อีเมลจะผ่าน DMARC หากผ่าน SPF หรือ DKIM อย่างใดอย่างหนึ่งพร้อมการทำ Alignment ที่ถูกต้อง ไม่จำเป็นต้องผ่านทั้งสองอย่าง การทำงานร่วมกันนี้ช่วยปิดช่องโหว่ที่ SPF เพียงอย่างเดียวไม่สามารถป้องกันการปลอมแปลงส่วนหัวที่ผู้รับมองเห็นได้
# 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การติดตั้งใช้งาน DMARC เป็น Stage
Organization ควรติดตั้งใช้งาน DMARC แบบค่อยเป็นค่อยไป เพื่อไม่ให้ Email ที่ถูกต้องได้รับผลกระทบ Stage 1: ติดตั้ง SPF และ DKIM สำหรับแหล่งส่ง Email ทั้งหมด Stage 2: เผยแพร่ระเบียน DMARC p=none พร้อมการ Reporting ด้วย RUA วิเคราะห์รายงาน (เครื่องมือ: DMARC Analyzer, dmarcian) เพื่อค้นหาแหล่งส่ง Email ที่ถูกต้องทั้งหมดเป็นเวลา 2-4 สัปดาห์ Stage 3: เปลี่ยนเป็น p=quarantine; pct=10 แล้วค่อย ๆ เพิ่มค่า pct จนถึง 100% Stage 4: เปลี่ยนเป็น p=reject เมื่อแหล่งส่ง Email ที่ถูกต้องทั้งหมดผ่านแล้ว การรีบใช้ reject ก่อนค้นพบแหล่งส่ง Email ทั้งหมดจะทำให้ Email ที่ถูกต้องถูกปฏิเสธ
# 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 toolsBIMI: ตัวบ่งชี้แบรนด์สำหรับการระบุ Message
BIMI เป็นมาตรฐานที่กำลังได้รับการพัฒนา โดยต่อยอดจาก DMARC เมื่อโดเมนมีนโยบาย DMARC เป็น quarantine หรือ reject โปรแกรมรับ Email (Gmail, Apple Mail) สามารถแสดงโลโก้แบรนด์ที่ผ่านการยืนยันแล้วถัดจากชื่อผู้ส่งในกล่องขาเข้าได้ BIMI ต้องใช้ใบรับรองเครื่องหมายที่ผ่านการยืนยัน (VMC) จากผู้ออกใบรับรองที่ได้รับอนุมัติ เพื่อยืนยันความเป็นเจ้าของเครื่องหมายการค้า แม้ BIMI จะยังไม่อยู่ในการสอบ Security+ แต่ก็แสดงให้เห็นทิศทางของการยืนยันตัวตน Email นั่นคือการทำให้ผู้ส่งที่ผ่านการยืนยันแตกต่างจากผู้ส่งที่ถูกปลอมแปลงได้อย่างชัดเจนด้วยภาพในทันที
SPF+DKIM+DMARC ทำงานร่วมกัน
มาตรฐานทั้งสามนี้ประกอบกันเป็นระบบยืนยันตัวตน Email ที่ครบถ้วน SPF ตรวจสอบว่า Server ที่ส่งได้รับอนุญาตจากเจ้าของโดเมน DKIM ตรวจสอบความถูกต้องของเนื้อหา Message และยืนยันว่า Organization ผู้ส่งถือครองคีย์ส่วนตัว DMARC เชื่อมโยงทั้งสองอย่างเข้ากับส่วนหัว From ที่ผู้รับมองเห็น บังคับใช้นโยบายเมื่อไม่ผ่าน และจัดทำ Reporting ไม่มีมาตรฐานใดมาตรฐานหนึ่งที่เพียงพอ: SPF เพียงอย่างเดียวไม่สามารถป้องกันการปลอมแปลงส่วนหัวที่ผู้รับมองเห็นได้ DKIM เพียงอย่างเดียวไม่ได้กำหนดให้ปฏิเสธสิ่งที่ไม่ผ่าน และ DMARC เพียงอย่างเดียวที่ไม่มี SPF หรือ DKIM ก็ไม่มีสิ่งให้นำมาตรวจสอบ ต้องติดตั้งใช้งานทั้งสามอย่างร่วมกันเพื่อป้องกันการปลอมแปลงโดเมนได้อย่างสมบูรณ์
# 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แบนเนอร์ Email ภายนอก
มาตรการป้องกันแบบหลายชั้นที่ใช้ได้จริงสำหรับการป้องกันฟิชชิงและ BEC คือการเพิ่มแบนเนอร์แจ้งเตือน Email ภายนอกให้กับทุก Message ที่มาจากภายนอก Organization แบนเนอร์นี้ ซึ่งโดยทั่วไปจะถูกแทรกโดย SEG จะแจ้งเตือนพนักงานว่า Email มาจากผู้ส่งภายนอก แม้ชื่อที่แสดงจะดูเหมือนเพื่อนร่วมงานหรือผู้บริหารก็ตาม แบนเนอร์มีประสิทธิภาพเป็นพิเศษในการระบุความพยายามแบบ BEC ซึ่งผู้โจมตีใช้โดเมนเลียนแบบหรือปลอมแปลงชื่อที่แสดง แบนเนอร์ควรมีลักษณะเด่นทางภาพ (ส่วนหัวหรือส่วนท้ายที่มีสี) และควรมีคำแนะนำเกี่ยวกับการรายงาน Message ที่น่าสงสัย
# 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ตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า SPF ใช้ระเบียน DNS TXT เพื่ออนุญาต IP ที่ใช้ส่ง Email แต่ตรวจสอบเฉพาะ envelope From ไม่ใช่ส่วนหัวที่ผู้รับมองเห็น DKIM เพิ่มลายเซ็นเข้ารหัสเพื่อยืนยันความถูกต้องของเนื้อหา Message และยังคงตรวจสอบได้แม้มีการส่งต่อ และ DMARC เชื่อม SPF กับ DKIM เข้ากับส่วนหัว From ที่ผู้รับมองเห็น พร้อมตรวจสอบ Alignment และใช้นโยบายที่บังคับใช้ได้ (none/quarantine/reject) รวมถึงการ Reporting บทถัดไปเราจะศึกษาเกตเวย์ Email ที่ปลอดภัยและการควบคุมสแปม
เรียนรู้ Security+ Academy ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 30
- บทเรียน
- 120
คำถามที่พบบ่อย
บทเรียน “การยืนยันตัวตนอีเมล: SPF, DKIM และ DMARC” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การยืนยันตัวตนอีเมล: SPF, DKIM และ DMARC” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Security+ Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การยืนยันตัวตนอีเมล: SPF, DKIM และ DMARC”
นำ Sender Policy Framework, DomainKeys Identified Mail และนโยบาย DMARC มาใช้และตรวจสอบความถูกต้อง เพื่อป้องกันการปลอมแปลงโดเมนและฟิชชิง คุณปฏิบัติ Security+ Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Security+ Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Security+ Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน
บทเรียน “การยืนยันตัวตนอีเมล: SPF, DKIM และ DMARC” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Security+ Academy นี้ได้ไหม
ได้ บทเรียน Security+ Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การยืนยันตัวตนอีเมล: SPF, DKIM และ DMARC
- เกตเวย์อีเมลที่ปลอดภัยและการควบคุมสแปม
- การกรองเนื้อหาเว็บและ DNS Sinkhole
- การตรวจสอบ SSL/TLS และการโจมตีแบบคนกลางในเบราว์เซอร์