ส่งอีเมลจากเว็บแล้วเข้า Junk ทุกที? ปัญหาไม่ได้อยู่ที่เนื้อหา แต่อยู่ที่ DNS (SPF/DKIM/DMARC)

เคยไหม? ส่งใบเสนอราคาให้ลูกค้า แล้วลูกค้าบอก "ไม่เห็นได้รับเลยพี่"

เรื่องนี้ผมเจอกับลูกค้าตัวเองบ่อยมากครับ — ทั้งคนทำเว็บ ทั้งเจ้าของกิจการ SME

สถานการณ์มันเป็นแบบนี้: คุณกดส่งใบเสนอราคาจากอีเมลบริษัท sales@yourdomain.com ไปแล้ว ระบบขึ้นว่า "ส่งสำเร็จ" หน้าจอไม่มี error อะไรเลย คุณก็สบายใจ รอลูกค้าตอบกลับ

ผ่านไปสองวัน... เงียบ

คุณโทรไปถาม ลูกค้าบอกว่า "อ้าว ไม่เห็นได้รับเลยพี่ ลองส่งใหม่ได้ไหม"

พอให้ลูกค้าไปเปิดดูในถัง Junk / Spam เท่านั้นแหละ — เจอ เมลคุณนอนนิ่งอยู่ในนั้นมาตั้งแต่วันแรก ลูกค้าไม่เคยเห็น เพราะไม่มีใครนั่งเปิดถังขยะเมลทุกวัน

บางเคสหนักกว่านั้น คือเมลไม่ได้แค่ตกถัง Junk แต่ เด้งกลับ (bounce) เลย — คุณได้เมลจากระบบ "Mail Delivery Failed" หรือ "Message rejected" กลับมา แปลว่าปลายทางปฏิเสธไม่รับตั้งแต่ประตู

ลองคิดดูครับว่ามันเสียอะไรบ้าง:

• เสียดีล — ใบเสนอราคาที่ลูกค้าไม่เคยเห็น = เหมือนไม่ได้ส่ง คู่แข่งที่เมลถึงก่อนได้งานไป
• เสียความน่าเชื่อถือ — ลูกค้าคิดว่าบริษัทคุณ "ไม่ตอบ" ทั้งที่คุณตอบไปแล้ว
• เสียเวลา — ตามงานซ้ำ ส่งซ้ำ โทรยืนยัน ทุกครั้งที่ส่งเมลกลายเป็นเรื่องต้องลุ้น

และที่แย่ที่สุดคือ คุณไม่รู้ตัวด้วยซ้ำว่ามันเกิดขึ้น เพราะหน้าจอฝั่งคุณขึ้นว่า "ส่งสำเร็จ" เสมอ

ผมชื่ออ๊อดครับ เป็นนักพัฒนา เขียนโค้ดทำเว็บมา 20 ปี ทำ PhalconHost มา 11 ปี ดูแลเว็บลูกค้ารวมกันกว่า 5,000 เว็บ และ VPS อีกราว 600 เครื่อง — เรื่องเมลเข้า Spam นี้ลูกค้าผมถามบ่อยที่สุดเรื่องหนึ่ง และเกือบทุกคนมาด้วย "ความเข้าใจผิด" เดียวกันเป๊ะ บทความนี้ผมจะเฉลยว่าปัญหาจริงอยู่ตรงไหน แล้วพาตั้งให้ถูกจนเมลเข้า Inbox — ย้ำก่อนว่านี่เป็นเนื้อหา ตั้งค่าและดูแลเมลของเว็บคุณเอง ไม่มีสอนยุ่งกับเมลใครทั้งสิ้น

ขอเปิดด้วยประโยคที่อยากให้จำไปทั้งบทความเลยครับ:

"เมลส่งสำเร็จ" กับ "เมลถึง Inbox ลูกค้า" เป็นคนละเรื่องกัน — และเส้นแบ่งของมันไม่ได้อยู่ที่เนื้อหาเมล แต่อยู่ที่ "โดเมนคุณยืนยันตัวตนผู้ส่งที่ DNS ได้ไหม"

ความเข้าใจผิดที่ทำให้แก้ไม่หายสักที (มุม (ความเข้าใจผิด))

ตรงนี้คือหัวใจของบทความนี้เลยครับ และเป็นจุดที่ผมเห็นคนทำเว็บพลาดกันเยอะที่สุด

พอเมลเข้า Spam คนส่วนใหญ่จะเดาว่า "ปัญหาน่าจะอยู่ที่เนื้อหาเมล" — แล้วก็ไปนั่งแก้คำ เลี่ยงคำว่า "ฟรี" "โปรโมชั่น" ลดจำนวนลิงก์ ลดรูป เปลี่ยน subject สิบรอบ หรือไม่ก็ไปโทษ ปลั๊กอิน ใน WordPress ลองสลับปลั๊กอินส่งเมลไปมา 3-4 ตัว

แก้ไปแก้มา เมลก็ยังเข้า Spam อยู่ดี เพราะ...

ปัญหาจริงส่วนใหญ่ไม่ได้อยู่ที่เนื้อหาเมล และไม่ได้อยู่ที่ปลั๊กอิน — แต่อยู่ที่คุณ "ไม่ได้ยืนยันตัวตนผู้ส่งที่ DNS" ปลายทางเลยมองว่าเมลของคุณน่าจะเป็นของปลอม (spoof)

ลองนึกภาพแบบนี้ครับ: เมลก็เหมือนซองจดหมายที่หน้าซองเขียนว่า "ส่งจาก yourdomain.com" — แต่ใครก็เขียนหน้าซองแบบนี้ได้ทั้งนั้น มิจฉาชีพปลอมชื่อผู้ส่ง (spoofing) กันทุกวัน

เพราะฉะนั้น ระบบเมลปลายทาง (Gmail, Outlook, เมลบริษัทลูกค้า) มันเลยมีกลไกถามกลับว่า "เมลที่อ้างว่ามาจาก yourdomain.com เนี่ย โดเมนนั้นยืนยันไหมว่าส่งมาจากเซิร์ฟเวอร์นี้จริง?"

ถ้าโดเมนคุณ ยืนยันได้ (มี SPF/DKIM/DMARC ครบ) → ปลายทางเชื่อ → เข้า Inbox ถ้าโดเมนคุณ ยืนยันไม่ได้ (ไม่มี หรือตั้งผิด) → ปลายทางสงสัย → โยนลงถัง Spam หรือเด้งทิ้ง

นี่คือเหตุผลว่าทำไม "การแก้เนื้อหาเมล" ถึงไม่เคยแก้ปัญหานี้ได้จริง — เพราะมันแก้ผิดจุด เหมือนเว็บล่มเพราะ DNS แต่ไปนั่งแก้ธีม

แล้วทำไม "เมื่อก่อนก็ยังพอผ่าน เดี๋ยวนี้ทำไมหนักขึ้น" — เพราะเส้นมันถูกยกสูงขึ้น

ตรงนี้ผมอยากเพิ่มมุมที่หลายคนไม่ทันสังเกตครับ — บางคนทักมาบอกว่า "พี่ เมื่อก่อนผมก็ส่งแบบนี้แหละ ไม่เห็นต้องตั้งอะไรเลย มันก็เข้า Inbox ปกติ ทำไมพักหลังเริ่มตกถัง Junk บ่อยขึ้น?"

คำตอบคือ โลกของเมลมันขยับเส้นมาตรฐานสูงขึ้นกว่าเดิมมาก ช่วงประมาณปี 2024 เป็นต้นมา ผู้ให้บริการเมลรายใหญ่ของโลก — ทั้งฝั่ง Gmail (Google) และ Outlook/Hotmail (Microsoft) — ประกาศบังคับเรื่อง authentication เข้มขึ้น โดยเฉพาะกับ "คนที่ส่งเมลปริมาณมาก": แทนที่จะ "มีอันใดอันหนึ่งก็พอ" กลายเป็นต้อง มี SPF และ DKIM และ DMARC ครบ ถึงจะผ่านสบาย และยังเช็กไปถึง rDNS/PTR ของ IP ผู้ส่งด้วย (เดี๋ยวเล่าเรื่อง rDNS ในหัวข้อท้ายๆ)

⚠️ อย่าเพิ่งคิดว่า "ฉันส่งไม่เยอะ ไม่เกี่ยว" — ต่อให้คุณยังไม่เข้าเกณฑ์ "ผู้ส่งปริมาณมาก" สิ่งที่เกิดขึ้นคือ มาตรฐานทั้งระบบมันยกตัวขึ้นทั้งแผง ปลายทางคุ้นกับการเห็นเมลที่ authentication ครบจนกลายเป็น "ปกติใหม่" เมลที่ไม่มี SPF/DKIM/DMARC เลยยิ่งดูผิดปกติและน่าสงสัยกว่าเดิม นี่แหละเหตุผลที่ "วิธีเดิม (นั่งแก้เนื้อหา)" ยิ่งวันยิ่งใช้ไม่ได้ — เพราะคุณพยายามแก้ตัวแปรที่ไม่ใช่ตัวที่ปลายทางให้น้ำหนัก

จับแก่นง่ายๆ ครับ: เมื่อก่อน authentication เป็น "ของมีก็ดี" — เดี๋ยวนี้มันคือ "ของต้องมี" ใครยังไม่ตั้งคือกำลังว่ายทวนน้ำที่แรงขึ้นเรื่อยๆ

3 เหตุผลหลักที่ทำให้เมลเข้า Spam (เรียงตามที่เจอบ่อย)

1. ไม่มี Authentication = ดูเหมือนเมลปลอม ← ตัวการอันดับหนึ่ง โดเมนไม่มี SPF/DKIM/DMARC ปลายทางพิสูจน์ตัวตนผู้ส่งไม่ได้ เลยตีว่าน่าสงสัย อันนี้แก้ได้ด้วยตัวเองและให้ผลชัดที่สุด

2. IP reputation ของเซิร์ฟเวอร์ที่ส่งไม่ดี ทุก IP ที่ส่งเมลมี "ประวัติ" ถ้า IP นั้นเคยถูกใช้ส่ง Spam หรือติด blacklist (เช่น Spamhaus) เมลที่ออกจาก IP นั้นจะโดนกรองหนักขึ้น — เรื่องนี้สำคัญมากกับ Shared Hosting (เดี๋ยวเล่าต่อด้านล่าง)

3. เนื้อหา/ลิงก์น่าสงสัย อันนี้ "มีผลจริง แต่เป็นปัจจัยรอง" — เมลที่มีแต่รูปไม่มีข้อความ, ลิงก์ย่อ (bit.ly) เยอะ, ไฟล์แนบแปลกๆ, หรือ HTML รกๆ ก็ทำให้คะแนนตก แต่ถ้า authentication ครบ เนื้อหาปกติทั่วไปก็ผ่านสบาย

สังเกตว่า 2 ใน 3 ข้อแรกไม่เกี่ยวกับเนื้อหาเมลเลย — มันคือเรื่อง DNS และเซิร์ฟเวอร์ ล้วนๆ นี่แหละครับงานของคนที่เข้าใจหลังบ้านจริงๆ

ทีนี้มาลงรายละเอียดวิธีแก้ทีละตัว ผมจะอธิบายให้เข้าใจว่าแต่ละตัวทำหน้าที่อะไร และตั้งยังไงให้ถูก

SPF — บอกว่า "เซิร์ฟเวอร์ไหนมีสิทธิ์ส่งเมลแทนโดเมนเรา"

SPF (Sender Policy Framework) คือ TXT record ที่คุณประกาศไว้บน DNS ว่า "เมลที่อ้างว่ามาจากโดเมนฉัน จะส่งออกมาจากเซิร์ฟเวอร์เหล่านี้เท่านั้น" ปลายทางเอา IP ผู้ส่งจริงมาเทียบกับลิสต์นี้ ถ้าตรง = ผ่าน SPF

ตัวอย่าง SPF record ที่ใช้ได้จริง (วางเป็น TXT record ที่ host @ หรือชื่อโดเมน):

v=spf1 a mx include:_spf.phalconhost.com ~all

อ่านทีละส่วน:

• v=spf1 — บอกว่านี่คือ SPF เวอร์ชัน 1 (ต้องขึ้นต้นแบบนี้เสมอ)
• a — อนุญาต IP ของ A record โดเมนนี้
• mx — อนุญาต IP ของเซิร์ฟเวอร์เมล (MX) ของโดเมนนี้
• include:_spf.phalconhost.com — รวมเซิร์ฟเวอร์ของผู้ให้บริการ (อันนี้เป็นตัวอย่าง — ของจริงให้ใช้ค่าที่ผู้ให้บริการกำหนด เช่นถ้าส่งผ่าน Google Workspace ก็ include:_spf.google.com)
• ~all — ปิดท้ายว่า "นอกจากที่ระบุข้างบน ให้ถือว่า softfail (น่าสงสัยแต่ยังไม่ปฏิเสธ)" — แนะนำใช้ ~all ช่วงแรก ส่วน -all (hardfail = ปฏิเสธเด็ดขาด) ค่อยใช้เมื่อมั่นใจว่าลิสต์ครบแล้วจริงๆ

⚠️ กับดักที่เจอบ่อยที่สุดของ SPF: ห้ามมีหลายอัน! หนึ่งโดเมน ต้องมี SPF record เดียวเท่านั้น ถ้ามี TXT ขึ้นต้น v=spf1 มากกว่า 1 บรรทัด มาตรฐานถือว่า ผิดทั้งคู่ (PermError) = เหมือนไม่มี SPF เลย เคสนี้เกิดบ่อยมากตอนใช้หลายบริการ เช่น มี SPF ของโฮสต์อยู่แล้ว แล้วไปสมัครส่งเมลผ่านบริการอื่น มันให้ SPF มาอีกอัน คุณก็เอาไปวางเพิ่มอีกบรรทัด → พังทันที วิธีแก้ที่ถูก: รวมเป็นบรรทัดเดียว เอา include: ของทุกบริการมาต่อกัน เช่น v=spf1 a mx include:_spf.phalconhost.com include:_spf.google.com ~all

DKIM — ลายเซ็นดิจิทัลที่พิสูจน์ว่าเมล "ไม่ถูกแก้ระหว่างทาง" และมาจากเราจริง

DKIM (DomainKeys Identified Mail) คือการเซ็นลายเซ็นดิจิทัลลงในเมลทุกฉบับที่ส่งออก เซิร์ฟเวอร์ของคุณถือ private key (กุญแจส่วนตัว) ไว้เซ็น ส่วน public key (กุญแจสาธารณะ) ถูกเผยแพร่เป็น TXT record บน DNS ปลายทางดึง public key มาตรวจลายเซ็น ถ้าตรง = ยืนยันได้ว่าเมลนี้มาจากโดเมนคุณจริง และเนื้อหาไม่ถูกดัดแปลงระหว่างทาง

DKIM record จะอยู่ในรูป selector._domainkey.yourdomain.com ตัวอย่างหน้าตาแบบนี้ (host: default._domainkey):

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...(public key ยาวๆ)...IDAQAB

ข่าวดีคือ ถ้าคุณใช้โฮสต์ที่เป็น DirectAdmin + Exim (ซึ่งเป็นมาตรฐานของโฮสต์ไทยจำนวนมาก รวมถึงที่ PhalconHost) ระบบมันสร้าง DKIM key ให้อัตโนมัติ เวลาสร้างโดเมน คุณแค่ต้องเช็กให้แน่ใจว่ามันเปิดอยู่ และ public key ถูกใส่ลงใน DNS zone จริง (ดูวิธีเช็กในหัวข้อ DirectAdmin ด้านล่าง)

DMARC — นโยบายว่า "ถ้า SPF/DKIM ไม่ผ่าน ให้ทำยังไง" + ส่งรายงานกลับ

DMARC (Domain-based Message Authentication, Reporting & Conformance) คือตัวที่ผูกทุกอย่างเข้าด้วยกัน มันบอกปลายทางว่า "ถ้าเมลที่อ้างว่ามาจากโดเมนฉัน สอบ SPF และ DKIM ไม่ผ่าน ให้จัดการยังไง" และยังสั่งให้ปลายทาง ส่งรายงานกลับมา ให้คุณรู้ว่ามีใครส่งเมลในนามโดเมนคุณบ้าง

DMARC วางเป็น TXT record ที่ host _dmarc ตัวอย่างเริ่มต้นที่ปลอดภัย:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100; aspf=r; adkim=r

อ่านส่วนสำคัญ:

• p=none — นโยบาย "ยังไม่ทำอะไร แค่เฝ้าดูและส่งรายงาน" ← เริ่มจากตรงนี้เสมอ
• rua=mailto:dmarc@yourdomain.com — ที่อยู่รับรายงานสรุป (อยากรู้ว่าใครส่งในนามเราบ้าง ดูที่นี่)
• pct=100 — ใช้นโยบายกับเมล 100% (ตอนขยับเป็น quarantine ค่อยลด % ลงเพื่อทยอยทดสอบได้)

ลำดับการไล่ DMARC ที่ถูกต้อง (อย่ากระโดด):

1. p=none — เปิดไว้เก็บรายงานก่อน 1-2 สัปดาห์ ดูว่า SPF/DKIM ของเราผ่านครบไหม มีเซิร์ฟเวอร์ที่ถูกลืมหรือเปล่า — ขั้นนี้สำคัญมาก ห้ามข้าม เพราะถ้ายังตั้ง SPF/DKIM ไม่ครบแล้วรีบสั่งบล็อก เมลที่ถูกต้องของคุณเองจะหายไปด้วย
2. p=quarantine — เมื่อมั่นใจว่าเมลจริงผ่านหมดแล้ว ขยับเป็น quarantine = เมลที่ไม่ผ่านให้เข้า Spam
3. p=reject — ขั้นสุดท้าย เมลที่ไม่ผ่านให้ปฏิเสธทิ้งเลย = ป้องกัน spoofing เต็มรูปแบบ (เหมาะกับโดเมนบริษัทที่ serious เรื่องแบรนด์)

🔎 ลำดับนี้ไม่ใช่แค่ผมคิดเองนะครับ — มันคือวิธีที่มาตรฐานทั้งวงการแนะนำตรงกัน: องค์กรกลางที่ดูแลมาตรฐาน DMARC โดยตรง (dmarc.org) ก็วางขั้นตอนการ deploy ไว้แบบเดียวกันเป๊ะ คือ "ตั้ง SPF/DKIM ให้ครบ → เช็ก alignment → เริ่มที่ p=none เก็บรายงาน → วิเคราะห์ → แล้วค่อยๆ ขยับไป quarantine แล้วค่อย reject" และฝั่งผู้ให้บริการเมลรายใหญ่ (Gmail/Outlook) ก็ยอมรับให้ตั้ง p=none ได้ในตอนแรก ขอแค่ "มี record" ส่วนบทความ Knowledge Base ของ security engineer ไทยหลายเจ้าก็อธิบายลำดับ none → quarantine → reject เหมือนกัน · พูดง่ายๆ คือสิ่งที่ผมกำลังเล่า ไม่ใช่ "สไตล์ PhalconHost" แต่เป็นวิธีที่คนทั้งโลกยึดเหมือนกันหมด — คนที่กระโดดข้าม p=none ไป reject เลยต่างหากที่ทำผิดทาง แล้วเมลตัวเองหาย

เพิ่มอีกชั้นที่ v1 ยังไม่ได้ขยาย: เรื่อง "alignment" (ทำไม SPF/DKIM ผ่านแล้ว DMARC ยัง fail ได้)

สังเกตในตัวอย่าง DMARC ข้างบนไหมครับว่ามี aspf=r กับ adkim=r — หลายคนก๊อปไปวางแต่ไม่รู้ว่ามันคืออะไร ตรงนี้ผมขอขยายให้ชัด เพราะมันคือสาเหตุของเคสที่ "ปวดหัวที่สุด" เคสหนึ่ง:

เคสที่เจอบ่อย: เช็ก SPF ก็ผ่าน เช็ก DKIM ก็ผ่าน แต่ DMARC ดันแสดงว่า fail — ทำไม?

คำตอบคือคำว่า alignment (การจัดแนวให้ตรงโดเมน) ครับ DMARC ไม่ได้ดูแค่ว่า "SPF/DKIM ผ่านไหม" แต่ดูต่อว่า โดเมนที่ผ่าน SPF/DKIM นั้น "ตรงกับโดเมนที่อยู่ในช่อง From: ที่ลูกค้าเห็น" หรือเปล่า — เพราะมิจฉาชีพอาจส่งเมลที่ SPF ผ่านในนามโดเมนของมันเอง แต่ปลอมช่อง From: เป็นชื่อแบรนด์คุณ DMARC เลยบังคับว่า "โดเมนที่ยืนยันได้ ต้องตรงกับโดเมนที่แสดงให้คนเห็นด้วย"

• aspf / adkim = r (relaxed) — ยอมให้ตรงกันแบบ "โดเมนหลักเดียวกันก็พอ" (เช่น mail.yourdomain.com กับ yourdomain.com ถือว่า align กัน) — แนะนำใช้ค่านี้ตอนเริ่ม เพราะยืดหยุ่นกว่า
• aspf / adkim = s (strict) — ต้องตรงเป๊ะทั้งโดเมน ไม่ยอมให้ subdomain ต่างกัน — เข้มกว่า แต่ถ้าตั้งทั้งที่ระบบส่งจริงใช้ subdomain อยู่ เมลตัวเองจะ fail DMARC แม้ SPF/DKIM ผ่าน

ทำไมเรื่องนี้สำคัญขึ้นเรื่อยๆ? เพราะตอนนี้ฝั่ง Gmail เองก็ระบุชัดว่า สำหรับเมลที่ส่งตรง "โดเมนในช่อง From: ต้อง align กับโดเมนของ SPF หรือ DKIM อย่างใดอย่างหนึ่ง" — แปลว่า alignment ไม่ใช่ของแถม มันคือเงื่อนไขผ่าน/ไม่ผ่านจริงๆ จุดที่คนพลาดบ่อยคือ ไปส่งเมลผ่านบริการภายนอก (เช่น ระบบส่งจดหมายข่าว, ระบบ CRM) ที่ SPF/DKIM ผ่านในนามโดเมน ของบริการนั้น แต่ช่อง From: ใช้โดเมนคุณ → SPF/DKIM เขียวสวยทั้งคู่ แต่ DMARC fail เพราะไม่ align → เมลตก Junk แบบงงๆ

จับแก่น: ถ้าวันไหนเจอ "SPF ผ่าน DKIM ผ่าน แต่ DMARC fail" — อย่าไปไล่แก้ SPF/DKIM ซ้ำ ให้มาดูที่ alignment ว่า โดเมนใน From: ตรงกับโดเมนที่ยืนยันได้จริงไหม (รายงาน DMARC rua ที่ตั้งไว้จะช่วยชี้จุดนี้ให้)

rDNS / PTR — IP ต้องชี้กลับเป็นชื่อโดเมนได้ (อันนี้ผู้ให้บริการตั้งให้)

อีกตัวที่คนทำเว็บมักไม่รู้ว่ามีอยู่ คือ rDNS (Reverse DNS) หรือ PTR record — มันคือการที่ IP ของเซิร์ฟเวอร์ส่งเมล "ชี้กลับ" ไปเป็นชื่อ hostname ที่ถูกต้อง (เช่น IP 1.2.3.4 → mail.yourdomain.com)

ทำไมสำคัญ? เพราะเซิร์ฟเวอร์เมลที่น่าเชื่อถือ "ต้องมี" rDNS ที่ตรงกัน Gmail/Outlook เช็กข้อนี้ด้วย (ทั้งสองเจ้าระบุชัดว่าผู้ส่งต้องมี forward และ reverse DNS ที่ถูกต้อง) ถ้า IP ส่งเมลไม่มี rDNS หรือ rDNS ชี้ไปมั่วๆ (เช่นชี้เป็น hostname ของ ISP แบบ generic) เมลจะโดนกรองหนักขึ้นทันที

จุดสำคัญคือ rDNS/PTR คุณตั้งเองจากฝั่ง DNS ทั่วไปไม่ได้ — มันต้องตั้งจากฝั่งเจ้าของ IP คือ ผู้ให้บริการโฮสต์/เซิร์ฟเวอร์ เพราะฉะนั้นถ้าคุณใช้ VPS หรือ Dedicated แล้วเมลเข้า Spam ทั้งๆ ที่ SPF/DKIM/DMARC ครบ — ให้เช็กกับผู้ให้บริการว่าตั้ง rDNS ให้หรือยัง อันนี้คือจุดที่ "โฮสต์ที่เข้าใจ" กับ "โฮสต์ที่บอกว่าไม่ใช่หน้าที่" ต่างกันชัดมาก (เก็บประเด็นนี้ไว้นะครับ เพราะมันคือหัวใจของหัวข้อ "ก็โฮสต์ตั้งให้แล้วนี่" ข้างล่าง)

เช็ก/เปิดทุกอย่างใน DirectAdmin (ทำตามได้เลย)

ถ้าโฮสต์คุณเป็น DirectAdmin (ส่วนใหญ่ในไทยใช้ตัวนี้) นี่คือจุดที่ต้องเข้าไปดู:

• DNS Management (เมนู DNS Management / DNS Control) — ที่นี่คือที่คุณดูและแก้ TXT records ทั้งหมด: SPF, DKIM, DMARC ลองหา record ที่ขึ้นต้น v=spf1, ตัว _domainkey, และ _dmarc ว่ามีครบไหม
• DKIM — ใน DirectAdmin รุ่นใหม่ DKIM จะถูกสร้างอัตโนมัติตอนสร้างโดเมน ให้เช็กว่ามี TXT record x._domainkey อยู่ใน zone (ถ้าไม่มี อาจต้องให้ admin รัน enable DKIM ให้) — ค่า DKIM นี้แหละที่ต้องอยู่ใน DNS ที่ "ใช้งานจริง" ด้วย (ระวังกรณีโดเมนชี้ DNS ไปที่อื่น เช่น Cloudflare — ต้องเอา record มาวางที่นั่นด้วย)
• E-Mail Accounts — จุดสร้าง mailbox ที่ "auth ได้" สำหรับให้เว็บ/แอปส่งเมลผ่าน (สำคัญมากกับ WordPress — อ่านต่อหัวข้อถัดไป)
• MX Records — เช็กว่า MX ชี้ถูก เพราะ SPF ตัว mx อ้างอิงจากตรงนี้

📌 ข้อควรระวังที่เจอบ่อย: ถ้าคุณย้าย DNS ไปจัดการที่ Cloudflare หรือที่อื่น แต่ DKIM/SPF ถูกสร้างไว้แค่ใน DirectAdmin โดเมน — record พวกนั้นจะ ไม่มีผล เพราะโลกภายนอกอ่าน DNS จากที่ที่ nameserver ชี้ไป ต้องก๊อป TXT records ทั้งหมดไปวางที่ DNS ที่ active จริง

WordPress: ทำไม wp_mail มักเข้า Spam และวิธีแก้ที่ถูก

เคสคลาสสิกของคนทำเว็บ WordPress เลยครับ — ฟอร์มติดต่อ, WooCommerce แจ้งออเดอร์, อีเมลรีเซ็ตรหัสผ่าน ส่งออกไปแล้วเข้า Spam หมด

สาเหตุคือ โดยค่าเริ่มต้น WordPress ส่งเมลผ่านฟังก์ชัน PHP mail() ซึ่งมันยิงเมลออกจากเว็บเซิร์ฟเวอร์ตรงๆ โดยไม่ผ่านการ authenticate กับ mailbox และบ่อยครั้งใช้ผู้ส่งมั่วๆ อย่าง wordpress@yourdomain.com ที่ไม่มีอยู่จริง → ผล: ไม่ผ่าน DKIM, อาจไม่ตรง SPF, และมักไม่ align ตามที่เล่าไปข้างบน ปลายทางตีว่าน่าสงสัย

วิธีแก้ที่ถูกต้อง: ให้ WordPress ส่งเมลผ่าน SMTP ของ mailbox ที่ auth แล้ว

1. สร้าง mailbox จริงใน DirectAdmin → E-Mail Accounts เช่น no-reply@yourdomain.com
2. ติดตั้งปลั๊กอิน SMTP (เช่น WP Mail SMTP, FluentSMTP — ตัวไหนก็ได้ หลักการเดียวกัน)
3. ตั้งค่าให้ส่งผ่าน SMTP ของ mailbox นั้น: host = เมลเซิร์ฟเวอร์ของโฮสต์, port 465 (SSL) หรือ 587 (TLS), ใส่ username/password ของ mailbox
4. ตั้ง "From" ให้ตรงกับ mailbox จริง (อย่าใช้อีเมลที่ไม่มีตัวตน) — ข้อนี้ช่วยเรื่อง alignment ไปในตัว

พอทำแบบนี้ เมลจาก WordPress จะออกผ่าน mailbox ที่ auth แล้ว → ผ่าน DKIM/SPF + align → เข้า Inbox

สังเกตว่า ตรงนี้คือจุดที่หลายคนเข้าใจผิดว่า "ปลั๊กอินช่วยให้เมลไม่เข้า Spam" — จริงๆ ปลั๊กอิน SMTP ไม่ได้วิเศษ มันแค่บังคับให้ส่งผ่านช่องทางที่ auth แล้วเท่านั้น รากฐานยังเป็นเรื่อง DNS อยู่ดี ถ้า SPF/DKIM ยังไม่ครบ ต่อให้ใช้ปลั๊กอินก็ยังเข้า Spam

เครื่องมือทดสอบ — อย่าเดา ให้วัด

แก้แล้วต้องวัดผลครับ อย่าเดาว่า "น่าจะดีขึ้น" นี่คือเครื่องมือที่ผมใช้จริง:

• mail-tester.com — เครื่องมือที่ผมแนะนำที่สุดสำหรับเริ่มต้น: เข้าไปแล้วมันให้ที่อยู่อีเมลสุ่มมา 1 อัน ให้คุณส่งเมลทดสอบไปที่อยู่นั้น แล้วกดเช็ก มันจะ ให้คะแนนเต็ม 10 พร้อมบอกชัดเลยว่า SPF ผ่านไหม DKIM ผ่านไหม DMARC ตั้งไหม alignment ตรงไหม ติด blacklist หรือเปล่า เนื้อหามีปัญหาตรงไหน — ตั้งเป้าให้ได้ 9-10/10
• MXToolbox — เช็ก record ราย type ได้ละเอียด: SPF Lookup, DKIM Lookup, DMARC Lookup, MX Lookup และมี Blacklist Check ในตัว เหมาะตอนต้องการตรวจ record ทีละตัวว่าตั้งถูก syntax ไหม
• เช็ก Blacklist (เช่น Spamhaus) — เอา IP ของเซิร์ฟเวอร์ส่งเมลไปเช็กว่าติด blacklist ของ Spamhaus หรือ list อื่นไหม ถ้าติด นี่คือเหตุผลใหญ่ที่เมลเข้า Spam และต้องดำเนินการขอ delist

Shared IP — เพื่อนร่วม IP ส่ง Spam แล้วลามถึงเราได้

ก่อนจะไปหัวข้อสำคัญสุดท้าย ขอแทรกเรื่องที่คนใช้ Shared Hosting ควรรู้ไว้: บน Shared Hosting คุณ ใช้ IP ร่วมกับเว็บอื่นอีกหลายเว็บ ถ้าเพื่อนร่วม IP คนใดคนหนึ่งส่งสแปม หรือเว็บเขาโดนแฮกแล้วถูกใช้ยิงสแปม → IP นั้นติด blacklist → เมลของคุณที่ออกจาก IP เดียวกันก็พลอยโดนกรองไปด้วย ทั้งที่คุณไม่ได้ทำอะไรผิดเลย

นี่คือเหตุผลว่าทำไม "คุณภาพและความสะอาดของ IP ที่ผู้ให้บริการดูแล" ถึงสำคัญกว่าที่คนคิด — มันไม่ใช่แค่เรื่องเร็ว/ช้า แต่กระทบ "เมลของคุณถึงลูกค้าไหม" โดยตรง และที่สำคัญคือ IP reputation ไม่ใช่เรื่อง "ตั้งครั้งเดียวจบ" แต่เป็นเรื่องที่ต้องเฝ้าและดูแลต่อเนื่อง — เพราะเพื่อนร่วม IP เปลี่ยนพฤติกรรมได้ตลอด การเลือกโฮสต์ที่ใส่ใจดูแล IP reputation, แยกการส่งเมลที่ดี, และจัดการเมื่อมีปัญหา = คุณไม่ต้องมานั่งรับกรรมจากเพื่อนร่วม IP

ส่วนที่หลายคนพลาด: "ก็โฮสต์ผมเขาตั้ง SPF/DKIM ให้แล้วนี่ / ผมทำตามคู่มือเขาแล้วนี่"

มาถึงตรงนี้ หลายคนจะเริ่มสบายใจว่า "อ๋อ งั้นก็ไม่เป็นไร โฮสต์ที่ผมใช้เขาตั้ง SPF/DKIM ให้แล้ว" หรือ "ผมก๊อปคู่มือเขามาวางครบแล้ว" — เดี๋ยวก่อนครับ ตรงนี้แหละคือกับดักชั้นที่สอง และเป็นจุดที่ผมเจอคนทำเว็บติดเยอะมาก

เพราะบทความและคู่มือเรื่อง SPF/DKIM/DMARC ที่หาเจอตามเน็ตทั่วไป ส่วนใหญ่มัน "จบแค่ตรงนั้น" — บางที่อธิบายเชิงแนวคิดว่า "3 ตัวต่างกันยังไง ทำไมต้องมี" ได้สวยงาม แต่ไม่พาลงมือทำจริง · บางที่เป็นคู่มือคลิกตามทีละขั้น "เพิ่ม TXT record แบบนี้ๆ" แต่ไม่บอกว่าทำไม และไม่เตือนกับดัก · และบางที่ลิสต์ "เหตุผลที่เมลเข้า Junk" ยาวเหยียด แต่กลับ ไม่พูดถึง SPF/DKIM/DMARC เลยสักคำ — ซึ่งคือสาเหตุจริงอันดับหนึ่ง! คนอ่านก็เลยไปนั่งแก้เนื้อหาตามที่บทความบอก เหนื่อยฟรี เพราะแก้ผิดจุด

ปัญหาคือ "ตั้ง SPF/DKIM ตามคู่มือแล้ว" ยังมีรูโหว่อีกอย่างน้อย 3 จุดที่คู่มือพวกนั้นมักไม่แตะ และนี่คือจุดที่เมลคุณยัง "ไม่เข้า Inbox" ทั้งที่คิดว่าทำครบแล้ว:

กับดักที่ 1 — rDNS/PTR ที่คุณตั้งเองไม่ได้ ต่อให้ทำคู่มือครบทุกข้อ อย่างที่เล่าไปข้างบน rDNS ต้องตั้งจากฝั่งเจ้าของ IP เท่านั้น คู่มือ "เพิ่ม TXT record" ทั่วไปไม่มีทางพาคุณตั้ง rDNS ได้ เพราะมันไม่ได้อยู่ในมือคุณ — ถ้าโฮสต์ไม่ได้ตั้ง rDNS ให้ (หรือตั้งไว้มั่วๆ) คุณจะทำ SPF/DKIM/DMARC ครบแค่ไหน เมลก็ยังโดนกรอง แล้วคุณจะงงว่า "ทำตามครบแล้วทำไมยังไม่หาย"

กับดักที่ 2 — IP reputation เป็นเรื่องต่อเนื่อง ไม่ใช่ตั้งครั้งเดียวจบ คู่มือตั้ง record เป็นงาน "ทำครั้งเดียว" — แต่ IP reputation เป็นงาน "ดูแลทุกวัน" ถ้าเพื่อนร่วม IP โดนแฮกพรุ่งนี้ แล้ว IP ติด blacklist เมลคุณก็เข้า Spam ทันที ทั้งที่ record คุณไม่ได้เปลี่ยนอะไรเลย — คู่มือไม่มีทางช่วยคุณตรงนี้ได้ เพราะมันต้องอาศัย "คนที่เฝ้าและจัดการ IP ให้สะอาดอยู่เสมอ"

กับดักที่ 3 — ตั้งครบแล้วแต่ mail-tester ยังไม่ผ่าน — แล้วใครช่วยคุณไล่? นี่คือข้อที่เจ็บที่สุด คุณตั้ง SPF/DKIM/DMARC ครบ ส่งเข้า mail-tester แล้วได้ 6/10 มันขึ้นเตือนอะไรไม่รู้เต็มไปหมด — SPF อาจซ้อนกันโดยไม่รู้ตัว, DKIM อาจหลุดเพราะ DNS ชี้ไปคนละที่, alignment อาจไม่ตรง, หรือ IP อาจติด list — คู่มือไม่มีทางรู้ว่าเคสคุณติดตรงไหน เพราะมันเขียนแบบทั่วไป ไม่ได้นั่งดูหน้าจอของคุณ คำถามจริงในวันนั้นคือ "แล้วใครจะนั่งไล่ทีละบรรทัดกับคุณจนมันเขียว?"

📌 จุดที่อยากให้สังเกต: ตลาดส่วนใหญ่ให้ "ความรู้" (บทความ/คู่มือ) เรื่อง SPF/DKIM/DMARC ไว้เยอะ — ซึ่งดีครับ แต่ความรู้กับ "การลงมือไล่เคสจริงของคุณจนเมลเข้า Inbox" มันคนละเรื่องกัน · และน้อยรายมากที่จะรับผิดชอบสองจุดที่อยู่ "นอกมือลูกค้า" คือ rDNS (ต้องเป็นเจ้าของ IP ถึงตั้งได้) กับ IP reputation ต่อเนื่อง (ต้องมีคนเฝ้า) · ความต่างตรงนี้แหละที่คุณจะรู้สึกได้จริงตอนเมลยังไม่เข้า ไม่ใช่ตอนอ่านคู่มือ

(ความเข้าใจผิด) ที่อันตรายที่สุด + สรุป 3M

ผมขอรวบ 3M ของเรื่อง "เมลเข้า Spam" ให้เห็นเป็นภาพเดียว เอาไปเช็กเว็บตัวเองได้ทันที:

🔵 (ความเข้าใจผิด) (ความเข้าใจผิด): "เมลเข้า Spam = ปัญหาอยู่ที่เนื้อหาเมล/ปลั๊กอิน" — จริงๆ คือ DNS ไม่ยืนยันตัวตน · "ตั้ง SPF/DKIM ตามคู่มือโฮสต์ครบแล้ว = จบ" — ยังเหลือ rDNS, IP reputation, และ alignment ที่คู่มือไม่แตะ · "เมื่อก่อนไม่ตั้งก็ยังเข้า Inbox นี่" — เส้นมาตรฐานถูกยกสูงขึ้นตั้งแต่ปี 2024 วิธีเดิมยิ่งใช้ไม่ได้

🔴 (สิ่งที่พลาด) (ความพลาดที่ทำเอง): นั่งแก้ subject/เนื้อหาสิบรอบแทนที่จะตั้ง authentication · มี SPF ซ้อนกันหลายบรรทัด (PermError = เหมือนไม่มี) · กระโดด DMARC ไป p=reject เลยจนเมลตัวเองหาย · ส่ง WordPress ผ่าน PHP mail() ที่ไม่ auth/ไม่ align · ก๊อป record ไว้ใน DirectAdmin แต่ DNS จริงชี้ไป Cloudflare (record ไม่มีผล)

🟠 (สิ่งที่ขาด) (สิ่งที่ "ไม่มี" เลยรับมือไม่ได้): ไม่มี SPF/DKIM/DMARC เลย · ไม่มี rDNS/PTR (ตั้งเองไม่ได้ ต้องให้เจ้าของ IP ตั้ง) · ไม่เข้าใจ alignment เลยแก้ "SPF/DKIM ผ่านแต่ DMARC fail" ไม่ถูก · ไม่มีใครเฝ้า IP reputation ให้ · ไม่มีคนช่วยไล่ mail-tester ตอนคะแนนยังไม่ถึง

สรุปเป็นตาราง: ตัวที่ต้องครบเพื่อให้เมลเข้า Inbox (เซฟไว้เช็กได้เลย)

ตัว	ทำหน้าที่อะไร	ใครตั้ง	ถ้าขาด/พลาดจะเจ็บยังไง
SPF	ลิสต์เซิร์ฟเวอร์ที่มีสิทธิ์ส่งแทนโดเมน	คุณตั้งเองที่ DNS	ไม่มี/ซ้อนกัน → ดูเหมือนเมลปลอม
DKIM	ลายเซ็นดิจิทัลกัน tamper + ยืนยันผู้ส่ง	DirectAdmin สร้างให้ (เช็กว่าอยู่ DNS จริง)	หลุด/อยู่ผิด DNS → ยืนยันไม่ได้
DMARC	นโยบาย none→quarantine→reject + รายงาน	คุณตั้งเองที่ DNS	กระโดดไป reject → เมลตัวเองหาย
Alignment (aspf/adkim)	From: ต้องตรงกับโดเมนที่ยืนยันได้	คุณคุมผ่าน From:/บริการที่ใช้	SPF/DKIM ผ่านแต่ DMARC fail แบบงงๆ
rDNS / PTR	IP ชี้กลับเป็น hostname ถูกต้อง	ผู้ให้บริการ (เจ้าของ IP) เท่านั้น	ไม่มี → ทำ record ครบก็ยังโดนกรอง
IP reputation	ความสะอาด/ประวัติของ IP ที่ส่ง	ผู้ให้บริการดูแลต่อเนื่อง	เพื่อนร่วม IP พังพรุ่งนี้ เมลคุณตก Spam ตาม

สังเกตว่า 4 ตัวแรกอยู่ในมือคุณ (ตั้งที่ DNS ได้) แต่ 2 ตัวล่าง — rDNS กับ IP reputation — อยู่นอกมือคุณ ต้องพึ่งผู้ให้บริการ นี่แหละคือเส้นแบ่งระหว่าง "โฮสต์ที่ปล่อยให้คุณงมเอง" กับ "โฮสต์ที่อยู่ข้างคุณ"

แล้ว PhalconHost คิดเรื่องนี้ยังไง? — Dev ดูแล Dev

ผมเล่าตรงๆ จากใจคนที่เคยเป็นคนทำเว็บนะครับ — เรื่อง SPF/DKIM/DMARC/rDNS เนี่ย ผมไม่ได้อ่านมาจากคู่มือ แต่ผมตั้งมันมาเป็นพันโดเมนกับมือ และเคยเป็นคนทำเว็บที่นั่งปวดหัวกับเมลเข้า Spam มาก่อนเหมือนกัน ผมรู้ว่าความรู้สึก "ทำตามครบทุกข้อแล้วแต่มันยังไม่หาย" มันกัดใจแค่ไหน

ที่ PhalconHost ผมเลยตั้งใจดูแลให้ครบทั้ง "ส่วนที่อยู่ในมือคุณ" และ "ส่วนที่อยู่นอกมือคุณ":

• ตั้ง SPF/DKIM/DMARC ให้พร้อมตั้งแต่แรก — สร้างโดเมนปุ๊บ ระบบ authentication พื้นฐานพร้อมใช้ ไม่ต้องมานั่งงมเอง (DirectAdmin + Exim สร้าง DKIM ให้อัตโนมัติ ผมเช็กให้ว่ามันอยู่ใน DNS จริง)
• rDNS/PTR ตั้งให้ — จุดที่หลายเจ้าบอกว่า "ไม่ใช่หน้าที่เรา" และเป็นจุดที่ คู่มือทั่วไปพาคุณทำเองไม่ได้ เพราะมันต้องเป็นเจ้าของ IP ถึงตั้งได้ — IP เป็นของเรา เราก็ตั้งให้ ตรงไปตรงมา
• ดูแล IP reputation และความสะอาดของ IP อย่างต่อเนื่อง — ไม่ใช่ตั้งครั้งเดียวจบ เพราะมันคือเรื่อง "เมลลูกค้าถึงปลายทางไหม" ไม่ใช่แค่ตัวเลขสวยๆ และเป็นงานที่ลูกค้าทำเองไม่ได้จริงๆ
• ที่สำคัญที่สุด: เคสเมลเข้า Spam แจ้งมาทาง LINE ได้เลย ผมช่วยไล่ให้ — ส่ง mail-tester มาให้ดูคะแนน เราดูด้วยกันว่าติดตรงไหน SPF ซ้อนกันไหม DKIM หลุดไหม alignment ตรงไหม WordPress ตั้ง SMTP ถูกหรือเปล่า แก้ทีละจุดจนเข้า Inbox — อันนี้คือ "ข้อ 3" ในกับดักที่ผมเล่า: ความรู้มีเต็มเน็ต แต่คนที่นั่งไล่เคสจริงของคุณจนเขียว หายากกว่า

ขอวางจุดยืนให้ชัดนะครับ เพื่อไม่ให้เข้าใจผิด — เราเป็นโฮสต์แบบ Unmanaged ที่มี Dev (คือผม) คอยช่วยเกินหน้าที่ ไม่ใช่บริการ managed email ที่จะไปนั่งตั้งค่าทุกอย่างแทนคุณทุกเม็ด เช่น ถ้าโดเมนคุณชี้ DNS ไปอยู่ที่อื่น (Cloudflare/ผู้ให้บริการ DNS เจ้าอื่น) หรือคุณส่งเมลหลักผ่าน Google Workspace/ระบบภายนอก — งานตั้งค่าฝั่งนั้นเป็นของคุณ (หรือผมแนะนำวิธีให้ได้ แต่ไม่ได้ล็อกอินไปทำให้) สิ่งที่ผมทำคือ ส่วนที่เป็น IP/เซิร์ฟเวอร์ของเราโดยตรง (rDNS, IP reputation, auth พื้นฐาน) ผมจัดให้เต็มที่ + ส่วนที่คุณติดแล้วไล่เองไม่ออก แจ้งมา ผมช่วยดูให้แบบ best-effort ตามสไตล์ "แจ้งมา เราจัดให้" — ถ้าเคสไหนมันเกินขอบที่เราช่วยได้จริงๆ ผมก็จะบอกตรงๆ ไม่รับปากลอยๆ

เพราะผมเชื่อว่าเรื่องเทคนิคแบบนี้ คุณไม่ควรต้องแก้คนเดียว — คุณควรมี Dev สักคนที่เข้าใจปัญหาคุณคอยหนุนหลัง ไม่ใช่ฝ่ายขายที่อ่านสคริปต์แล้วบอกว่า "ลองส่งใหม่ดูนะคะ" นี่คือสิ่งที่ลูกค้าผมหลายคนพูดเหมือนกันว่า "ทำไมไม่ได้เจอกันตั้งนานแล้ว" — เพราะที่ผ่านมาเขาเจอแต่โฮสต์ที่ทิ้งเขาไว้กลางทางพร้อมคู่มือหนึ่งหน้า

ถ้าเมลคุณยังเข้า Junk อยู่ ทักมาเลย

ลองทำตามบทความนี้ดูก่อนครับ — เช็ก SPF ว่ามีอันเดียว, เปิด DKIM, ตั้ง DMARC p=none, เช็ก alignment ว่า From: ตรงกับโดเมนที่ยืนยันได้ไหม แล้วส่งเข้า mail-tester ดูคะแนน

ถ้าทำแล้วยังงงๆ หรือคะแนนยังไม่ถึง หรือไม่แน่ใจว่าเซิร์ฟเวอร์ที่ใช้อยู่ตั้ง rDNS ให้หรือยัง — ทักมาคุยกับผมที่ LINE OA ของ PhalconHost ได้เลย บอกโดเมนมา เดี๋ยวช่วยดูให้ว่าติดตรงไหน ไม่ต้องเป็นลูกค้าก่อนก็ถามได้ครับ คุยกับ Dev ตัวจริง ไม่ใช่บอท — และถ้าดูแล้วของคุณโอเคอยู่แล้ว ไม่ต้องย้ายมาก็ได้ ผมก็จะบอกตามนั้นตรงๆ

— คุณอ๊อด, PhalconHost · Dev ดูแล Dev