
Google Workspace (เดิมชื่อ G Suite) ให้คุณใช้อีเมลธุรกิจในรูปแบบ [email protected] โดยมี Gmail, ปฏิทิน และ Drive ของ Google อยู่เบื้องหลัง หัวใจที่ทำให้ระบบทำงานคือ MX Record — เรกคอร์ดบนโดเมนที่บอกว่าอีเมลของโดเมนนี้ต้องส่งไปที่เซิร์ฟเวอร์ใด บทความนี้อธิบายว่า MX Record ทำงานอย่างไร วิธีตั้งค่าให้ชี้มาที่ Google และจุดที่พลาดบ่อยจนอีเมลใช้ไม่ได้
MX Record คืออะไร และทำไม Google Workspace ต้องใช้
MX Record (Mail Exchange Record) คือเรกคอร์ดประเภทหนึ่งในระบบ DNS ของโดเมน ทำหน้าที่ระบุว่าเซิร์ฟเวอร์ใดมีสิทธิ์รับอีเมลขาเข้าของโดเมนนั้น ทุกครั้งที่มีคนส่งอีเมลถึง [email protected] เซิร์ฟเวอร์ผู้ส่งจะค้นหา MX Record ของ yourdomain.com ก่อน แล้วจึงส่งข้อความไปยังเซิร์ฟเวอร์ที่ระบุไว้ตามลำดับ Priority หาก MX Record ชี้ผิดหรือไม่มีเลย อีเมลจะส่งไม่ถึงและมักตีกลับเป็น error ทันที
เมื่อคุณสมัคร Google Workspace แล้ว Google จะเป็นผู้รับและจัดเก็บอีเมลทั้งหมดผ่าน Gmail ดังนั้นโดเมนของคุณต้องชี้ MX Record มาที่เซิร์ฟเวอร์เมลของ Google ขั้นตอนนี้คือสะพานเชื่อมระหว่างชื่อโดเมนที่คุณถือครองกับกล่องจดหมายในระบบของ Google การตั้งค่าทำที่ผู้ที่เป็น Authoritative DNS ของโดเมน — สำหรับลูกค้า AsiaGB ที่ใช้ DNS เริ่มต้นก็ทำในแผง DirectAdmin ได้ทันที
ตาราง MX Records ของ Google Workspace
Google Workspace (ตามเอกสารของ Google) ใช้ MX Records 5 รายการพร้อมค่า Priority ดังตารางด้านล่าง ใส่ค่า Host เป็น @ (หรือเว้นว่าง ขึ้นกับแผงควบคุม) และ TTL ใช้ค่า 3600 วินาที (1 ชั่วโมง) ได้ตามมาตรฐาน:
| Host / Name | Priority | Value / Points to | TTL |
|---|---|---|---|
| @ | 1 | ASPMX.L.GOOGLE.COM | 3600 |
| @ | 5 | ALT1.ASPMX.L.GOOGLE.COM | 3600 |
| @ | 5 | ALT2.ASPMX.L.GOOGLE.COM | 3600 |
| @ | 10 | ALT3.ASPMX.L.GOOGLE.COM | 3600 |
| @ | 10 | ALT4.ASPMX.L.GOOGLE.COM | 3600 |
Priority (บางแผงเรียก Preference) ยิ่งเลขน้อยยิ่งสำคัญก่อน — เซิร์ฟเวอร์ผู้ส่งจะลอง ASPMX.L.GOOGLE.COM (Priority 1) เป็นอันดับแรก ถ้าไม่ตอบสนองจึงไล่ไปที่ ALT1/ALT2 (Priority 5) และ ALT3/ALT4 (Priority 10) ตามลำดับ ค่าทั้งห้าจึงต้องครบ ห้ามใส่แค่บางตัว มิฉะนั้นความทนทานต่อข้อผิดพลาด (redundancy) จะลดลง
ขั้นตอนตั้งค่า MX Record ทีละขั้นใน DirectAdmin
ทำตามลำดับนี้เพื่อย้ายอีเมลของโดเมนมาที่ Google Workspace อย่างปลอดภัย โดยไม่ทำให้บริการอื่น (เว็บไซต์ subdomain ฯลฯ) ของโดเมนกระทบ:
- ยืนยันความเป็นเจ้าของโดเมนด้วย TXT Record ก่อน — ใน Google Admin Console จะให้ค่า TXT verification (เช่น
google-site-verification=xxxxxxxx) นำไปเพิ่มเป็น TXT Record ใน DirectAdmin DNS Management แล้วกดยืนยันใน Google ก่อนเสมอ ขั้นตอนนี้พิสูจน์ว่าคุณเป็นเจ้าของโดเมนจริง - ลบ MX Record เดิมทั้งหมด — เข้า DirectAdmin → E-Mail Manager → MX Records เลือกโดเมน แล้วลบ MX Record เก่าทุกรายการ (เช่นของ Email Hosting เดิม หรือเรกคอร์ดที่ชี้กลับมาที่เซิร์ฟเวอร์โฮสติ้ง) เพื่อไม่ให้ปะปนกับของ Google
- เพิ่ม MX Record ของ Google ทั้ง 5 รายการ — กรอกค่าตามตารางด้านบนทีละรายการ พร้อมตั้ง Priority ให้ตรง (1 / 5 / 5 / 10 / 10)
- ปิดตัวเลือก "Use this server to handle my emails" — ใน DirectAdmin หากมีตัวเลือกให้เซิร์ฟเวอร์รับเมลเอง (local mail) ต้องปิด เพื่อให้เซิร์ฟเวอร์ส่งอีเมลออกไปยัง Google ไม่เก็บไว้เอง
- กด Save แล้วรอ DNS Propagation — บันทึกค่า แล้วรอให้ DNS กระจายทั่วโลก โดยทั่วไปใช้เวลา 15 นาทีถึง 48 ชั่วโมงขึ้นกับค่า TTL ของเรกคอร์ดเดิม
ขั้นตอนตั้งค่าใน DirectAdmin (สรุปย่อ)
- ล็อกอิน DirectAdmin
- ไปที่ E-Mail Manager → MX Records
- เลือกโดเมนที่ต้องการ
- ลบ MX Record เดิม ทั้งหมดออกก่อน
- เพิ่ม MX Record ใหม่ทีละรายการตามตารางด้านบน
- คลิก Save
ตั้งค่า SPF Record (สำคัญมาก)
เพิ่ม TXT Record เพื่อให้ Google Workspace ส่งอีเมลได้โดยไม่ถูก Spam:
ไปที่ DNS Management → เพิ่ม TXT Record:
Name: @ (หรือโดเมนของคุณ)
Value: v=spf1 include:_spf.google.com ~all
ตั้งค่า DKIM (แนะนำ)
เปิด DKIM ใน Google Workspace Admin Console → Gmail → Authenticate Email แล้วคัดลอก DKIM Key มาเพิ่มเป็น TXT Record ใน DirectAdmin DNS Management
ตั้ง SPF / DKIM / DMARC สำหรับ Google Workspace ให้ครบ
การชี้ MX Record อย่างเดียวทำให้รับอีเมลได้ แต่ถ้าต้องการให้อีเมล "ขาออก" ของคุณไม่ถูกตีตราเป็น Spam และป้องกันการปลอมแปลงชื่อโดเมน ต้องตั้งเรกคอร์ดยืนยันตัวตน 3 ชนิดให้ครบ ทั้งสามเป็น TXT Record ที่เพิ่มใน DirectAdmin DNS Management:
1) SPF — บอกว่าใครส่งแทนโดเมนได้
SPF ระบุว่าเซิร์ฟเวอร์ใดได้รับอนุญาตให้ส่งอีเมลในนามโดเมนของคุณ สำหรับ Google Workspace ใช้ค่าเดียวพอ:
Type: TXT
Host: @
Value: v=spf1 include:_spf.google.com ~all
ห้ามมี SPF Record มากกว่า 1 รายการต่อโดเมน หากเดิมมี SPF ของผู้ให้บริการอื่นอยู่แล้ว ให้รวมเข้าด้วยกันในบรรทัดเดียว (เพิ่ม include: ต่อกัน) ไม่ใช่สร้าง TXT แยกอันใหม่
2) DKIM — ลายเซ็นดิจิทัลกันการแก้ไขเนื้อหา
DKIM แนบลายเซ็นเข้ารหัสไปกับอีเมลทุกฉบับ ผู้รับใช้กุญแจสาธารณะที่ประกาศไว้ใน DNS ตรวจสอบว่าข้อความไม่ถูกดัดแปลงระหว่างทาง เปิดใน Admin Console → Apps → Google Workspace → Gmail → Authenticate Email จะได้ค่า host (มักเป็น google._domainkey) และ value ยาว ๆ นำมาเพิ่มเป็น TXT Record:
Type: TXT
Host: google._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3...
3) DMARC — นโยบายเมื่อ SPF/DKIM ไม่ผ่าน
DMARC บอกเซิร์ฟเวอร์ปลายทางว่าให้ทำอย่างไรกับอีเมลที่อ้างชื่อโดเมนคุณแต่ตรวจ SPF/DKIM ไม่ผ่าน และส่งรายงานสรุปกลับมาให้คุณ เริ่มต้นแบบปลอดภัยด้วยนโยบาย none เพื่อเฝ้าดูก่อน:
Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected]
เมื่อมั่นใจว่าอีเมลที่ส่งจริงผ่าน SPF/DKIM ครบแล้ว ค่อยยกระดับนโยบายเป็น p=quarantine แล้วจึงเป็น p=reject เพื่อบล็อกอีเมลปลอมที่อ้างชื่อโดเมนของคุณอย่างเด็ดขาด
ปัญหาที่พบบ่อยและวิธีแก้
อีเมลไม่เข้ากล่องจดหมาย Gmail
สาเหตุที่พบบ่อยที่สุดคือ DNS ยังไม่ propagate หรือ MX Record ใส่ค่าไม่ครบ 5 รายการ ตรวจด้วยเครื่องมือ MX lookup (เช่น MX Toolbox) ว่าโดเมนแสดง ASPMX.L.GOOGLE.COM ครบทั้ง 5 ค่าหรือยัง หากยังเห็นเซิร์ฟเวอร์เก่าค้างอยู่ ให้รอ TTL หมดอายุหรือกลับไปลบ MX เดิมที่ตกหล่น
MX เก่าค้าง / อีเมลแยกไปสองที่
หากลบ MX Record เดิมไม่หมด อีเมลขาเข้าจะถูกแบ่งระหว่างเซิร์ฟเวอร์เก่ากับ Google — บางฉบับเข้า Gmail บางฉบับไปค้างที่เซิร์ฟเวอร์เดิม วิธีแก้คือเข้า DirectAdmin ลบ MX Record ที่ไม่ใช่ของ Google ออกให้เหลือเฉพาะ 5 ค่าของ Google และอย่าลืมปิดตัวเลือก local mail ของเซิร์ฟเวอร์
การยืนยันโดเมน (Verification) ไม่ผ่าน
หาก Google แจ้งว่ายืนยันโดเมนไม่สำเร็จ ให้ตรวจว่า TXT verification ถูกวางที่ host ระดับโดเมนหลัก (@) ไม่ใช่ subdomain และคัดลอกค่ามาครบไม่มีช่องว่างเกิน บางครั้งต้องรอ DNS propagate สองสามสิบนาทีก่อนกดยืนยันซ้ำ อย่าลบ TXT verification ออกแม้ยืนยันผ่านแล้ว เพราะ Google อาจตรวจซ้ำเป็นระยะ
อีเมลขาออกตกถังขยะของผู้รับ
มักเกิดจาก SPF/DKIM/DMARC ไม่ครบหรือใส่ผิด ตรวจ SPF ว่ามี include:_spf.google.com และมีเพียง 1 รายการ ตรวจว่า DKIM เปิดใช้งานใน Admin Console แล้วจริง (ไม่ใช่แค่สร้าง key) และ DMARC ประกาศถูกต้อง เมื่อทั้งสามผ่าน คะแนนความน่าเชื่อถือของอีเมลจะดีขึ้นชัดเจน
รอ DNS Propagation
หลังบันทึก MX Records ต้องรอ DNS Propagation ประมาณ 15 นาที ถึง 48 ชั่วโมง ทดสอบโดยส่งอีเมลทดสอบไปยัง address ใหม่ หรือใช้ MX Toolbox ตรวจสอบ
ข้อควรระวัง: อย่าลืมลบ MX Record เดิมออกก่อนเพิ่มของ Google เพราะหาก MX ซ้อนกันอาจทำให้อีเมลบางส่วนยังคงไปที่ Server เดิม และอย่าลบ A Record หรือ CNAME ของโดเมน
คำถามที่พบบ่อย
ตั้ง MX Record แล้วอีเมลใช้ได้เลยไหม
ไม่ทันที ต้องรอ DNS Propagation ตั้งแต่ไม่กี่นาทีจนถึงหลายชั่วโมง ขึ้นกับค่า TTL ของเรกคอร์ดเดิม
ต้องลบ MX Record เดิมออกก่อนไหม
ควรลบ MX Record เดิม (เช่นของ Email Hosting หรือผู้ให้บริการรายก่อน) ออกให้หมด เหลือเฉพาะของ Google ไม่เช่นนั้นอีเมลอาจถูกส่งไปผิดเซิร์ฟเวอร์
ตั้ง MX ที่ไหน — ที่โดเมนหรือที่ Hosting
ตั้งที่ผู้ที่เป็น Authoritative DNS ของโดเมน ถ้าใช้ DNS ของ AsiaGB ก็ตั้งใน DirectAdmin ถ้าย้าย DNS ไป Cloudflare แล้วต้องตั้งใน Cloudflare
ต้องตั้ง SPF DKIM และ DMARC ทุกตัวเลยไหม
MX Record อย่างเดียวก็รับอีเมลได้แล้ว แต่ถ้าต้องการให้อีเมลขาออกไม่ถูกตีเป็น Spam และกันการปลอมแปลงชื่อโดเมน แนะนำให้ตั้งครบทั้ง SPF, DKIM และ DMARC อย่างน้อย SPF กับ DKIM ควรมีเสมอ ส่วน DMARC เริ่มที่ p=none เพื่อเฝ้าดูก่อนแล้วค่อยยกระดับ
ต้องการโดเมนสำหรับ Google Workspace?
จดโดเมน .com .co.th .in.th ที่ AsiaGB เริ่มต้น 500 บาท/ปี พร้อมจัดการ DNS ได้ทันที
จดโดเมนใหม่