ทีมผลิตภัณฑ์ควรประเมินอะไรเมื่อเลือกบริการตรวจสอบอีเมล

กำหนดการตรวจสอบเป็นหลายการตรวจสอบที่แยกจากกัน

“การตรวจสอบอีเมล” อาจหมายถึงการตรวจสอบฟอร์มฝั่งไคลเอนต์ การแยกวิเคราะห์ Internet Message Format การมีอยู่ของโดเมน การตรวจสอบการกำหนดเส้นทางอีเมลผ่าน DNS บทสนทนา SMTP ข้อมูลอีเมลตีกลับในอดีต การจัดหมวดหมู่โดเมนใช้ครั้งเดียว การแนะนำเมื่อพิมพ์ผิด หรือหลักฐานว่าบุคคลควบคุมที่อยู่นั้น งานเหล่านี้สังเกตข้อเท็จจริงคนละอย่าง ให้เริ่มจากการตัดสินใจที่เป็นลายลักษณ์อักษร คือ บล็อกอินพุตสมัครใช้งานที่ผิดรูป เตือนเรื่องการพิมพ์ผิดที่น่าจะเป็น ลดการส่งซ้ำไปยังที่อยู่ที่ล้มเหลวถาวร หรือทบทวนรายชื่อที่นำเข้าโดยมีวัตถุประสงค์ที่ชอบด้วยกฎหมายและเป็นที่คาดหมาย ให้ผู้ให้บริการแต่ละรายระบุหลักฐานที่แน่นอนเบื้องหลังผลลัพธ์ valid, invalid, risky, unknown, accept-all, disposable, role-based และ temporary คะแนนสีเขียวเพียงค่าเดียวไม่ควรรวมไวยากรณ์ ข้อมูลชื่อเสียงจากบุคคลที่สาม และการตอบกลับชั่วคราวของเซิร์ฟเวอร์ระยะไกลเข้าด้วยกันโดยไม่บอกกล่าว ให้เก็บเหตุผลดิบ เวลาที่ตรวจสอบ อินพุตที่ปรับให้เป็นมาตรฐาน และการตัดสินใจตามนโยบายแยกจากกัน เพื่อให้ผลิตภัณฑ์เปลี่ยนเกณฑ์ได้โดยไม่ต้องแสร้งว่าข้อสังเกตเบื้องหลังเปลี่ยนไป

แยกวิเคราะห์ไวยากรณ์โดยไม่ปฏิเสธที่อยู่ที่ถูกต้อง

ไวยากรณ์ที่อยู่อีเมลบนอินเทอร์เน็ตกว้างกว่านิพจน์ปรกติที่ใช้ในเว็บฟอร์มทั่วไป RFC 5322 กำหนดไวยากรณ์ที่อยู่ในข้อความ ส่วน SMTP กำหนดข้อกำหนดการขนส่งสำหรับรูปแบบกล่องจดหมายและโดเมน ให้ใช้ parser ที่มีการดูแลและการตรวจสอบอินพุตเบื้องต้นแบบไม่เข้มงวด แทนนิพจน์ที่เขียนเองซึ่งรับเฉพาะรูปแบบผู้บริโภคที่คุ้นเคย เก็บที่อยู่ดั้งเดิมของผู้ใช้ไว้สำหรับการแสดงผลและการตรวจสอบย้อนหลัง แต่ปรับให้เป็นมาตรฐานเฉพาะกฎที่ทีมอธิบายได้ ชื่อโดเมนไม่แยกตัวพิมพ์เล็กใหญ่ ส่วน local-part อาจจัดการต่างกันตามผู้ให้บริการ การแปลงเป็นตัวพิมพ์เล็กหรือลบเครื่องหมายวรรคตอนอาจรวมกล่องจดหมายที่ต่างกันเข้าด้วยกัน ตัดสินใจว่าผลิตภัณฑ์รองรับที่อยู่แบบสากลหรือไม่ และบันทึกขอบเขตนั้นให้ชัดเจน ไวยากรณ์ผ่านหมายความเพียงว่าที่อยู่นั้นแทนได้ตามไวยากรณ์ที่รองรับ ไม่ได้พิสูจน์ว่าโดเมนรับอีเมล กล่องจดหมายมีอยู่ บุคคลเป็นเจ้าของ หรือผู้รับร้องขอข้อความ ผู้ให้บริการตรวจสอบควรส่งเหตุผลด้านไวยากรณ์กลับมา แทนที่จะแทนที่ที่อยู่ที่ผิดปกติแต่รองรับโดยไม่ขอการยืนยัน

ตรวจสอบหลักฐานโดเมนและการกำหนดเส้นทางอีเมล

ค้นหาโดเมนของที่อยู่ผ่าน DNS และแยกเส้นทางอีเมลที่ใช้ได้ออกจากความล้มเหลวในการค้นหา การส่ง SMTP โดยปกติใช้เรคคอร์ด MX และพฤติกรรม fallback ที่กำหนดไว้ ส่วน RFC 7505 ให้โดเมนเผยแพร่ Null MX เพื่อแจ้งว่าไม่รับอีเมลใด ๆ บริการควรรายงาน NXDOMAIN, Null MX, MX ที่ถูกต้อง, implicit fallback, DNS timeout, SERVFAIL และข้อผิดพลาดที่เกี่ยวกับ DNSSEC หรือ resolver เป็นข้อสังเกตที่ต่างกัน ความล้มเหลวของ resolver ชั่วคราวต้องไม่กลายเป็นคำตัดสินว่าไม่ถูกต้องถาวร บันทึกเวลาของ resolver และคำตอบสุดท้าย เพราะการเปลี่ยนแปลงและแคชของ DNS ทำให้ผลลัพธ์หมดอายุได้ ความสำเร็จระดับโดเมนไม่ได้พิสูจน์ว่ามีกล่องจดหมายใดกล่องหนึ่งอยู่ MX ที่ถูกต้องอาจให้บริการที่อยู่นับล้าน ผ่านเกตเวย์ความปลอดภัย รับผู้รับทุกคน หรือเลื่อนการตรวจสอบไปภายหลัง ควรให้ผู้ให้บริการเปิดเผยหลักฐานระดับโดเมน แทนที่จะอธิบายทุกโดเมนที่มีเรคคอร์ด MX ว่าเป็นผู้รับที่ยืนยันแล้ว

มอง SMTP probing ว่าไม่แน่นอนและอ่อนไหวต่อนโยบาย

บางบริการเชื่อมต่อกับเซิร์ฟเวอร์ SMTP ปลายทางและออกคำสั่งใน transaction มากพอที่จะสังเกตการจัดการผู้รับโดยไม่ส่งเนื้อหาข้อความ RFC 5321 กำหนดคำสั่งและการตอบกลับ แต่ระบบระยะไกลอาจปิดคำสั่งตรวจสอบ ยอมรับผู้รับทุกคนในตอนแรก ปฏิเสธ probe ทำ tarpit ทำ greylist จำกัดอัตรา เปลี่ยนพฤติกรรมตาม IP ที่เชื่อมต่อ หรือหน่วงการตรวจสอบผู้รับจนหลังยอมรับข้อความ การตอบกลับ `250` ต่อ `RCPT TO` คือหลักฐานจากเซิร์ฟเวอร์หนึ่ง ณ เวลาหนึ่ง ไม่ใช่ข้อพิสูจน์ว่ากล่องจดหมายมีผู้ดูแลหรือจะยอมรับข้อความระบบจริงในภายหลัง การตอบกลับ `4xx` เป็นแบบชั่วคราว และปกติควรให้ผลเป็นไม่ทราบหรือลองใหม่ภายหลัง ไม่ใช่ไม่ถูกต้อง การตอบกลับ `5xx` ต้องมีขั้นคำสั่งและข้อมูลวินิจฉัยที่แน่นอนก่อนจึงใช้ประกอบการตัดสินใจว่าที่อยู่อีเมลนั้นใช้ไม่ได้ถาวร ให้ถามว่าผู้ขายระบุตัวตนอย่างรับผิดชอบหรือไม่ จำกัดทราฟฟิก เคารพนโยบายเซิร์ฟเวอร์ ใช้ตัวตน envelope จริง และป้องกันไม่ให้โครงสร้างพื้นฐานการ probe สร้างปัญหาด้านชื่อเสียงหรือการละเมิดให้ลูกค้าหรือไม่

เรียกร้องผลลัพธ์ที่อธิบายได้และระบบอัตโนมัติที่ระมัดระวัง

กำหนดโมเดลผลลัพธ์ภายในก่อนเชื่อมต่อกับผู้ให้บริการ มิติที่เป็นประโยชน์ได้แก่ สถานะไวยากรณ์ สถานะโดเมน สถานะ MX Null MX ข้อสังเกต SMTP รหัสสถานะแบบขยาย หลักฐาน accept-all การจัดหมวดหมู่ disposable หรือ role คำแนะนำเมื่อพิมพ์ผิด ความเชื่อมั่น เวลาที่ตรวจสอบ และแหล่งข้อมูล ให้ `unknown` และ `temporary` เป็นผลลัพธ์ระดับหนึ่ง อย่าบังคับให้เป็น valid เพียงเพื่อเพิ่มยอดสมัคร หรือเป็น invalid เพียงเพื่อให้โค้ดง่ายขึ้น สงวนการบล็อกเด็ดขาดไว้สำหรับหลักฐานที่ผลิตภัณฑ์อนุมัติไว้อย่างตั้งใจ เช่น ไวยากรณ์ที่เป็นไปไม่ได้ โดเมน Null MX หรือความล้มเหลวถาวรที่ซ้ำและเป็นปัจจุบันตามนโยบายของผลิตภัณฑ์ ใช้การเตือนหรือขอการยืนยันสำหรับการพิมพ์ผิดที่น่าจะเป็น สำหรับกรณีที่กำกวม ให้ยืนยันความเป็นเจ้าของผ่านขั้นตอนยืนยันปกติของผลิตภัณฑ์ หรืออนุญาตให้ส่งครั้งแรกแบบควบคุมและประมวลผลผลลัพธ์ บันทึกว่ากฎใดเป็นผู้ตัดสิน โดยไม่เก็บประวัติที่อยู่มากกว่าที่ซัพพอร์ต การป้องกันการฉ้อโกง ความเป็นส่วนตัว และความปลอดภัยของผู้รับจำเป็นต้องใช้จริง

วัดความแม่นยำด้วยชุดทดสอบที่ควบคุมและมีกรอบเวลา

สร้างชุดทดสอบที่ทีมทราบค่าจริงได้อย่างถูกกฎหมาย ได้แก่ ที่อยู่ในโดเมนที่เป็นเจ้าของ กล่องจดหมายที่ควบคุม ผู้รับที่ไม่มีอยู่จริงอย่างชัดเจน โดเมน Null MX โดเมน catch-all กรณี Unicode ภายในขอบเขตที่รองรับ กรณีขอบของไวยากรณ์ และเซิร์ฟเวอร์ที่ตั้งค่าให้ตอบกลับชั่วคราว รันผู้ให้บริการแต่ละรายในเวลาเดียวกันและเก็บรหัสเหตุผล ไม่ใช่แค่ป้ายผลลัพธ์ วัดการบล็อกผิด การยอมรับผิด อัตรา unknown ความหน่วง การเปลี่ยนแปลงของผลลัพธ์ และเวลาในการฟื้นตัวจากความล้มเหลวของ DNS หรือ SMTP ชั่วคราว ห้ามทดสอบด้วยที่อยู่ที่ซื้อมาหรือดึงมา หลีกเลี่ยงการอ้างเปอร์เซ็นต์ความแม่นยำสากลจากตัวอย่างแคบ เพราะส่วนผสมของโดเมน นโยบายผู้รับ ชื่อเสียงของการ probe เวลา และอายุของที่อยู่ ล้วนมีผลต่อข้อสังเกต ตรวจสอบผลซ้ำหลังช่วงความสดใหม่ที่ผู้ให้บริการระบุและหลังการเปลี่ยนโดเมนแบบควบคุม ช่วงพิสูจน์ควรตรวจสอบประโยชน์ของการตัดสินใจและพฤติกรรมเชิงปฏิบัติการ ไม่ใช่สร้างทราฟฟิกที่ผู้รับไม่ได้ร้องขอ

แยกการตรวจสอบออกจากความยินยอมและชื่อเสียงผู้ส่ง

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

ทบทวนความเป็นส่วนตัว ความปลอดภัย และการเก็บรักษา ก่อนอัปโหลดที่อยู่

รายชื่อที่อยู่อีเมลเป็นข้อมูลส่วนบุคคลและอ่อนไหวทางการค้า แม้บริการจะส่งกลับเพียงคะแนน ให้ถามว่าที่อยู่ถูกประมวลผลที่ไหน ถูกจัดเก็บหรือไม่ อินพุตดิบและผลลัพธ์อยู่นานเท่าใด subprocessor ใดได้รับข้อมูล และถูกนำไปใช้ซ้ำเพื่อ network intelligence การเปรียบเทียบเกณฑ์มาตรฐาน หรือการฝึกโมเดลหรือไม่ ควรเลือกอินเทอร์เฟซแบบที่อยู่เดียวหรือแบบ batch ที่ใช้ฟิลด์น้อยที่สุดและรองรับการลบ การส่งออก การควบคุมตามภูมิภาค และการแยก tenant เก็บ API key ไว้ใน secret manager จำกัดตามสภาพแวดล้อมและ workload เมื่อเป็นไปได้ ยืนยันตัวตนของ callback และป้องกันไม่ให้ที่อยู่หรือข้อมูลรับรองเข้าไปอยู่ในระบบวิเคราะห์ URL ประวัติเทอร์มินัล พรอมต์ หรือล็อกวงกว้าง การอัปโหลดแบบ batch ต้องมีการอนุญาต ขีดจำกัดขนาด การแยกวิเคราะห์ที่ปลอดภัยจากมัลแวร์ ประวัติการตรวจสอบ และวันหมดอายุ การลบตามสัญญายังไม่พอ หากการส่งออก การสำรองข้อมูล ร่องรอยดีบัก และชุดข้อมูลชื่อเสียงที่สร้างจากข้อมูลยังไม่มีคำอธิบาย ทดสอบว่าเวิร์กสเปซหนึ่งค้นหาประวัติการตรวจสอบของอีกเวิร์กสเปซไม่ได้ และไม่สามารถอนุมานได้ว่าที่อยู่ปรากฏในข้อมูลของลูกค้ารายอื่นหรือไม่

ประเมิน API และเส้นทางการออกในฐานะระบบปฏิบัติการ

ควรต้องมี request ID ที่คงที่ รหัสเหตุผลที่มีเวอร์ชัน ข้อผิดพลาด HTTP ที่ชัดเจน การสร้าง batch แบบ idempotent การแบ่งหน้า สถานะรายรายการ เฮดเดอร์ rate limit คำแนะนำการลองใหม่ การยืนยันตัวตนของ webhook และขนาดสูงสุดที่มีเอกสาร การ timeout อาจทิ้ง batch ไว้ในสถานะกำกวม ไคลเอนต์จึงต้องมีการกระทบยอด ไม่ใช่ส่งซ้ำแบบไม่ดูสถานะ กำหนดว่าผลลัพธ์ค้นหาได้นานเท่าใด และทีมส่งออก hash ของอินพุตดั้งเดิม ค่าที่ปรับให้เป็นมาตรฐาน หลักฐาน เวลา และการตัดสินใจได้อย่างไรเมื่อเปลี่ยนผู้ให้บริการ ตรวจสอบหน่วยการใช้งานอย่างละเอียด ต่อที่อยู่ที่ส่ง ที่อยู่ไม่ซ้ำ ผลที่เสร็จสมบูรณ์ การลองใหม่ หรือการตรวจสอบเสริม อาจทำให้ต้นทุนต่างกัน ทดสอบการหมุนเวียน key ข้อมูลรับรองที่ถูกเพิกถอน rate limit การล้มเหลวบางส่วนของ batch การเล่นซ้ำของ callback การเสร็จล่าช้า การลบ และการปิดบัญชี รักษาโมเดลผลลัพธ์ของผลิตภัณฑ์เองไว้ เพื่อไม่ให้ป้ายเฉพาะของผู้ให้บริการกระจายเข้าไปในตรรกะทางธุรกิจ ความสามารถในการย้ายผู้ให้บริการสำคัญ เพราะอาจต้องใช้การตัดสินใจตรวจสอบในอดีตระหว่างการซัพพอร์ต การตรวจสอบการฉ้อโกง ข้อพิพาทเรื่องความยินยอม และการย้ายผู้ให้บริการ

ใช้ SendHQ สำหรับความสามารถด้านอีเมลที่มีเอกสารกำกับ

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

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

แหล่งอ้างอิง

• ข้อกำหนด RFC 5321: Simple Mail Transfer Protocol — RFC Editor
• ข้อกำหนด RFC 5322: Internet Message Format — RFC Editor
• ข้อกำหนด RFC 7505: A Null MX No Service Resource Record for Domains That Accept No Mail — RFC Editor
• ข้อกำหนด RFC 3463: Enhanced Mail System Status Codes — RFC Editor
• แนวทางสำหรับผู้ส่งอีเมลของ Gmail — Google
• แนวปฏิบัติที่ดีที่สุดสำหรับผู้ส่งของ Yahoo — Yahoo Sender Hub
• คู่มือสรุปการตรวจสอบอินพุตของ OWASP — OWASP Foundation
• สัญญา OpenAPI ของ SendHQ — SendHQ