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

echo.email วิเคราะห์อีเมลหนึ่งฉบับต่อหนึ่งที่อยู่และอธิบายผลลัพธ์ คำตอบด้านล่างอธิบายวิธีการทำงานของบริการ และความหมายของการตรวจแต่ละรายการในรายงาน

echo.email ทำงานอย่างไร

หน้าแรกจะให้ที่อยู่ใหม่ที่ประกอบด้วยคำสามคำ เช่น power.file.tube@echo.email ข้อความที่ส่งไปยังที่อยู่นี้จะไปถึงเซิร์ฟเวอร์อีเมลของ echo.email ซึ่งบันทึกการสนทนา SMTP และส่งข้อความต่อไปวิเคราะห์ ไม่กี่วินาทีต่อมา หน้าเว็บจะเปลี่ยนเป็นรายงานที่ครอบคลุมการยืนยันตัวตน เนื้อหา การปฏิบัติตามข้อกำหนด และการส่ง ไม่ต้องติดตั้งอะไรและไม่มีระบบบัญชีผู้ใช้

ที่อยู่ใช้งานได้นานเท่าไร

ที่อยู่จะใช้งานได้ตราบที่หน้าเว็บยังเปิดอยู่ หน้าเว็บจะติดต่อเซิร์ฟเวอร์ทุกสองวินาที และหากโหลดหน้าใหม่ภายใน 10 นาที แท็บเดิมจะยังได้ที่อยู่เดิม เมื่อปิดหน้าเว็บไปนานกว่า 10 นาที เซิร์ฟเวอร์อีเมลจะปฏิเสธอีเมลใหม่ที่ส่งถึงที่อยู่นี้ด้วยข้อผิดพลาดถาวร

ข้อความแรกที่มาถึงเท่านั้นที่ถูกนำมาวิเคราะห์ ข้อความที่ส่งตามมายังที่อยู่เดียวกันจะถูกปฏิเสธ รายงานแต่ละฉบับจึงเป็นของอีเมลเพียงฉบับเดียว ข้อความที่ใหญ่กว่า 10 MB จะถูกปฏิเสธระหว่างการสนทนา SMTP

รายงานถูกเก็บไว้นานเท่าไร

รายงาน ข้อความที่จัดเก็บ และข้อมูลรูปภาพที่ดาวน์โหลดมาจะถูกลบโดยอัตโนมัติเมื่อครบ 24 ชั่วโมงหลังจากข้อความมาถึง ภายใน 24 ชั่วโมงนั้น ทุกคนที่มีลิงก์รายงานจะเปิดดูได้ หลังจากนั้นลิงก์จะใช้ไม่ได้ ยกเว้นรายงานตัวอย่างเพียงฉบับเดียว เพราะรายงานตัวอย่างมาจากข้อความทดสอบที่ส่งมาเพื่อจุดประสงค์นี้โดยเฉพาะ

เกิดอะไรขึ้นกับเนื้อหาของข้อความ

echo.email จัดเก็บข้อความทั้งฉบับ ได้แก่ ส่วนหัว เนื้อความ และไฟล์แนบ พร้อมรายละเอียดของเซสชัน SMTP เช่น ที่อยู่ IP ที่ส่ง ชื่อ HELO และเวอร์ชัน TLS ข้อมูลจัดเก็บใน EU และเซิร์ฟเวอร์อีเมลตั้งอยู่ที่เมือง Falkenstein ประเทศเยอรมนี ทุกคนที่มีลิงก์รายงานจะเห็นข้อความทั้งฉบับ ข้อความทดสอบจึงควรมีเนื้อหาที่แชร์ได้อย่างปลอดภัย จดหมายข่าวมักมีลิงก์ติดตามและลิงก์ยกเลิกรับข่าวสารที่ผูกกับผู้รับคนเดียว การส่งสำเนาไปยังรายชื่อทดสอบจะช่วยเก็บลิงก์เหล่านั้นไว้เป็นความลับ

ติดต่อผู้ดูแลได้โดยตรงสองที่อยู่: contact@echo.email สำหรับคำถามและการแจ้งปัญหา และ privacy@echo.email สำหรับคำขอเกี่ยวกับข้อมูล นโยบายความเป็นส่วนตัวมีรายละเอียดทั้งหมด

การตรวจ SPF ทดสอบอะไร

SPF ระบุรายชื่อเซิร์ฟเวอร์ที่ได้รับอนุญาตให้ส่งอีเมลโดยใช้โดเมนนั้นใน return path echo.email นำโดเมนจากผู้ส่ง envelope (ที่อยู่ MAIL FROM หรือที่เรียกว่า return path) แล้วประเมินเรคคอร์ด SPF ของโดเมนนั้นเทียบกับที่อยู่ IP ของเซิร์ฟเวอร์ที่ส่งข้อความ ผลลัพธ์ที่ดีมีเพียง pass เท่านั้น ส่วน softfail, neutral และ none ล้วนทำให้ผู้รับไม่มีหลักฐาน SPF ยืนยันผู้ส่ง

echo.email ประเมิน SPF สำหรับผู้ส่ง envelope โดยไม่ตรวจชื่อ HELO ซึ่งเป็นวิธีเดียวกับที่ผู้ให้บริการกล่องจดหมายรายใหญ่ใช้ประเมิน SPF ของอีเมลจำนวนมาก รายงานแสดงทุกเรคคอร์ดและทุก mechanism ตลอดทาง จึงเห็นเส้นทางไปสู่ผลลัพธ์สุดท้ายได้ชัดเจน

ทำไมจำนวนการค้นหา DNS จึงสำคัญ

การประเมิน SPF ค้นหา DNS ได้ไม่เกิน 10 ครั้ง mechanism include, a, mx, ptr, exists และ redirect แต่ละตัวนับรวมในขีดจำกัดนี้ รวมถึงตัวที่อยู่ใน include ที่ซ้อนกันด้วย หากเกินขีดจำกัด ผลลัพธ์จะกลายเป็นข้อผิดพลาดถาวร และผู้รับจะถือว่าข้อความไม่มี SPF ที่ถูกต้องเลย การค้นหาที่ไม่พบเรคคอร์ด (void lookup) มีขีดจำกัดแยกต่างหากที่สองครั้ง สาเหตุที่พบบ่อยคือ include ของบริการภายนอกที่ต่อกันเป็นสายยาว และการตัดรายการบริการให้สั้นลงจะแก้ปัญหาได้

DKIM พิสูจน์อะไร

DKIM เพิ่มลายเซ็นเข้ารหัสลงในส่วนหัวของข้อความ โดเมนที่ลงลายเซ็นเผยแพร่คีย์สาธารณะไว้ใน DNS ภายใต้ชื่อ selector จากนั้น echo.email จะดึงคีย์นั้นมาตรวจลายเซ็นเทียบกับส่วนหัวและเนื้อความตามที่ได้รับ ผล pass หมายความว่าส่วนที่ลงลายเซ็นมาถึงโดยไม่ถูกแก้ไข และโดเมนที่ลงลายเซ็นรับรองส่วนเหล่านั้น

รายงานแสดงโดเมนที่ลงลายเซ็น (d=), selector (s=), ส่วนหัวที่ลงลายเซ็น (h=) รวมถึงประเภทและขนาดของคีย์ หากมีการจำกัดความยาวเนื้อความ (l=) รายงานจะแจ้งเตือน เพราะการจำกัดนี้เปิดช่องให้ผู้อื่นต่อท้ายเนื้อหาได้หลังจากลงลายเซ็นแล้ว

DMARC คืออะไร

DMARC ผูก SPF และ DKIM เข้ากับโดเมนในที่อยู่ From ที่มองเห็น โดเมน From เผยแพร่นโยบายไว้ที่ _dmarc.<domain> เพื่อบอกผู้รับว่าควรจัดการอีเมลที่ยืนยันตัวตนไม่ผ่านอย่างไร: none, quarantine หรือ reject ข้อความจะผ่าน DMARC เมื่อ SPF หรือ DKIM อย่างใดอย่างหนึ่งผ่านสำหรับโดเมนที่ aligned กับโดเมน From

DMARC ไม่ได้ยืนยันตัวตนด้วยตัวเอง คุณค่าของ DMARC อยู่ที่ข้อกำหนดเรื่อง alignment และรายงานรวม (rua=) ที่ผู้รับส่งกลับไปให้เจ้าของโดเมน

aligned หมายถึงอะไร

Alignment คือการเปรียบเทียบโดเมนที่ยืนยันตัวตนแล้วกับโดเมน From โดย alignment แบบ relaxed กำหนดให้เป็นโดเมนองค์กรเดียวกัน ตัวอย่างเช่น mail.example.com จะ align กับ example.com ส่วน alignment แบบ strict กำหนดให้ชื่อโฮสต์ตรงกันทุกตัวอักษร โดเมนองค์กรได้มาจาก Public Suffix List ซึ่งรู้ว่าชื่ออย่าง example.co.uk นับเป็นโดเมนที่จดทะเบียนได้หนึ่งโดเมน เมื่อรายงานระบุว่า aligned โดยไม่มีคำขยาย หมายถึงการเปรียบเทียบกับโดเมน From

BIMI คืออะไร

BIMI เผยแพร่โลโก้แบรนด์ให้ผู้ให้บริการกล่องจดหมายแสดงข้างอีเมลที่ยืนยันตัวตนแล้ว เรคคอร์ดอยู่ที่ default._bimi.<domain> และชี้ไปยังโลโก้ SVG (l=) และสำหรับผู้ให้บริการส่วนใหญ่ ยังชี้ไปยัง Verified Mark Certificate (a=) ด้วย BIMI ใช้ได้เฉพาะกับโดเมนที่มีนโยบาย DMARC แบบบังคับใช้ คือ quarantine หรือ reject ที่ 100 เปอร์เซ็นต์ echo.email แสดงเรคคอร์ดและบอกว่านโยบาย DMARC ตรงตามข้อกำหนดหรือไม่

ทำไม reverse DNS จึงสำคัญ

ทุกที่อยู่ IP ที่ส่งอีเมลต้องมีเรคคอร์ด PTR ที่ชี้ไปยังชื่อโฮสต์ และชื่อโฮสต์นั้นต้องมีเรคคอร์ด A หรือ AAAA ที่ชี้กลับมายังที่อยู่ IP เดิม การตรวจไปกลับนี้เรียกว่า forward-confirmed reverse DNS หรือ FCrDNS ผู้ให้บริการกล่องจดหมายรายใหญ่ถือว่า FCrDNS เป็นข้อกำหนดขั้นต่ำของเซิร์ฟเวอร์ที่ส่งอีเมล และอีเมลจากที่อยู่ IP ที่ไม่มีเรคคอร์ด PTR มักถูกปฏิเสธทันที

reverse DNS แบบทั่วไปคืออะไร

เรคคอร์ด PTR บางรายการใช้รูปแบบการตั้งชื่อของ ISP เช่น 192-0-2-10.dynamic.example.net ชื่อแบบนี้บ่งบอกว่าเป็นการเชื่อมต่อตามบ้าน หรือเป็นเซิร์ฟเวอร์ที่ไม่มีใครตั้งค่าไว้สำหรับอีเมล ตัวกรองจึงมองชื่อเหล่านี้อย่างระแวง ชื่อเฉพาะในโดเมนของผู้ส่งเอง เช่น mail.example.com แสดงว่าเป็นเซิร์ฟเวอร์อีเมลที่ตั้งค่าไว้อย่างตั้งใจ

ชื่อ HELO แบบไหนดีที่สุด

เซิร์ฟเวอร์ที่ส่งจะแนะนำตัวด้วยชื่อ HELO หรือ EHLO ตอนเริ่มการสนทนา SMTP ชื่อที่ดีเป็นของเซิร์ฟเวอร์ที่ส่ง หาเจอได้ใน DNS และตรงกับเรคคอร์ด PTR ของที่อยู่ IP ที่ส่ง ที่อยู่ IP เปล่า ๆ ชื่ออย่าง localhost และข้อความสุ่มเป็นลักษณะทั่วไปของมัลแวร์ และของสแปมแบบ snowshoe ตัวกรองจึงให้น้ำหนักกับสิ่งเหล่านี้ตามนั้น

ทำไมต้องตรวจ TLS

Opportunistic TLS เข้ารหัสการสนทนา SMTP เมื่อเซิร์ฟเวอร์ผู้รับเสนอ STARTTLS echo.email เสนอ STARTTLS ในทุกการเชื่อมต่อ และบันทึกเวอร์ชัน TLS และ cipher ที่ผู้ส่งเลือก อีเมลที่ส่งโดยไม่มี TLS จะเดินทางเป็นข้อความธรรมดาระหว่างเซิร์ฟเวอร์ทั้งสอง และ Google กับ Yahoo กำหนดให้ TLS เป็นข้อกำหนดสำหรับผู้ส่งอีเมลจำนวนมาก รายงานยังนับลิงก์และรูปภาพที่โหลดผ่าน http ธรรมดาด้วย เพราะคำขอเหล่านั้นก็เดินทางโดยไม่เข้ารหัสเช่นกัน

ทำไมต้องตรวจ IPv6

ความพร้อมของ IPv6 ตัดสินจากสองคำถาม คำถามแรกคือผู้ส่งส่งถึงเซิร์ฟเวอร์อีเมลที่ใช้ IPv6 อย่างเดียวได้หรือไม่ ข้อความที่มาถึงผ่าน IPv6 ตอบว่าได้โดยตรง ข้อความที่มาถึงผ่าน IPv4 ยังนับว่ารองรับ IPv6 เมื่อโฮสต์ที่ส่งมีเรคคอร์ด AAAA, reverse DNS ของที่อยู่ IPv6 นั้นระบุชื่อโฮสต์เดียวกัน และ SPF ผ่านสำหรับที่อยู่นั้น เซิร์ฟเวอร์อีเมลส่วนใหญ่เลือก IPv4 หรือ IPv6 ในแต่ละการเชื่อมต่อ ข้อความถัดไปจากโฮสต์เดียวกันจึงมักมาถึงผ่าน IPv6 คำถามที่สองคือทุกโฮสต์ที่ให้บริการรูปภาพและลิงก์ในข้อความมีเรคคอร์ด AAAA หรือไม่ เพื่อให้ผู้อ่านบนเครือข่ายที่ใช้ IPv6 อย่างเดียวหรืออยู่หลัง carrier-grade NAT ยังโหลดเนื้อหาได้ รายงานจะระบุว่าข้อความพร้อมสำหรับ IPv6 เมื่อคำตอบทั้งสองข้อคือได้

วัดขนาดอีเมลอย่างไร

ขนาดอีเมลคือจำนวนไบต์ตามที่ส่งจริง ได้แก่ ส่วนหัวทั้งหมด ทุกส่วน MIME ไฟล์แนบ และส่วนที่เพิ่มขึ้นจากการเข้ารหัส base64 หรือ quoted-printable Gmail จะตัดข้อความที่มี HTML เกินประมาณ 102 KB และซ่อนส่วนที่เหลือไว้หลังลิงก์ และส่วนที่ถูกตัดมักมีลิงก์ยกเลิกรับข่าวสารและพิกเซลติดตามอยู่ด้วย

น้ำหนักรูปภาพคืออะไร

น้ำหนักรูปภาพคือขนาดรวมของรูปภาพภายนอกที่อ้างถึงในแท็ก <img> วัดโดยดาวน์โหลดแต่ละรูปหนึ่งครั้ง ตัวเลขนี้เป็นค่าต่ำสุด เพราะไม่ได้นับรูปภาพจากแอตทริบิวต์ srcset และพื้นหลัง CSS ข้อความที่หนักจะโหลดช้าบนการเชื่อมต่อมือถือ และทำให้ผู้อ่านเสียค่าอินเทอร์เน็ต

ส่วนเกินของรูปภาพคืออะไร

ส่วนเกินของรูปภาพคือการประมาณจำนวนไบต์ที่ผู้ส่งประหยัดได้ หากส่งรูปภาพแต่ละรูปให้มีขนาดใกล้กับขนาดที่ข้อความแสดง รูปภาพที่ใหญ่ไม่เกินสองเท่าของขนาดที่แสดงนับว่าไม่มีส่วนเกิน เพราะหน้าจอความละเอียดสูงใช้พิกเซลที่เพิ่มมา เมื่อเกินสองเท่าของขนาดที่แสดง พิกเซลที่เพิ่มมาจะเพิ่มจำนวนไบต์โดยไม่ได้เพิ่มรายละเอียด รูปภาพที่เล็กกว่า 1 KB เช่น รูปเว้นระยะ จะไม่ถูกนำมาคิด

echo.email จัดการรูปภาพอย่างไร

การวิเคราะห์จะดาวน์โหลดรูปภาพภายนอกทุกรูปหนึ่งครั้ง และบันทึกสถานะ HTTP การเปลี่ยนเส้นทาง ขนาด ประเภทเนื้อหา และขนาดเป็นพิกเซล จากนั้นเปรียบเทียบขนาดพิกเซลกับขนาดที่ระบุใน HTML การดาวน์โหลดรูปภาพเป็นสิ่งที่โปรแกรมอีเมลทำเมื่อผู้อ่านเปิดข้อความ ระบบติดตามการเปิดอ่านจึงบันทึกว่ามีการเปิด การดาวน์โหลดมาจากเครือข่าย Cloudflare และคำขอไปยังที่อยู่ส่วนตัวหรือที่อยู่ภายในจะถูกปฏิเสธ

ลิงก์ถูกแยกออกมาจาก HTML และจัดกลุ่มตามโฮสต์ โดยถอดรหัสพารามิเตอร์ของ query ให้อ่านง่ายขึ้น echo.email ไม่เปิดลิงก์ทั่วไปเลย เพราะการเปิดลิงก์อาจเป็นการยืนยันการสมัครรับข่าวสาร สั่งให้เกิดการกระทำบางอย่าง หรือถูกนับเป็นการคลิก ข้อยกเว้นเดียวคือ URL สำหรับยกเลิกรับข่าวสารแบบคลิกเดียวที่อธิบายไว้ด้านล่าง

List-Unsubscribe คืออะไร

List-Unsubscribe เป็นส่วนหัวที่กำหนดไว้ใน RFC 2369 ส่วนหัวนี้มีวิธีออกจากรายชื่อหนึ่งวิธีขึ้นไป ในรูปแบบที่อยู่ mailto: URL แบบ https: หรือทั้งสองแบบ ผู้ให้บริการกล่องจดหมายใช้ส่วนหัวนี้แสดงปุ่มยกเลิกรับข่าวสารของตัวเองข้างชื่อผู้ส่ง URL แบบ http ธรรมดาล้าสมัยแล้ว รูปแบบที่คาดหวังคือ https

การยกเลิกรับข่าวสารแบบคลิกเดียวคืออะไร

RFC 8058 เพิ่มส่วนหัวที่สอง คือ List-Unsubscribe-Post ที่มีค่าคงที่ List-Unsubscribe=One-Click เมื่อมีส่วนหัวทั้งสอง ผู้ให้บริการกล่องจดหมายจะส่งคำขอ POST ไปยัง URL แบบ https และผู้รับจะออกจากรายชื่อได้โดยไม่ต้องเข้าหน้าเว็บ Google และ Yahoo กำหนดให้ผู้ส่งอีเมลจำนวนมากต้องมีการยกเลิกรับข่าวสารแบบคลิกเดียว

echo.email ส่งคำขอ POST แบบเดียวกันและรายงานการตอบกลับ สถานะ 2xx ใด ๆ นับว่าสำเร็จ คำขอนี้ยกเลิกการรับข่าวสารเฉพาะที่อยู่ชั่วคราวของ echo.email เท่านั้น

การยกเลิกรับข่าวสารแบบไม่ต้องโต้ตอบหมายถึงอะไร

การยกเลิกรับข่าวสารแบบไม่ต้องโต้ตอบเสร็จสมบูรณ์โดยที่ผู้รับไม่ต้องเปิดเบราว์เซอร์หรือยืนยันสิ่งใด แบบคลิกเดียวตาม RFC 8058 เป็นวิธีที่แนะนำ ที่อยู่ mailto: ใน List-Unsubscribe ก็นับด้วย แต่การยกเลิกทางอีเมลช้ากว่าและผู้รับไม่ได้รับการยืนยัน ผู้ให้บริการจึงถือว่า mailto เป็นวิธีสำรอง

ทำไมยังต้องมีลิงก์ยกเลิกรับข่าวสารในเนื้อความ

กฎหมายการตลาดในประเทศส่วนใหญ่คาดหวังให้มีวิธีออกจากรายชื่อที่มองเห็นได้ภายในข้อความ ซึ่งมักเป็นลิงก์ในส่วนท้าย ส่วนหัวมีไว้ให้ผู้ให้บริการกล่องจดหมาย และลิงก์ในส่วนท้ายมีไว้ให้ผู้อ่าน ส่วน echo.email จะมองหาลิงก์ที่มีถ้อยคำเกี่ยวกับการยกเลิกรับข่าวสาร หรือ URL ที่มีลักษณะเป็นการยกเลิกรับข่าวสาร การตรวจหานี้เป็นการคาดเดา และบางครั้งอาจเลือกลิงก์ผิด การใส่พารามิเตอร์ติดตามแยกต่างหากในลิงก์ส่วนท้ายจะช่วยแยกการยกเลิกจากส่วนท้ายกับจากส่วนหัวในสถิติของผู้ส่ง

List-Id คืออะไร

List-Id (RFC 2919) ระบุชื่อรายชื่ออีเมลที่ข้อความนั้นสังกัด เช่น News <news.example.com> Google และ Yahoo ไม่ได้กำหนดให้ต้องมีส่วนหัวนี้ ผู้รับและเซิร์ฟเวอร์ผู้รับใช้ส่วนหัวนี้จัดเรียงและกรองอีเมลตามสายข้อความ การเพิ่มส่วนหัวนี้จึงเป็นแนวปฏิบัติที่ดี

รายการตรวจแนวปฏิบัติที่ดีคืออะไร

รายการตรวจนี้ทำตามข้อกำหนดที่ Google และ Yahoo ประกาศสำหรับผู้ส่งอีเมลจำนวนมากในปี 2024 ได้แก่ SPF ที่ aligned, DKIM ที่ aligned, forward-confirmed reverse DNS, TLS, โดเมน From ที่ไม่ใช่ผู้ให้บริการอีเมลฟรีและ DMARC ไม่ล้มเหลว, นโยบาย DMARC ที่เผยแพร่แล้ว, วิธียืนยันตัวตนที่ aligned อย่างน้อยหนึ่งวิธี, การยกเลิกรับข่าวสารแบบคลิกเดียว และลิงก์ยกเลิกรับข่าวสารที่มองเห็นได้ แต่ละแถวแสดงว่าใช่หรือไม่ แถวสีแดงมีแนวโน้มเป็นสาเหตุที่อีเมลเข้ากล่องจดหมายของผู้ให้บริการรายใหญ่ได้น้อยลง และคะแนนเต็มคือมาตรฐานพื้นฐานสำหรับอีเมลจำนวนมาก

บางแถวนับคะแนนเฉพาะเมื่อเกี่ยวข้องเท่านั้น สองแถวเรื่องการยกเลิกรับข่าวสารจะนับเมื่อข้อความมีส่วนหัวของอีเมลจำนวนมาก ได้แก่ List-Unsubscribe, List-Unsubscribe-Post, List-Id หรือ Precedence ที่ตั้งค่าเป็น bulk, list หรือ junk ข้อความส่วนตัวที่ไม่มีส่วนหัวเหล่านี้จะข้ามสองแถวนี้ไป แถว SPF alignment จะไม่นับคะแนนเมื่อผู้ส่ง envelope ถูกเขียนใหม่ด้วย SRS และ DMARC ผ่านด้วย DKIM ที่ aligned ทั้งนี้ เมื่อเขียนใหม่ด้วย SRS แล้ว SPF จะตรวจโดเมนของเซิร์ฟเวอร์ที่เขียนใหม่แทนโดเมน From บริการส่งต่ออีเมลใช้ SRS ตามการออกแบบ และเซิร์ฟเวอร์ส่งอีเมลบางแห่งใช้ SRS กับอีเมลขาออกทั้งหมด ซึ่งทำให้ SPF ไม่ aligned คะแนนแสดงจำนวนแถวที่ผ่านจากจำนวนแถวที่นับ

แสดงผลข้อความอย่างไร

มุมมองที่แสดงผลจะแสดงส่วน HTML ภายในกรอบ sandbox เบราว์เซอร์เป็นผู้แสดงผล ผลลัพธ์จึงตรงกับเบราว์เซอร์บนเดสก์ท็อป ไม่ใช่โปรแกรมอีเมลหรืออุปกรณ์ใดโดยเฉพาะ สคริปต์ ฟอร์ม และลิงก์ถูกปิดใช้งานในตัวอย่าง มุมมองแยกต่างหากจะแสดงข้อความเมื่อบล็อกรูปภาพ และเมื่อแสดงข้อความ alt แทนรูปภาพแต่ละรูป ซึ่งเป็นสิ่งที่ผู้อ่านจำนวนมากเห็นเป็นอย่างแรก

หมวด MIME ในรายงานแสดงอะไร

MIME คือโครงสร้างภายในข้อความ ได้แก่ ส่วนต่าง ๆ ประเภทเนื้อหา ชุดอักขระ การเข้ารหัสสำหรับส่ง และ boundary ที่คั่นระหว่างส่วน จดหมายข่าวทั่วไปมีคอนเทนเนอร์ multipart/alternative ที่มีส่วน text/plain และส่วน text/html การไม่มีส่วนข้อความธรรมดา การไม่มี boundary ปิดท้าย หรือการซ้อนกันแบบผิดปกติจะเห็นได้ชัดในแผนผัง

ส่วนข้อมูลดิบแสดงอะไร

ส่วนข้อมูลดิบแสดงข้อความดิบตามที่ได้รับ พร้อมสถิติ ได้แก่ ขนาดรวม จำนวนบรรทัด บรรทัดที่ยาวที่สุด อักขระนอก ASCII และการขึ้นบรรทัดแบบ LF เดี่ยว ทั้งนี้ RFC 5322 จำกัดความยาวบรรทัดไว้ที่ 998 อักขระ และเซิร์ฟเวอร์บางแห่งจะตัดหรือปฏิเสธบรรทัดที่ยาวกว่านั้น การขึ้นบรรทัดแบบ LF เดี่ยวที่ไม่มี carriage return เป็นสาเหตุที่พบบ่อยของ DKIM ล้มเหลว เพราะเซิร์ฟเวอร์ระหว่างทางจะเขียนส่วนนี้ใหม่

มุมมองข้อความดิบเริ่มต้นด้วยส่วนหัว trace ที่ mx.echo.email บันทึกตอนรับอีเมล ได้แก่ Return-Path, Authentication-Results, Received-SPF และ Received ด้านล่างคือข้อความตรงตามที่ได้รับทุกประการ และลิงก์ดาวน์โหลดจะให้ไฟล์ .eml ที่ไม่ถูกแก้ไข

รายงานนี้ตรวจ blocklist ใดบ้าง

ผู้รับจะค้นหาที่อยู่ IP ที่ส่งและโดเมนผู้ส่งใน DNS blocklist และการอยู่ในรายการที่ใช้กันแพร่หลายจะทำให้อีเมลถูกปฏิเสธหรือถูกกรอง รายงานตรวจรายการเดียวกับ scan.mx ได้แก่ Spamhaus ZEN และ AuthBL สำหรับที่อยู่ IP, Spamhaus DBL และ ZRD สำหรับโดเมน From และโดเมน envelope รวมถึง SpamCop, GBUdb Truncate และ PSBL สำหรับที่อยู่ IPv4 แต่ละแถวแสดงว่าอยู่ในรายการหรือไม่ พร้อมลิงก์ไปยังหน้าขอถอดชื่อออกของผู้ดูแลรายการ

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

คะแนน SpamAssassin หมายถึงอะไร

SpamAssassin เป็นตัวกรองสแปมแบบโอเพนซอร์สที่เซิร์ฟเวอร์ผู้รับจำนวนมากใช้ เซิร์ฟเวอร์อีเมลให้คะแนนข้อความทดสอบแต่ละฉบับด้วย SpamAssassin และชุดกฎมาตรฐานที่อัปเดตทุกวัน รายงานแสดงคะแนนรวม เกณฑ์สแปมซึ่งอยู่ที่ 5 คะแนน และทุกกฎที่ตรงกัน โดยเรียงจากคะแนนสูงสุดก่อน คะแนนติดลบเป็นผลดีต่อข้อความ เช่น ลายเซ็น DKIM ที่ถูกต้อง

การทดสอบผ่านเครือข่ายจะค้นหาที่อยู่ IP ที่ส่งและโดเมนในลิงก์บน Spamhaus (ผ่าน DQS), URIBL, SURBL และรายการอื่น ๆ ในชุดกฎมาตรฐาน การเรียนรู้แบบ Bayesian และเครือข่ายแฮชที่ใช้ร่วมกันอย่าง Razor, Pyzor และ DCC ถูกปิดไว้ คะแนนจึงขึ้นอยู่กับตัวข้อความเท่านั้น และไม่มีข้อมูลใดของข้อความออกจากเซิร์ฟเวอร์เพื่อใช้ในการเรียนรู้

คะแนนนี้ใช้เพื่ออ้างอิงและไม่นับรวมในคะแนนแนวปฏิบัติที่ดี ผู้รับแต่ละรายใช้ตัวกรองของตัวเองซึ่งมีกฎและเกณฑ์ของตัวเอง และ Gmail กับ Outlook ไม่ได้ใช้ SpamAssassin เลย คะแนนที่มากกว่าศูนย์เป็นเรื่องปกติ กฎที่มีคะแนนสูงสุดจะบอกว่าการแก้ไขตรงไหนช่วยได้มากที่สุด ข้อความที่ใหญ่กว่า 500 KB จะไม่ถูกให้คะแนน

ทำไมโดเมนผู้ส่งต้องมีเซิร์ฟเวอร์อีเมล

การตอบกลับจะไปที่โดเมน From และอีเมลตีกลับจะไปที่โดเมนของผู้ส่ง envelope ทั้งสองโดเมนต้องมีเรคคอร์ด MX หรืออย่างน้อยต้องมีเรคคอร์ดที่อยู่ ซึ่งเซิร์ฟเวอร์อีเมลใช้เป็นทางสำรอง Null MX คือ MX รายการเดียวที่ชี้ไปยังจุด (RFC 7505) เป็นการประกาศว่าโดเมนนั้นไม่รับอีเมลเลย และผู้รับบางรายจะปฏิเสธข้อความจากโดเมนแบบนี้

องค์ประกอบ HTML ใดที่นับว่าเสี่ยง

สคริปต์, ฟอร์ม, iframe, object และ embed แทบไม่มีที่ใช้ในอีเมล โปรแกรมอีเมลส่วนใหญ่จะตัดออก และตัวกรองสแปมให้คะแนนสิ่งเหล่านี้เป็นสัญญาณของฟิชชิง ลิงก์และรูปภาพธรรมดาทำหน้าที่เดียวกันได้โดยไม่ถูกหักคะแนน ส่วนเนื้อหายังแสดงขนาด HTML และปริมาณข้อความที่มองเห็นได้ใน HTML ด้วย เพราะข้อความที่เกือบทั้งหมดเป็นมาร์กอัปหรือรูปภาพจะดูน่าสงสัยในสายตาของตัวกรอง

ทำไมจึงแจ้งเตือนลิงก์ย่อ

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

ส่วน DNS แสดงอะไร

ทุกการค้นหา DNS ที่ทำเพื่อรายงานจะปรากฏในส่วน DNS โดยจัดกลุ่มตามจุดประสงค์ ได้แก่ reverse DNS, SPF, DKIM, DMARC, BIMI, เซิร์ฟเวอร์อีเมล และการตรวจ IPv6 การค้นหา blocklist ไม่อยู่ในรายการนี้ เพราะชื่อที่ใช้ค้นหามีคีย์การเข้าถึงอยู่ แต่ละรายการแสดงชื่อ ประเภทเรคคอร์ด รหัสการตอบกลับ คำตอบพร้อม TTL และเรคคอร์ด authority ถ้ามี รายการนี้แสดงว่าเรคคอร์ดใดให้ผลลัพธ์แต่ละอย่าง ซึ่งช่วยได้เมื่อการเปลี่ยนแปลง DNS ล่าสุดยังไปไม่ถึงทุก resolver

เครื่องมือฟรีอื่น ๆ

scan.mx
ตรวจการตั้งค่าอีเมลของโดเมน: MX, SPF, DKIM, DMARC, BIMI
portscan.com
ตรวจว่าพอร์ต TCP ใดเปิดอยู่บนที่อยู่ IP รวมถึงพอร์ต 25