วิธีส่งอีเมลจากแอปของคุณให้เข้ากล่องจดหมาย (Inbox)
หากต้องการส่งอีเมลจากแอปให้เชื่อถือได้ ให้ใช้ผู้ให้บริการส่งอีเมลแทนกล่องจดหมายส่วนตัว ส่งจากที่อยู่บนโดเมนของคุณเอง และเพิ่มเรคอร์ด DNS ที่ผู้ให้บริการกำหนดให้ เพื่อให้ SPF, DKIM และ DMARC ผ่านทั้งหมด แยกอีเมลธุรกรรม เช่น รีเซ็ตรหัสผ่าน ใบเสร็จ และการยืนยัน ออกจากอีเมลการตลาด ส่งแต่ละประเภทเฉพาะถึงคนที่คาดหวังจะได้รับ และจัดการกรณีอีเมลตีกลับ (bounce) และการยกเลิกการรับข่าวสาร การตั้งค่าการยืนยันตัวตนให้ถูกต้องเป็นสิ่งแรกที่ต้องทำ เพราะเป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้อีเมลของแอปไปอยู่ในสแปม
อีเมลธุรกรรมกับอีเมลการตลาด
อีเมลสองประเภทนี้หน้าตาในโค้ดคล้ายกัน แต่ผู้ให้บริการกล่องจดหมายและกฎหมายปฏิบัติต่อต่างกันมาก
| ธุรกรรม (Transactional) | การตลาด (Bulk) | |
|---|---|---|
| ถูกส่งเมื่อ | ผู้ใช้ทำบางอย่าง | ตารางหรือแคมเปญของคุณ |
| ตัวอย่าง | ยืนยันการสมัคร รีเซ็ตรหัสผ่าน magic link ใบเสร็จ การเตือนการจอง "มีคนตอบกลับ" | จดหมายข่าว ประกาศผลิตภัณฑ์ โปรโมชัน การกลับมาหาลูกค้าเก่า |
| ผู้รับ | ทีละคน | จำนวนมากพร้อมกัน |
| ความยินยอม | ถือว่ามีจากการกระทำ | ต้องได้รับอนุญาต พร้อมตัวเลือกยกเลิกที่ทำได้ง่าย |
| เวลา | ต้องถึงในไม่กี่วินาที | ไม่กี่นาทีก็ยอมรับได้ |
| ส่งจากที่ไหน | แอปของคุณผ่าน API | เครื่องมือจดหมายข่าวหรือฟีเจอร์ broadcast ของผู้ให้บริการ |
ควรแยกทั้งสองประเภทออกจากกัน หากแคมเปญการตลาดได้รับการร้องเรียนว่าเป็นสแปม คุณไม่อยากให้อีเมลรีเซ็ตรหัสผ่านที่ส่งจากช่องทางเดียวกันได้รับผลกระทบไปด้วย วิธีที่นิยมคือใช้ซับโดเมนแยก เช่น mail.example.com สำหรับอีเมลบัญชี และ news.example.com สำหรับจดหมายข่าว บางผู้ให้บริการแยกสองประเภทนี้ภายในให้อยู่แล้ว เช่น Postmark ระบุว่า message stream แบบ transactional และ broadcast ทำงานบนโครงสร้างพื้นฐานการส่งที่แยกจากกัน (ข้อมูลของกันยายน 2026)
เลือกผู้ให้บริการ
แอปของคุณไม่ควรส่งอีเมลเองจากเซิร์ฟเวอร์ของตัวเอง ผู้ให้บริการส่งอีเมลจะดูแลโครงสร้างพื้นฐาน ชื่อเสียงของ IP การลองส่งซ้ำ และการจัดการอีเมลตีกลับ ตัวเลือกที่รู้จักกันดี ได้แก่ Postmark, Resend, SendGrid, Amazon SES และ Mailgun แต่ละรายมี HTTP API และการเข้าถึงผ่าน SMTP ราคาและแพ็กเกจเปลี่ยนแปลงได้ จึงควรเปรียบเทียบจากเว็บไซต์ของแต่ละราย
สิ่งที่ควรเทียบกัน:
- จุดเน้น ผู้ให้บริการบางรายเน้นอีเมลธุรกรรม ส่วนบางรายรวมทั้งธุรกรรมและการตลาดไว้ด้วยกัน
- ประสบการณ์นักพัฒนา API ที่ชัดเจน ไลบรารีทางการสำหรับภาษาที่คุณใช้ และล็อกที่แสดงว่าแต่ละฉบับส่งถึง ตีกลับ หรือถูกทำเครื่องหมายเป็นสแปม
- Webhook สำหรับการตีกลับ การร้องเรียน และการส่งสำเร็จ เพื่อให้แอปตอบสนองได้
- เทมเพลต จัดเก็บที่ผู้ให้บริการ หรือในโค้ดของคุณเอง การเก็บในโค้ดทำให้มีเวอร์ชันและทดสอบได้
- ภูมิภาคและการจัดการข้อมูล หากคุณมีข้อกำหนดว่าข้อมูลประมวลผลที่ไหน
- ค่าใช้จ่ายตามปริมาณของคุณ รวมถึงสิ่งที่เกิดขึ้นเมื่อเกินโควตาฟรี
สำหรับจดหมายข่าวที่ส่งให้รายชื่อ เครื่องมือจดหมายข่าวหรือเครื่องมือการตลาดทางอีเมลโดยเฉพาะมักเหมาะกว่าการสร้างฟีเจอร์แคมเปญไว้ในแอปเอง
ตั้งค่าโดเมนที่ใช้ส่ง
ส่งจากโดเมนของคุณเอง เช่น hello@example.com ไม่ใช่ที่อยู่ Gmail หรือ Outlook อีเมลจากกล่องฟรีที่ส่งผ่านบริการภายนอกจะไม่ผ่านการตรวจสอบการยืนยันตัวตน และมีโอกาสถูกกรองสูง
พิจารณาใช้ซับโดเมนเฉพาะสำหรับการส่ง เช่น Resend แนะนำให้ส่งจากซับโดเมนอย่าง updates.example.com เพื่อแยกชื่อเสียงการส่งออกจากเว็บหลัก และยังทำให้เรคอร์ด DNS ของอีเมลแยกจากเว็บไซต์หลักด้วย (ข้อมูลของกันยายน 2026)
จากนั้นผู้ให้บริการจะให้เรคอร์ด DNS ให้คุณเพิ่มในที่ที่จัดการ DNS ของโดเมนของคุณ หากคุณยังไม่คุ้นกับ DNS โดเมนและ DNS ทำงานอย่างไร จะอธิบายเรคอร์ดให้ก่อน
SPF
SPF (Sender Policy Framework) คือเรคอร์ด TXT ที่ระบุว่าเซิร์ฟเวอร์ใดได้รับอนุญาตให้ส่งอีเมลในนามโดเมนของคุณ ผู้รับจะตรวจว่าเซิร์ฟเวอร์ที่ส่งอยู่ในรายการนั้นหรือไม่
- โดเมนควรมี เรคอร์ด SPF เพียงหนึ่งรายการ หากเพิ่มผู้ให้บริการ ให้รวมเข้ากับเรคอร์ดเดิม ไม่ใช่เพิ่มเรคอร์ดที่สอง
- SPF อนุญาตให้ค้นหา DNS ได้มากที่สุด 10 ครั้งขณะประเมินผล สายของ
include:ที่ยาวอาจเกินและทำให้ล้มเหลวได้ - ผู้ให้บริการหลายรายตั้งค่า SPF บนซับโดเมน return-path ที่ให้คุณสร้าง ดังนั้นคุณอาจไม่ต้องแตะเรคอร์ด SPF หลักเลย
DKIM
DKIM (DomainKeys Identified Mail) เพิ่มลายเซ็นเข้ารหัสลงในทุกฉบับ ผู้ให้บริการลงลายเซ็นด้วยคีย์ส่วนตัว และคุณเผยแพร่คีย์สาธารณะที่คู่กันเป็นเรคอร์ด DNS (TXT หรือ CNAME ขึ้นอยู่กับผู้ให้บริการ) ผู้รับจะตรวจลายเซ็นเพื่อยืนยันว่าอีเมลมาจากผู้ส่งที่ได้รับอนุญาต และไม่ถูกแก้ไขระหว่างทาง
ขั้นตอน "verify domain" ของผู้ให้บริการส่วนใหญ่เกี่ยวข้องกับ DKIM อย่าข้ามขั้นนี้
DMARC
DMARC เชื่อมสองอย่างแรกเข้าด้วยกัน เป็นเรคอร์ด TXT ที่ _dmarc.yourdomain.com ซึ่งบอกผู้รับว่า:
- การจับคู่ (alignment): โดเมนในที่อยู่ From ที่ผู้รับเห็นต้องตรงกับโดเมนที่ผ่าน SPF หรือ DKIM
- นโยบาย: ควรทำอย่างไรกับอีเมลที่ไม่ผ่าน ได้แก่
p=none(แค่รายงาน)p=quarantine(ถือว่าน่าสงสัย มักเข้าสแปม) หรือp=reject(ปฏิเสธ) - รายงาน: ส่งรายงานสรุปไปที่ไหน (
rua=) เพื่อให้คุณเห็นว่าใครส่งในนามโดเมนของคุณบ้าง
แนวทางที่เหมาะสมคือเริ่มด้วย p=none พร้อมที่อยู่สำหรับรับรายงาน ยืนยันว่าอีเมลที่ถูกต้องของคุณผ่าน แล้วค่อยขยับไป quarantine และในที่สุดคือ reject นโยบายที่เข้มงวดยังทำให้คนอื่นปลอมแปลงโดเมนของคุณได้ยากขึ้นมาก
Gmail ต้องการอะไรบ้าง
ตามแนวทางของผู้ส่งของ Google ณ กันยายน 2026:
- ผู้ส่งทุกราย ที่ส่งไปยังบัญชี Gmail ส่วนตัวต้องมี SPF หรือ DKIM มี forward DNS และ reverse DNS ที่ถูกต้องสำหรับเซิร์ฟเวอร์ที่ส่ง ใช้ TLS และอัตราสแปมใน Postmaster Tools ต่ำกว่า 0.3%
- ผู้ส่งจำนวนมาก (bulk sender) ที่ส่งเกิน 5,000 ฉบับต่อวันไปยัง Gmail ต้องมีทั้ง SPF และ DKIM มีเรคอร์ด DMARC (นโยบาย
p=noneใช้ได้) มีการจับคู่โดเมน From และมีการยกเลิกการรับข่าวสารแบบคลิกเดียว พร้อมลิงก์ยกเลิกที่มองเห็นได้ในอีเมลการตลาดและอีเมลที่ผู้ใช้สมัครรับ
ผู้ให้บริการจัดการส่วนฝั่งเซิร์ฟเวอร์ให้ เรคอร์ด DNS และการจัดการการยกเลิกการรับข่าวสารเป็นความรับผิดชอบของคุณ แม้ปริมาณจะไม่ถึง 5,000 ฉบับต่อวัน การทำตามกฎของผู้ส่งจำนวนมากก็เป็นวิธีที่ง่ายที่สุดในการปลอดภัย
สร้างการส่งอีเมลเข้าไปในแอป
เมื่อยืนยันโดเมนแล้ว:
- เก็บ API key เป็นความลับฝั่งเซิร์ฟเวอร์ ห้ามใส่ในโค้ดฝั่งหน้าบ้าน ดู ตัวแปรสภาพแวดล้อมและความลับคืออะไร
- ส่งจากเซิร์ฟเวอร์ หลังจากการกระทำที่ทำให้เกิดอีเมลสำเร็จแล้ว
- อย่าให้ผู้ใช้รออีเมล สำหรับแอปที่ซับซ้อนกว่าระดับพื้นฐาน ให้เข้าคิวการส่งและลองส่งซ้ำเมื่อเกิดความล้มเหลวชั่วคราว เพื่อไม่ให้การตอบสนองที่ช้าของผู้ให้บริการทำให้การสมัครช้าลง
- บันทึกผลลัพธ์ เช่น message ID และสถานะจากผู้ให้บริการ โดยไม่บันทึกคีย์หรือเนื้อหาข้อความทั้งฉบับที่มีข้อมูลส่วนบุคคล
- จัดการ webhook สำหรับการตีกลับและการร้องเรียน หยุดส่งไปยังที่อยู่ที่ตีกลับอย่างถาวรหรือที่ทำเครื่องหมายว่าเป็นสแปม
ตัวอย่างพรอมต์ที่ครอบคลุมพื้นฐาน:
ส่งอีเมลธุรกรรมด้วย [PROVIDER] โดยใช้ความลับฝั่งเซิร์ฟเวอร์ [ENV_NAME] จากที่อยู่ "Acme hello@mail.acme.com" ส่งอีเมลต้อนรับหลังการสมัคร และอีเมลยืนยันการจองหลังจากบันทึกการจองแล้ว เก็บเทมเพลตไว้ในโค้ด พร้อมเวอร์ชันข้อความธรรมดาควบคู่กับ HTML เข้าคิวการส่งและลองส่งซ้ำสูงสุดสามครั้งเมื่อเกิดความล้มเหลวชั่วคราว บันทึกข้อผิดพลาดจากผู้ให้บริการแต่ห้ามบันทึก API key เพิ่ม endpoint ของ webhook ที่ทำเครื่องหมายที่อยู่ที่ส่งไม่ได้เมื่อตีกลับอย่างถาวรหรือมีการร้องเรียน และข้ามที่อยู่เหล่านั้นในการส่งครั้งต่อไป
อีเมลบัญชี เช่น ลิงก์ยืนยัน magic link และการรีเซ็ตรหัสผ่าน เป็นส่วนหนึ่งของการเข้าสู่ระบบ วิธีเพิ่มการเข้าสู่ระบบในแอปของคุณ อธิบายว่าขั้นตอนเหล่านี้เข้ากันอย่างไร ควรทำให้ลิงก์เหล่านี้ใช้ได้ครั้งเดียวและมีอายุสั้น
นิสัยที่ช่วยให้อีเมลถึงกล่องจดหมาย
การยืนยันตัวตนช่วยให้อีเมลได้รับการพิจารณา พฤติกรรมของคุณเป็นสิ่งที่ทำให้อีเมลอยู่ในกล่องจดหมาย
- ส่งเฉพาะสิ่งที่คนคาดหวัง การสมัครที่ยืนยันแล้ว การยินยอมที่ชัดเจนสำหรับอีเมลการตลาด และห้ามซื้อรายชื่อ
- ทำให้การยกเลิกการรับข่าวสารทำได้ง่าย สำหรับทุกอย่างที่ไม่ใช่ธุรกรรมโดยเคร่งครัด และเคารพการยกเลิกทันที
- อุ่นโดเมนใหม่ (warm up) โดเมนที่เพิ่งสร้างและส่งหลายพันฉบับในวันแรกดูน่าสงสัย เริ่มจากอีเมลธุรกรรมแล้วเพิ่มปริมาณอย่างค่อยเป็นค่อยไป
- รักษารายชื่อให้สะอาด ลบการตีกลับถาวรทันที และพิจารณาลบคนที่ไม่เปิดอีเมลใดเลยเป็นเวลานาน
- เขียนให้เหมือนคนเขียน หัวข้อที่ชัดเจน ชื่อผู้ส่งที่จำได้ ส่วนข้อความธรรมดา รูปภาพไม่มาก และลิงก์ไปยังโดเมนของคุณเอง หลีกเลี่ยงตัวย่อลิงก์
- ติดตาม ลงทะเบียนโดเมนใน Google Postmaster Tools และอ่านรายงาน DMARC เป็นครั้งคราว
- ใช้ reply-to ที่มีคนอ่านจริง การตอบกลับเป็นสัญญาณที่ดี และเป็นความคิดเห็นที่มีประโยชน์
ทดสอบโดยไม่ส่งสแปมให้ใคร
- ใช้ โหมดทดสอบหรือ sandbox ของผู้ให้บริการ หากมี หรือส่งไปยังที่อยู่ที่คุณเป็นเจ้าของ
- ตอนพัฒนา ให้ส่งไปยังกล่องทดสอบ catch-all แทนผู้ใช้จริง ฐานข้อมูลตัวอย่างที่เต็มไปด้วยที่อยู่ที่ดูเหมือนจริงเป็นวิธีง่าย ๆ ที่จะส่งอีเมลถึงคนแปลกหน้าโดยไม่ตั้งใจ
- ตรวจแต่ละเทมเพลตในหลายไคลเอนต์ เช่น Gmail บนเว็บ แอปเมลบนมือถือ Outlook และโหมดมืด
- ดู header ของอีเมลทดสอบ จะแสดงว่า SPF, DKIM และ DMARC ผ่านหรือไม่
ข้อกฎหมายพื้นฐาน
กฎแตกต่างกันตามประเทศ โดยทั่วไป อีเมลการตลาดต้องได้รับความยินยอมในหลายที่ ต้องระบุผู้ส่งให้ชัด และต้องมีการยกเลิกการรับข่าวสารที่ใช้งานได้ ส่วนอีเมลธุรกรรมถูกปฏิบัติต่างกัน แต่ไม่ควรนำไปใช้สอดแทรกเนื้อหาการตลาด หากคุณเก็บที่อยู่จาก หน้า waitlist ให้บอกว่าจะส่งอะไร เก็บอะไร เมื่อไหร่ และอย่างไรที่แต่ละคนลงทะเบียน หากไม่แน่ใจ ให้ตรวจกฎในพื้นที่ที่ผู้ใช้ของคุณอยู่
เช็กลิสต์อีเมล
- เลือกผู้ให้บริการส่งอีเมลแล้ว และเก็บ API key เป็นความลับฝั่งเซิร์ฟเวอร์
- ส่งจากโดเมนหรือซับโดเมนของคุณเอง ไม่ใช่กล่องอีเมลฟรี
- เพิ่มเรคอร์ด SPF, DKIM และ DMARC และผ่านการตรวจสอบ
- แยกอีเมลธุรกรรมออกจากอีเมลการตลาด
- เข้าคิวการส่งและลองส่งซ้ำ พร้อมบันทึกผลลัพธ์
- จัดการ webhook สำหรับการตีกลับและการร้องเรียน
- มีตัวเลือกยกเลิกการรับข่าวสารในอีเมลที่ไม่ใช่ธุรกรรม และเคารพทันที
- ทดสอบเทมเพลตในหลายไคลเอนต์ และอีเมลทดสอบไม่ไปถึงผู้ใช้จริง
การส่งอีเมลจากแอป Mythex
Mythex ไม่มีบริการส่งอีเมลในตัวสำหรับแอปที่คุณสร้าง คุณจึงต้องนำผู้ให้บริการเอง เช่น Resend, SendGrid หรือ Postmark เก็บ API key ของผู้ให้บริการเป็นความลับของโปรเจกต์ เอเจนต์สามารถขอได้ด้วยการ์ดความลับในแชท และคุณบอกอีเมลที่ต้องการด้วยภาษาธรรมดาได้เลย เอกสารมีพรอมต์เริ่มต้นใน ส่งอีเมลจากแอปของคุณ หากคุณซื้อโดเมนผ่าน Mythex ในแพ็ก Pro คุณสามารถเพิ่มเรคอร์ด TXT และ CNAME ของผู้ให้บริการในการตั้งค่า DNS ของโดเมนได้ ดู โดเมนที่กำหนดเอง
คำถาม
อีเมลธุรกรรมต่างจากอีเมลการตลาดอย่างไร
อีเมลธุรกรรมถูกส่งเมื่อผู้ใช้ทำบางอย่างและคาดว่าจะได้รับ เช่น รีเซ็ตรหัสผ่าน ใบเสร็จ หรือยืนยันการจอง ส่วนอีเมลการตลาดถูกส่งถึงคนจำนวนมากตามตารางของคุณ เช่น จดหมายข่าวและประกาศ สองประเภทนี้มีกฎเรื่องความยินยอมต่างกัน และควรส่งจากช่องทาง (stream) หรือซับโดเมนแยกกัน
ทำไมอีเมลของแอปถึงไปอยู่ในสแปม
สาเหตุที่พบบ่อยคือโดเมนที่ส่งยังไม่ได้ตั้งค่า SPF, DKIM และ DMARC การส่งจากที่อยู่อีเมลฟรีอย่าง Gmail ผ่านบริการภายนอก โดเมนใหม่ที่ยังไม่มีชื่อเสียง หรือเนื้อหาและลิงก์ที่ดูเหมือนสแปม ควรแก้เรื่องการยืนยันตัวตนก่อน แล้วค่อยดูเนื้อหาและปริมาณ
ส่งอีเมลของแอปจากบัญชี Gmail ของฉันได้ไหม
อาจได้สำหรับการทดสอบข้อความส่วนตัวไม่กี่ฉบับ แต่ไม่เหมาะกับแอปจริง ควรใช้ผู้ให้บริการส่งอีเมลที่มีโดเมนของคุณเอง ตั้งค่าเรคอร์ด DNS ที่เขาให้ แล้วส่งจากที่อยู่อีเมลในโดเมนนั้น
ฉันต้องมี DMARC ไหม
ในทางปฏิบัติแล้วควรมี ตามข้อมูลของกันยายน 2026 Google ต้องการ DMARC สำหรับผู้ส่งที่ส่งเกิน 5,000 ฉบับต่อวันไปยังที่อยู่ Gmail และเรคอร์ด DMARC ยังช่วยป้องกันไม่ให้มีการปลอมแปลงโดเมนของคุณด้วย การเริ่มด้วยนโยบาย p=none ก็ใช้ได้ในขณะที่คุณตรวจรายงาน