ตรวจสอบอีเมล (syntax + ตรวจจับการพิมพ์ผิ
พิมพ์อีเมลเพื่อตรวจสอบว่า syntax ถูกต้องและหาการพิมพ์ผิดของ domain เช่น 'gmial.com' → 'gmail.com' แสดงรายละเอียด local-part, domain, TLD และเตือนเมื่อเกินขีดจำกัด RFC
- Local part
- user
- Domain
- example.com
- TLD
- com
- Plus tag (+)
- —
วิธีการทำงาน
เครื่องมือนี้ทำอะไรได้ (และทำอะไรไม่ได้)
การตรวจสอบ syntax อีเมลตรวจว่า 'name@domain.tld' ปฏิบัติตามกฎโครงสร้างใน RFC 5322 หรือไม่ เราใช้ regex ที่ใช้งานได้จริงซึ่งจับการพิมพ์ผิดในโลกจริงเกือบทั้งหมด ในขณะที่ยังยืดหยุ่นพอสำหรับที่อยู่ที่ถูกต้องที่มี plus tag, dots และ TLD ที่ผิดปกติ
สิ่งที่เครื่องมือนี้ทำไม่ได้: ยืนยันว่าที่อยู่รับอีเมลได้จริง สิ่งนั้นต้องส่งอีเมลจริงหรือทำการตรวจสอบ SMTP ซึ่งต้องใช้โค้ดฝั่งเซิร์ฟเวอร์และมีความเสี่ยง false positive การตรวจสอบ syntax จับการพิมพ์ผิดในราคาถูก การตรวจสอบ deliverability ต้องการวิธีอื่น
การตรวจจับการพิมพ์ผิดทั่วไป
เราตรวจหาการพิมพ์ผิดในผู้ให้บริการอีเมลฟรีหลัก — 'gmial.com' แทน 'gmail.com', 'yaho.com' แทน 'yahoo.com' ฯลฯ ประมาณ 95% ของการพิมพ์ผิดในการสมัครอีเมลเป็นการพิมพ์ผิด domain ของผู้ให้บริการไม่กี่รายเหล่านี้ การจับฝั่ง client ช่วยให้คุณไม่ต้องส่งอีเมลต้อนรับที่เด้งกลับ
หากคุณสร้างฟอร์มสมัคร ใช้ตรรกะเดียวกันก่อนส่ง แสดงคำแนะนำ 'คุณหมายถึง...?' และให้ผู้ใช้ยอมรับหรือปฏิเสธ ฟอร์มสมัครที่ดีทำเช่นนี้เป็นประจำ ช่วยปรับปรุง deliverability อีเมลอย่างเห็นได้ชัด
กฎ local part
Plus tag ('user+filter@gmail.com'): รองรับกันอย่างกว้างขวางโดยผู้ให้บริการหลัก ใช้สร้างที่อยู่เฉพาะสำหรับการสมัครต่าง ๆ โดยเก็บ inbox เดียว
Dots ('user.name@gmail.com'): Gmail ถือว่าเป็นที่อยู่เดียวกัน (ละเว้น dots) แต่ผู้ให้บริการอื่นอาจถือว่าเป็นที่อยู่ต่างกัน อย่าพึ่งพา dot-equivalence นอก Gmail
ความยาว: RFC 5321 จำกัด local part ที่ 64 ตัวอักษรและที่อยู่ทั้งหมดที่ 254 ตัวอักษร เราเตือนเมื่อเกินขีดเหล่านี้ — เซิร์ฟเวอร์ส่วนใหญ่ปฏิเสธที่อยู่ที่ยาวกว่า
Case sensitivity: ตาม RFC local part คำนึงถึงตัวพิมพ์แต่ผู้ให้บริการส่วนใหญ่ถือว่าไม่คำนึงถึงตัวพิมพ์ Domain ไม่คำนึงถึงตัวพิมพ์เสมอ
คำถามที่พบบ่อย
›เครื่องมือนี้ยืนยันว่าอีเมลมีอยู่จริงหรือไม่?
ไม่ — เฉพาะ syntax เท่านั้น การยืนยันว่า inbox มีอยู่ต้องใช้การตรวจสอบ SMTP ฝั่งเซิร์ฟเวอร์หรือส่งอีเมลยืนยัน เครื่องมือนี้จับการพิมพ์ผิดในราคาถูก
›ทำไมถึงยอมรับ 'a@b.co'?
เพราะเป็น syntax ที่ถูกต้องทางเทคนิค TLD '.co' เป็นจริง (โคลอมเบีย) การตรวจสอบ syntax ไม่สามารถกรอง TLD ที่จริงแต่หายากได้
›แล้วอีเมลที่มี unicode (เช่น 用户@例え.jp) ล่ะ?
ที่อยู่อีเมล Internationalized ถูกต้องตาม RFC 6531 แต่ regex ที่ใช้ที่นี่ไม่รองรับ backend ฟอร์มส่วนใหญ่ก็ยังไม่รองรับเช่นกัน สำหรับการตรวจสอบที่รองรับ unicode ใช้ library เฉพาะ
›Plus tag คืออะไร?
ทุกอย่างระหว่าง + และ @ ถูก Gmail และผู้ให้บริการหลายรายถือเป็นส่วนหนึ่งของการ routing user+toolify@gmail.com ไปที่ user@gmail.com แต่คุณสามารถกรองด้วย suffix +toolify
›ทำไม Gmail ถึงละเว้น dots?
นโยบาย Gmail ในอดีต user.name@gmail.com และ username@gmail.com ส่งไปยัง inbox เดียวกัน ผู้ให้บริการอื่น (Yahoo, Outlook) ถือว่าเป็นที่อยู่ต่างกัน
›อีเมลที่ถูกต้องยาวสูงสุดเท่าไร?
254 ตัวอักษรรวมตาม RFC 5321 Local part ≤ 64 เซิร์ฟเวอร์ส่วนใหญ่ปฏิเสธที่ยาวกว่า
›ข้อมูลออกจากเบราว์เซอร์หรือไม่?
ไม่ การตรวจสอบทำงานในเครื่อง ไม่มีข้อมูลส่งไปยังเซิร์ฟเวอร์ใด ๆ
›ฉันตรวจสอบแบบ bulk ได้ไหม?
ไม่ในเครื่องมือนี้ — วางทีละหนึ่งที่อยู่ สำหรับรายการ ใช้ script หรือบริการตรวจสอบ bulk เฉพาะ (พร้อมความยินยอมสำหรับผู้ที่คุณตรวจสอบที่อยู่)
เครื่องมือที่เกี่ยวข้อง
อัปเดตล่าสุด: