วิธีอ่าน Email Header: ไล่ย้อน Received Chain และตรวจสอบ SPF, DKIM และ DMARC

เมื่ออีเมลที่น่าสงสัย หลอกลวง หรือมาช้ากว่าปกติ หล่นเข้ามาในกล่องจดหมาย เนื้อหาของอีเมลแทบไม่บอกอะไรเลยว่ามันมาจากไหนจริงๆ หลักฐานทั้งหมดอยู่ใน raw header — ข้อความเทคนิคหนาแน่นที่ email client ส่วนใหญ่ซ่อนไว้ Email Header Parser เปลี่ยนข้อความกองนั้นให้เป็นตาราง field ที่อ่านง่าย ถอดรหัส MIME encoded-words และเรียง Received hop chain จาก hop ล่าสุดขึ้นบนสุด เพื่อให้คุณไล่เส้นทางอีเมลได้ในแวบเดียว ทุกอย่างทำงานในเบราว์เซอร์ของคุณ — ไม่มีอะไรที่คุณวางถูกอัปโหลดไปไหน

วิธีเปิด raw header: ใน Gmail ให้เปิดอีเมล คลิกเมนูสามจุด แล้วเลือก "Show original" ใน Outlook ใช้ "View message source" บนเว็บ หรือดู "Internet headers" ในหน้า properties ของเดสก์ท็อป ส่วน Apple Mail กด Shift-Command-H ได้เลย บทความนี้จะพาไปดูวิธีอ่านสิ่งที่คุณเจอ — โดยเฉพาะ Received chain และผลลัพธ์ SPF, DKIM และ DMARC

ทำไมต้องใช้ Email Header Parser?

• มองทะลุผู้ส่งปลอม — แก้ที่อยู่ From ได้ง่ายมาก แต่ Received chain และ Authentication-Results จะบันทึกโครงสร้างพื้นฐานจริงที่อีเมลเดินทางผ่าน รวมถึง IP ของเซิร์ฟเวอร์ผู้ส่ง
• ไล่เส้นทางอีเมลทีละ hop — เครื่องมือเรียงบรรทัด Received จาก hop ใหม่สุดขึ้นบนสุด ทำให้ไล่เส้นทางได้โดยไม่ต้องเรียงกลับในหัว
• ถอดรหัส subject ที่อ่านไม่ออก — subject ภาษาอื่นมักถูกห่อด้วย RFC 2047 encoded-words อย่าง =?UTF-8?B?...?= เครื่องมือถอด MIME encoded-words เหล่านี้เป็นข้อความจริง
• เช็คการยืนยันตัวตนได้ในแวบเดียว — ผล SPF, DKIM และ DMARC ถูกดึงออกจาก Authentication-Results เห็นรายการที่ fail ได้ในไม่กี่วินาที
• เป็นส่วนตัวและรวดเร็ว — parsing เป็น 100% client-side และคุณจะได้ตาราง field สำคัญครบ: From, To, Subject, Date, Message-ID, Return-Path, Reply-To และ Delivered-To

ฟีเจอร์เด่น

• วางได้เฉพาะส่วน header โดยไม่ต้องเอา body มาด้วย ทำให้ตัวอย่างที่แชร์เล็กลงและปลอดภัยขึ้น
• timestamp ของทุก hop ถูกเก็บไว้ครบ วัดความหน่วงระหว่างเซิร์ฟเวอร์ได้

วิธีใช้ Email Header Parser

1. คัดลอก raw header ใช้ "Show original" ของ Gmail หรือ "View message source" ของ Outlook แล้ว copy ตั้งแต่บรรทัด Received: แรก
2. วางในเครื่องมือ เปิด Email Header Parser แล้ววางข้อความลงในช่อง input
3. อ่านตาราง field สังเกต Reply-To ที่ไม่ตรงกับ From หรือโดเมน Return-Path ที่ไม่ตรงกับผู้ส่งที่แสดง
4. ไล่ Received chain ตาม hop จากบนลงล่าง (ใหม่สุดไปเก่าสุด) ดูว่าชื่อเซิร์ฟเวอร์และ timestamp เชื่อมต่อกันอย่างสมเหตุสมผลหรือไม่
5. ตรวจผลการยืนยัน ดู SPF, DKIM และ DMARC ก่อนสรุปอะไร — อีเมลฟิชิงที่แต่ง From มาสวยงามมัก fail อย่างน้อยหนึ่งรายการ

การอ่าน Received Chain

header ชื่อ Received คือหัวใจของการสืบสวนอีเมล ทุกเซิร์ฟเวอร์ที่รับอีเมลจะเติมบรรทัด Received ของตัวเอง ไว้ด้านบน ของก้อน header เสมอ รายการจึงเรียงจากใหม่ไปเก่า: บรรทัดบนสุดคือเซิร์ฟเวอร์สุดท้ายที่แตะอีเมล และบรรทัดล่างสุดใกล้จุดเริ่มต้นที่สุด — ให้อ่าน chain จากล่างขึ้นบน

Received: from mail-sor1.example-corp.com ([203.0.113.41])
        by mx.inbox-guard.net with ESMTPS; Fri, 12 Sep 2026 01:02:55 -0700
Received: from lists.newsletters.example.net ([198.51.100.7])
        by mail-sor1.example-corp.com with ESMTP; Fri, 12 Sep 2026 01:02:51 -0700
Authentication-Results: mx.inbox-guard.net;
        spf=pass smtp.mailfrom=example-corp.com;
        dkim=pass header.d=newsletters.example.net;
        dmarc=fail (p=reject) header.from=secure-bank.example

อ่านจากล่างขึ้นบน: client ผู้ให้บริการอินเทอร์เน็ตส่งอีเมลไปที่ lists.newsletters.example.net ซึ่ง relay ต่อผ่าน mail-sor1.example-corp.com ก่อนถึง provider ของคุณ

ใช้ timestamp วัดความหน่วง — ทุก hop มีวันที่ เวลา และ timezone ของตัวเอง ลบ timestamp ที่ติดกันจะเห็นว่าอีเมลรออยู่ที่ไหน: ไม่กี่นาทีคือการจับคิวปกติ ส่วนช่องว่างสิบสี่ชั่วโมงชี้ไปที่ greylisting หรือผู้ส่งที่ออฟไลน์

แยก hop จริงออกจาก hop ปลอม — สแปมเมอร์ใส่บรรทัด Received ปลอมเพิ่มได้ chain ที่แท้จะสอดคล้องกัน: เซิร์ฟเวอร์ผู้รับของ hop หนึ่งต้องเป็นผู้ส่งในบรรทัดถัดขึ้นไป timestamp ต้องเพิ่มขึ้นเมื่อขยับขึ้น และชื่อต้อง resolve ได้จริง บรรทัดปลอมมักขาดความต่อเนื่องนี้ หลักฐานที่เชื่อถือได้ที่สุดคือ hop ล่าสุดที่ mail provider ของคุณเป็นคนเขียน — ทุกอย่างข้างบนมาจากโครงสร้างพื้นฐานที่คุณควบคุมไม่ได้

เข้าใจผลลัพธ์ SPF, DKIM และ DMARC

header Authentication-Results บันทึกสิ่งที่เซิร์ฟเวอร์ปลายทางสรุปไว้:

• SPF ตรวจว่า IP ที่เชื่อมต่อเข้ามาได้รับอนุญาตให้ส่งในนามโดเมนซองจดหมายหรือไม่: pass คือได้รับอนุญาต, fail คือ IP ไม่อยู่ในรายการ, softfail คือโดเมนระบุว่า host ที่ไม่รู้จักน่าสงสัยเพียงบางส่วน
• DKIM ตรวจลายเซ็นเข้ารหัสของอีเมล pass พิสูจน์ว่าเนื้อหาไม่ถูกแก้ระหว่างทางและโดเมนผู้ลงนามรับผิดชอบข้อความนี้ ส่วนการไม่มีลายเซ็นอาจเกิดจากระบบ forwarding ที่แก้ไขข้อความก็ได้
• DMARC บังคับให้เกิด alignment: SPF หรือ DKIM ต้อง pass และ ใช้โดเมนที่ตรงกับ From ที่แสดง ค่า policy p=none, p=quarantine และ p=reject บอกว่าโดเมนให้ receiver ทำอย่างไรกับเคส fail — dmarc=fail บนโดเมน p=reject จึงเป็นสัญญาณฟิชิงที่แรงมาก ถ้ารวมกับ spf=fail และ dkim=none แทบจะสรุปคดีได้เลย

กรณีการใช้งานจริง

คัดกรองฟิชิง

เมื่อมีคนรายงานอีเมลน่าสงสัย ให้เช็ค Authentication-Results หา dmarc=fail เทียบ Return-Path กับชื่อผู้ส่งที่แสดง และไล่ chain ดูว่าอีเมลเข้าโครงสร้างของคุณจากประเทศหรือ host ที่ไม่ควรจะเป็น — parsing เปลี่ยนความรู้สึกให้กลายเป็นหลักฐานที่แนบกับ incident report ได้

แก้ปัญหาอีเมลตกไปสแปม

ถ้า campaign ของคุณหล่นไปสแปม header ของอีเมลที่ส่งถึงจริงจะบอกเหตุผล spf=softfail, ลายเซ็น DKIM ที่พังเพราะการ forward หรือ policy dmarc=none ต่างชี้ไปยังจุดที่ต้องแก้ใน DNS record ของคุณ

วินิจฉัยอีเมลมาช้า

password reset หรือ invoice บางทีมาช้าไปหลายชั่วโมง การไล่ timestamp ของแต่ละ hop จะชี้ว่าอีเมลรออยู่ตรงไหน และความล่าช้ามาจาก provider ของคุณ, greylisting ฝั่งผู้รับ หรือ relay ที่ช้า

ไล่ต้นทางสแปม

สำหรับสแปมที่วนกลับมาเรื่อยๆ ส่วนล่างของ Received chain จะระบุเครือข่ายที่ inject อีเมลเข้ามาจริง รายงาน IP นั้นไปยัง abuse desk แทนการบล็อกโดเมนปลอมที่แสดงไว้

Best Practices ในการวิเคราะห์ Header

• ลบข้อมูลอ่อนไหวก่อนแชร์ — ตัดที่อยู่ผู้รับและชื่อเซิร์ฟเวอร์ภายในออกจากตัวอย่างที่ส่งเข้า ticket หรือบอร์ด เพราะ header อาจรั่วข้อมูลโครงสร้างภายใน
• ดูผลการยืนยันทั้งสามตัวพร้อมกัน — SPF โดน forward หลอกได้ DKIM อาจหายบนอีเมลแท้ และมีแค่ DMARC alignment เท่านั้นที่ยืนยันโดเมน From ที่แสดง
• เทียบเวลาใน Received chain — timestamp ต้องเพิ่มขึ้นเมื่อไล่ขึ้นบน หาก hop ไหนสลับลำดับเวลาควรสงสัยไว้ก่อน
• เชื่อบรรทัดจาก provider ของคุณมากที่สุด — record ที่ mail provider เขียนเองปลอมยาก ส่วนข้ออ้างที่เขียนอยู่ข้างบนให้ถือว่ายังไม่พิสูจน์
• จับคู่การวิเคราะห์ header กับการตรวจเนื้อหา — header พิสูจน์ที่มา ไม่ได้พิสูจน์เจตนา อย่าลืมตรวจ link และไฟล์แนบก่อนกดอะไร

เริ่ม Parse Email Header ได้เลย

ครั้งหน้าที่อีเมลดูแปลกๆ อย่าเชื่อแค่ชื่อผู้ส่งที่แสดง copy raw header มาวางใน Email Header Parser ฟรี แล้วคุณจะได้ตาราง field ที่อ่านง่าย, Received chain เรียงจากใหม่สุด และผล SPF, DKIM และ DMARC ชัดเจน — อยู่ในเบราว์เซอร์ของคุณเองอย่างเป็นส่วนตัว

เครื่องมือที่เกี่ยวข้อง:

• Email Extractor — สกัด email address ทุกตัวจากข้อความใดๆ
• URL Parser — แยก URL และ query string ออกเป็นส่วนๆ อ่านง่าย
• Base64 Tool — encode และ decode ข้อความ Base64

ขอให้สนุกกับการไล่ header!

คำถามที่พบบ่อย

ถ: header ของอีเมลฉันถูกอัปโหลดไปไหนหรือเปล่า?

ตอบ: ไม่ parsing ทำงานทั้งหมดในเบราว์เซอร์ด้วย client-side JavaScript ข้อความที่คุณวางไม่เคยผ่านเซิร์ฟเวอร์ใดๆ

ถ: ทำไม Received hop ล่าสุดถึงอยู่บนสุด?

ตอบ: เพราะทุกเซิร์ฟเวอร์เติมบรรทัด Received ไว้เหนือบรรทัดเดิมเสมอ ก้อน header จึงเรียงจากใหม่ไปเก่า และต้องอ่านจากล่างขึ้นบนเพื่อไล่จุดเริ่มต้นจริง

ถ: สแปมเมอร์ปลอม Received header ได้หรือไม่?

ตอบ: ได้ chain ที่แท้จะสอดคล้องกัน — เซิร์ฟเวอร์แต่ละตัวเป็นผู้ส่งของ hop ถัดไปและ timestamp เพิ่มขึ้นเมื่อไล่ขึ้น — ส่วนบรรทัดปลอมมักขาดความต่อเนื่องนี้

ถ: SPF softfail กับ fail ต่างกันอย่างไร?

ตอบ: fail หมายถึง IP ผู้ส่งไม่ได้รับอนุญาตในนามโดเมนอย่างชัดเจน ส่วน softfail คือโดเมนระบุว่า host ที่ไม่รู้จักน่าสงสัยเพียงบางส่วน — ถือเป็นคำเตือน ไม่ใช่หลักฐานการโกง