เครือข่าย/HTTP

Email Header Analyzer

แยกวิเคราะห์ส่วนหัวดิบของอีเมล (View Source / Show Original) — ฟิลด์พื้นฐาน ลำดับ Received พร้อมเวลา SPF/DKIM/DMARC สัญญาณการปลอมแปลง From/Reply-To

A message's full headers (View Source or Show Original in a mail client) record its entire path through mail servers, along with sender-authenticity check results. This tool breaks those headers down into readable fields and flags signs of spoofing.

How to use it

Common uses

Things to keep in mind

The Date header is set by the sender's client and can be inaccurate; for an exact timeline, trust the timestamps in the Received chain, which are added by the mail servers themselves.

Passing SPF/DKIM/DMARC only confirms the message is technically authorized by the sending domain — it doesn't guarantee the content itself isn't phishing or spam.

บทความเกี่ยวกับเครื่องมือนี้: Email Headers: SPF, DKIM และ DMARC ตรวจสอบผู้ส่งจริงอย่างไร

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

เฮดเดอร์อีเมลบอกอะไรฉันได้จริง ๆ ที่เนื้อหาข้อความบอกไม่ได้?

เฮดเดอร์เผยเส้นทางที่อีเมลผ่านเซิร์ฟเวอร์เมล (บรรทัด Received) ผลการยืนยันตัวตน (SPF, DKIM, DMARC) และเซิร์ฟเวอร์ต้นทางที่แท้จริง — มีประโยชน์ในการตรวจจับอีเมลปลอมหรือฟิชชิง

จะรู้ได้อย่างไรว่า SPF, DKIM หรือ DMARC ผ่านจริง?

มองหา pass, fail หรือ none ในเฮดเดอร์ Authentication-Results — "pass" ทั้งสามตัวเป็นสัญญาณที่ชัดเจน (แม้จะไม่แน่นอนทั้งหมด) ว่าข้อความไม่ถูกปลอมแปลง ในขณะที่การล้มเหลวในการตรวจสอบที่สำคัญต่อผู้ส่งเป็นสัญญาณเตือน

การวางเฮดเดอร์อีเมลที่นี่อัปโหลดมันไปที่ไหนหรือไม่?

ไม่ เฮดเดอร์ถูกแยกวิเคราะห์ทั้งหมดในเบราว์เซอร์ของคุณ ไม่มีการส่งไปยังเซิร์ฟเวอร์ จึงปลอดภัยที่จะวิเคราะห์เฮดเดอร์จริง

เฮดเดอร์ Message-ID มีไว้เพื่ออะไร?

เป็นตัวระบุเฉพาะที่กำหนดให้อีเมลแต่ละฉบับ ใช้โดยโปรแกรมอีเมลเพื่อจัดกลุ่มข้อความเป็นเธรดผ่านเฮดเดอร์ In-Reply-To ซึ่งเชื่อมโยงการตอบกลับกับ Message-ID ของข้อความต้นฉบับ

ทำไมเฮดเดอร์ Date อาจไม่ตรงกับเวลาประทับตราของเฮดเดอร์ Received?

Date ถูกตั้งค่าโดยโปรแกรมอีเมลของผู้ส่งและอาจผิดพลาดได้หากนาฬิกาของเขาไม่ตรงกัน ในขณะที่เวลาประทับตราของ Received ถูกเพิ่มโดยเซิร์ฟเวอร์ในช่วงเวลาที่ส่งจริง จึงน่าเชื่อถือกว่า

บทความ: เครือข่าย/HTTP

การแยกส่วน URL: ที่อยู่เว็บประกอบด้วยส่วนใดบ้าง

ส่วนแฟรกเมนต์ของ URL (หลัง #) ไม่เคยถูกส่งไปยังเซิร์ฟเวอร์เลย มีแต่เบราว์เซอร์เท่านั้นที่ประมวลผล

คิวรีสตริงกับ JSON: อะไรเหมาะกว่าสำหรับส่งข้อมูลที่ซับซ้อน

เหตุใดจึงไม่มีวิธีมาตรฐานสำหรับการส่งอาร์เรย์ผ่านคิวรีสตริง

User-Agent: เหตุใด Chrome ถึงมีคำว่า "Mozilla" และ "Safari"

เหตุใด User-Agent ของ Chrome จึงอ้างตัวว่าเป็น "Mozilla" และ "Safari" ทั้งที่ไม่ใช่

HTTP Basic Auth: เฮดเดอร์ Authorization ถูกสร้างขึ้นอย่างไร

Base64 ไม่ใช่การเข้ารหัส — รหัสผ่านของ Basic Auth สามารถถูกถอดรหัสได้ในไม่กี่วินาที

HTTP Headers: เมทาดาต้าที่มาพร้อมกับทุกคำขอและการตอบกลับ

เฮดเดอร์ Content-Type บอกเบราว์เซอร์อย่างไรว่าจะจัดการการตอบกลับเป็น HTML, JSON หรือรูปภาพ

คุกกี้: เหตุใดแอตทริบิวต์ Secure, HttpOnly และ SameSite จึงสำคัญ

เหตุใดแอตทริบิวต์ HttpOnly จึงช่วยป้องกันไม่ให้คุกกี้เซสชันถูกขโมยในการโจมตี XSS

ข้อผิดพลาด CORS: เหตุใดเบราว์เซอร์จึงบล็อกการตอบกลับ

เหตุใดคำขอที่ใช้งานได้ใน Postman จึงเกิดข้อผิดพลาด CORS ในเบราว์เซอร์