เนื้อหาสนับสนุน สนับสนุนโดย THAI DATA CLOUDหมายความว่าอย่างไร
รับมืออีเมลล่ม บทเรียนจาก Microsoft 365 ล่มเกือบทั้งวัน 13 พ.ย. 2026 ธุรกิจไทยควรคุมโดเมนเอง มีสำเนาอีเมล และเส้นทางสำรองบนโครงสร้างพื้นฐานในประเทศ
โดย กองบรรณาธิการ THAI DATA อ่าน 11 นาที
สรุปประเด็นสำคัญ
- Microsoft 365 ล่มตั้งแต่เช้า 13 พฤศจิกายน 2026 ผู้ใช้เข้า Outlook ไม่ได้และอีเมลล่าช้า ณ 05:00 น. 14 พ.ย. Microsoft ยังไม่ปิดเหตุ รอให้อีเมลที่ค้างประมวลผลครบ และแจ้งว่าต้นเหตุมาจากการอัปเกรดความจุเครือข่าย ไม่ใช่ภัยไซเบอร์
- รับมืออีเมลล่มระหว่างเหตุ: อย่าเปลี่ยน MX Record แจ้งพนักงานและลูกค้าผ่านช่องทางที่ไม่พึ่งอีเมล และบันทึกเวลาที่ได้รับผลกระทบไว้เรียกร้องตามข้อตกลงระดับบริการ
- การพึ่งพาตัวเองไม่ได้แปลว่าเลิกใช้คลาวด์ต่างประเทศ แต่คือคุมโดเมนและ DNS เอง มีสำเนาอีเมลของตัวเอง มีเส้นทางอีเมลสำรอง และมีคนกับคู่มือที่พร้อม
- รายชื่อ Local Region Geographies ของ Microsoft 365 บน Microsoft Learn (อัปเดต 8 ต.ค. 2026) มีมาเลเซียและอินโดนีเซีย แต่ไม่มีประเทศไทย ส่วน PDPA ไม่ได้บังคับเก็บข้อมูลในประเทศ แต่มาตรา 28–29 วางเงื่อนไขการส่งข้อมูลออก
- ในประเทศไม่ได้แปลว่าไม่ล่ม Google Cloud ในสหราชอาณาจักรเคยล่ม 6 ชั่วโมง 8 นาที จากระบบไฟฟ้า แผนรับมืออีเมลล่มที่ดีจึงต้องมีสองเส้นทางที่ไม่พึ่งกันและซ้อมสลับจริง
รับมืออีเมลล่มกลายเป็นคำถามของผู้บริหารไทยทันทีหลังเหตุ Microsoft 365 ล่มเมื่อวันที่ 13 พฤศจิกายน 2026 ซึ่งทำให้หลายองค์กรเปิด Outlook ไม่ได้และอีเมลถึงช้าเกือบหนึ่งวันเต็ม คำตอบสั้นคือ ระหว่างเหตุให้สื่อสารผ่านช่องทางอื่นและอย่าเปลี่ยน MX Record ส่วนระยะยาว ธุรกิจไทยควรพึ่งพาตัวเองได้มากขึ้น คือคุมโดเมนและ DNS เอง มีสำเนาอีเมลของตัวเอง และมีเส้นทางอีเมลสำรองบนโครงสร้างพื้นฐานในประเทศ
บทวิเคราะห์นี้รวบรวมข้อเท็จจริงจากหน้าสถานะของ Microsoft รายงานหลังเหตุของผู้ให้บริการคลาวด์รายใหญ่ และนโยบายดิจิทัลของไทย แล้วสรุปเป็นแผนรับมืออีเมลล่ม 3 ชั้นที่ธุรกิจทุกขนาดเริ่มได้ เนื้อหานี้สนับสนุนโดย THAI DATA CLOUD ผู้ดำเนินงานเว็บไซต์นี้และผู้ให้บริการ Data Center และระบบอีเมลในประเทศ
รับมืออีเมลล่ม: เกิดอะไรขึ้นกับ Microsoft 365 วันที่ 13–14 พ.ย. 2026
หน้า Microsoft service health status แจ้งตั้งแต่เช้าวันที่ 13 พฤศจิกายน 2026 ว่าผู้ใช้อาจเข้ากล่องจดหมาย Exchange Online ไม่ได้ ทั้งผ่าน Outlook on the web, Outlook เดสก์ท็อป, Exchange ActiveSync และการเชื่อมต่อแบบ REST และอีเมลอาจถึงช้า ผลกระทบลามไปถึงบริการที่ต้องคุยกับ Exchange Online เช่น ปฏิทินและการนัดประชุมใน Teams, Copilot Chat และหน้า Microsoft 365 admin center บางหน้า ผู้ดูแลระบบจึงต้องตามอ่านอัปเดตจากหน้า status.cloud.microsoft แทน
ระหว่างเหตุ Microsoft ขยายเวลาเก็บอีเมลที่ล่าช้าเป็น 48 ชั่วโมง เมื่อ 00:57 น. วันที่ 14 พ.ย. Microsoft แจ้งว่าต้นเหตุมาจากปัญหาระหว่างการอัปเกรดความจุเครือข่าย ซึ่งแสดงผลหลังการเปลี่ยนค่าเครือข่ายครั้งล่าสุด ไม่เกี่ยวกับภัยไซเบอร์ ข้อความ ณ 05:00 น. วันที่ 14 พ.ย. ระบุว่าบริการฟื้นตัวต่อเนื่อง และ Microsoft จะเฝ้าดูต่ออีกระยะ พร้อมรอให้อีเมลที่ค้างระหว่างเหตุประมวลผลครบก่อนปิดเหตุ
สถานะรอบล่าสุดติดตามได้ที่ข่าว Microsoft 365 ล่ม 13 พ.ย. 2026 ซึ่งอัปเดตตามหน้าสถานะของ Microsoft ทุกรอบ
รับมืออีเมลล่มระหว่างเหตุ: 5 สิ่งที่ทำได้ทันที
- แจ้งผ่านช่องทางที่ไม่พึ่งอีเมล บอกพนักงานผ่านโทรศัพท์หรือกลุ่มแชตของบริษัท และบอกลูกค้าผ่านหน้าเว็บไซต์หรือบัญชีทางการว่าอีเมลอาจถึงช้า แต่ไม่ได้หายไป
- อย่าเปลี่ยน MX Record ระหว่างเหตุ อีเมลที่ค้างในคิวของผู้ให้บริการจะถูกส่งต่อภายหลัง ถ้าเปลี่ยนตอนนี้ อีเมลจะแยกไปอยู่สองระบบและตามหายาก
- ติดตามหน้าสถานะของผู้ให้บริการโดยตรง เพราะหน้าผู้ดูแลระบบอาจเปิดไม่ได้ การเปิด ticket ซ้ำไม่ได้ทำให้แก้เร็วขึ้น
- บันทึกเวลาและงานที่ได้รับผลกระทบ ไว้ใช้เรียกร้องตามข้อตกลงระดับบริการ (SLA) และทบทวนแผนรับมืออีเมลล่มหลังเหตุ
- ระวังข้อความที่อ้างว่าเป็นวิธีแก้ปัญหา ช่วงที่ระบบหลักล่ม พนักงานมักรีบทำตามลิงก์หรือไฟล์ที่ส่งมาทางช่องทางอื่น ให้ยืนยันกับทีมไอทีก่อนทุกครั้ง
หลังระบบกลับมา ให้ตรวจคิวอีเมลขาออก งานอัตโนมัติที่ล้มเหลว และอีเมลสำคัญจากลูกค้าที่อาจเข้ามาช้ากว่าปกติ ขั้นตอนละเอียดสำหรับผู้ดูแล Microsoft 365 อยู่ในบทความรับมือ Microsoft 365 ล่ม (เนื้อหาสนับสนุนจาก THAI DATA CLOUD)
บทเรียนรับมืออีเมลล่มข้อแรก: เมื่อทั้งองค์กรพึ่งระบบเดียว
เหตุครั้งนี้ไม่ได้หยุดแค่อีเมล เพราะปฏิทิน การนัดประชุม Copilot และงานอัตโนมัติจำนวนมากผูกอยู่กับ Exchange Online เมื่อจุดเดียวสะดุด งานทั้งชุดจึงหยุดพร้อมกัน นี่คือความเสี่ยงจากการกระจุกตัว (Concentration Risk) ที่เห็นซ้ำในเหตุคลาวด์ล่มครั้งใหญ่หลายครั้ง
| เหตุการณ์ | เวลา (เวลาไทย) | สาเหตุตามรายงานของเจ้าของระบบ | ผลกระทบ |
|---|---|---|---|
| อัปเดต CrowdStrike | 19 ก.ค. 2024 | อัปเดตที่ผิดพลาดของ CrowdStrike | Microsoft ประเมินว่ากระทบ Windows 8.5 ล้านเครื่อง หรือไม่ถึง 1% |
| AWS us-east-1 | 20 ต.ค. 13:48 น. ถึง 21 ต.ค. 2025 04:20 น. | ข้อบกพร่องแฝงในระบบจัดการ DNS อัตโนมัติของ DynamoDB | บริการที่พึ่ง DynamoDB และบริการต่อเนื่องสะดุดราว 14 ชั่วโมงครึ่ง |
| Cloudflare | 18 พ.ย. 2025 เริ่ม 18:20 น. | การเปลี่ยนสิทธิ์ฐานข้อมูลทำให้ไฟล์ของ Bot Management ใหญ่เกินเพดาน | เว็บไซต์ลูกค้าแสดงหน้า error ทราฟฟิกหลักกลับมาราว 21:30 น. |
| Microsoft 365 | 13–14 พ.ย. 2026 | ปัญหาระหว่างอัปเกรดความจุเครือข่าย | Exchange Online และบริการที่พึ่งอีเมล |
จุดร่วมของทั้ง 4 เหตุคือ ไม่มีครั้งใดเกิดจากการโจมตี ทุกครั้งเกิดจากการเปลี่ยนแปลงหรือข้อบกพร่องภายในระบบของผู้ให้บริการเอง ลูกค้าแก้ปัญหาแทนไม่ได้ สิ่งเดียวที่ลูกค้าทำได้คือเตรียมทางเลือกไว้ก่อน การรับมืออีเมลล่มจึงเป็นเรื่องที่ต้องวางแผนตั้งแต่วันที่ระบบยังปกติ
พึ่งพาตัวเองเพื่อรับมืออีเมลล่ม หมายถึงอะไร
การพึ่งพาตัวเองไม่ได้แปลว่าต้องสร้าง Data Center เอง หรือเลิกใช้ Microsoft 365 ระบบของผู้ให้บริการระดับโลกยังเหมาะกับหลายองค์กร แต่องค์กรควรถือกุญแจสำคัญไว้เอง 5 ดอก
- โดเมนและ DNS บัญชีผู้จดโดเมนและผู้ให้บริการ DNS เป็นชื่อบริษัท มีผู้เข้าถึงได้อย่างน้อย 2 คน และรู้วิธีเปลี่ยน MX Record
- สำเนาอีเมลของตัวเอง มีสำเนากล่องจดหมายที่เก็บแยกจากผู้ให้บริการหลัก และเคยทดสอบกู้คืนจริง
- เส้นทางอีเมลสำรอง มีระบบที่สองที่พร้อมรับส่งอีเมลให้ฝ่ายที่ขาดอีเมลไม่ได้ เช่น ขาย จัดซื้อ และการเงิน
- คนและคู่มือ มีขั้นตอนรับมืออีเมลล่มเป็นลายลักษณ์อักษร ระบุว่าใครตัดสินใจ ใครแจ้งใคร และรายชื่อโทรศัพท์ที่ไม่ได้เก็บไว้ในอีเมล
- ผู้ดูแลที่ติดต่อได้ มีผู้ให้บริการหรือทีมที่ติดต่อได้ในเวลาไทยและภาษาไทย ไม่ใช่แค่หน้าสถานะภาษาอังกฤษ
องค์กรที่มีครบ 5 ข้อนี้ยังได้รับผลกระทบเมื่อผู้ให้บริการล่ม แต่เลือกได้ว่าจะทำอะไรต่อ แทนที่จะรออย่างเดียว ซึ่งเป็นแก่นของการรับมืออีเมลล่ม
ทำไมโครงสร้างพื้นฐานในประเทศสำคัญกับธุรกิจไทย: ข้อมูลและกฎหมาย
ข้อแรกคือที่ตั้งของข้อมูล หน้า Microsoft 365 data locations บน Microsoft Learn (อัปเดต 8 ตุลาคม 2026) ระบุกลุ่ม Local Region Geographies ที่ได้คำมั่นเรื่องเก็บข้อมูลในประเทศเพิ่มเติม เช่น มาเลเซีย อินโดนีเซีย ญี่ปุ่น อินเดีย ไต้หวัน และเกาหลีใต้ แต่ไม่มีประเทศไทย องค์กรตรวจที่ตั้งข้อมูลของ tenant ตัวเองได้จาก Data Location Card ใน admin center
ข้อที่สองคือกฎหมาย PDPA ไม่ได้บังคับเก็บข้อมูลในประเทศเป็นการทั่วไป แต่มาตรา 28–29 วางเงื่อนไขการส่งข้อมูลส่วนบุคคลไปต่างประเทศ รายละเอียดอยู่ในบทความ Data Residency ไทย การเก็บสำเนาอีเมลในประเทศเพื่อรับมืออีเมลล่มจึงไม่ใช่ข้อบังคับ แต่ช่วยลดคำถามเรื่องการส่งข้อมูลออก และทำให้ข้อมูลอยู่ภายใต้กฎหมายที่องค์กรคุ้นเคย
ข้อที่สามคือความเสี่ยงของที่ตั้ง เมื่อ 15 กันยายน 2026 AWS แจ้งว่ากู้ข้อมูลที่เก็บไว้เฉพาะใน Region บาห์เรนไม่ได้ หลังศูนย์ข้อมูลในภูมิภาคเสียหายจากเหตุโจมตีช่วงสงครามอิหร่าน ตามรายงานของ The National และข่าว AWS กู้ข้อมูล Region บาห์เรนไม่ได้ บทเรียนคือข้อมูลสำคัญต้องมีสำเนาอยู่นอกที่ตั้งหลัก สำหรับธุรกิจไทยที่ระบบหลักอยู่ต่างประเทศ สำเนาที่อยู่ในไทยคือสำเนาคนละที่ตั้งที่องค์กรเข้าถึงและควบคุมได้เอง
ทำไมโครงสร้างพื้นฐานในประเทศสำคัญกับธุรกิจไทย: เครือข่าย ทีม และนโยบาย
ด้านเครือข่าย ข้อมูล PeeringDB ณ 1 พฤศจิกายน 2026 แสดงสถานที่ในไทย 41 แห่ง และจุดแลกเปลี่ยนอินเทอร์เน็ต (IX) 12 จุด ตามบทความ Carrier Neutral ในไทย ผู้ใช้ในไทยกับเซิร์ฟเวอร์ในไทยจึงแลกเปลี่ยนทราฟฟิกกันภายในประเทศได้ผ่าน IX เหล่านี้ ระบบอีเมลสำรองที่ตั้งในไทยจึงอยู่ใกล้ผู้ใช้ และไม่ต้องพึ่งเส้นทางเดียวกับระบบหลักในต่างประเทศ ซึ่งเป็นคุณสมบัติที่การรับมืออีเมลล่มต้องการ
ด้านทีมดูแล เหตุครั้งนี้ผู้ดูแลระบบในไทยต้องตามอ่านอัปเดตภาษาอังกฤษบนหน้าสถานะตลอดคืน ขณะที่หน้า admin center บางหน้าเปิดไม่ได้ ผู้ให้บริการในประเทศที่มีทีมตอบเป็นภาษาไทยในเวลาไทยช่วยให้การรับมืออีเมลล่มตัดสินใจได้เร็วขึ้น
ด้านนโยบาย รัฐบาลไทยเดินทางเดียวกัน มาตรฐานคลาวด์ของ สกมช. มีผลตั้งแต่ 10 กันยายน 2569 กับหน่วยงานรัฐและโครงสร้างพื้นฐานสำคัญทางสารสนเทศ (มาตรฐานคลาวด์ สกมช.) และคณะรัฐมนตรีเห็นชอบนโยบายกำกับกิจการ Data Center เมื่อ 10 พฤศจิกายน 2569 (มติ ครม. Data Center) ส่วนโรดแมปโครงสร้างพื้นฐานดิจิทัลของ สดช. ประเมินเงินลงทุนจาก 335,000 ล้านบาทในปี 2026 เป็น 641,000 ล้านบาทในปี 2030 โดยปี 2026 เอกชนลงทุน 95.7% ส่วนใหญ่เป็นผู้ให้บริการรายใหญ่ระดับโลก ธุรกิจจึงควรดูทั้งที่ตั้ง ผู้ดำเนินงาน สัญญา และทีมดูแล เพราะตั้งอยู่ในไทยไม่ได้แปลว่าบริษัทไทยเป็นผู้ดูแล
ในประเทศไม่ได้แปลว่าไม่ล่ม: ข้อจำกัดที่ต้องรู้ก่อนรับมืออีเมลล่ม
ศูนย์ข้อมูลทุกแห่งล่มได้ เมื่อ 20 ตุลาคม 2026 Google Cloud ใน Region europe-west2 ของสหราชอาณาจักรล่ม 6 ชั่วโมง 8 นาที แม้ศูนย์ข้อมูลจะมีระบบไฟฟ้าแบบ 2N รายงานของ Google ระบุว่าระบบควบคุม (PLC) ไม่สั่งเครื่องปั่นไฟทำงาน ลูกค้าในอังกฤษที่ใช้ศูนย์ข้อมูลในประเทศก็สะดุดเช่นกัน อ่านต่อในข่าว Google Cloud europe-west2 ล่ม
การตั้งเซิร์ฟเวอร์เองก็มีความเสี่ยงของตัวเอง เดือนตุลาคม 2026 Microsoft ยืนยันว่าอัปเดต Windows Server ทำให้ Exchange Server ล่มได้ ผู้ใช้เข้า OWA ไม่ได้และอีเมลค้างในคิว ระบบที่ดูแลเองจึงต้องมีคนจัดการแพตช์และเฝ้าระบบ
SLA 99.9% ยังเปิดให้ระบบหยุดได้ราว 8.8 ชั่วโมงต่อปี ไม่ว่าผู้ให้บริการจะอยู่ในหรือนอกประเทศ เป้าหมายของการรับมืออีเมลล่มจึงไม่ใช่การย้ายจุดล้มเหลวจากที่หนึ่งไปอีกที่หนึ่ง แต่คือการมีสองเส้นทางที่ไม่พึ่งกัน เช่น ระบบหลักบน Microsoft 365 กับระบบสำรองในไทย หรือระบบหลักที่กรุงเทพฯ กับ DR Site คนละภูมิภาค
แผนรับมืออีเมลล่ม 3 ชั้น สำหรับธุรกิจไทย
ชั้นที่ 1 คน คู่มือ และช่องทางสื่อสาร (ไม่มีค่าใช้จ่าย) เขียนขั้นตอนรับมืออีเมลล่มหนึ่งหน้า ระบุผู้ตัดสินใจ ช่องทางแจ้งพนักงานและลูกค้า รายชื่อโทรศัพท์ที่พิมพ์เก็บไว้ และตรวจว่าเข้าบัญชีโดเมนและ DNS ได้จริง
ชั้นที่ 2 สำเนาอีเมลและการพักอีเมล (ค่าใช้จ่ายต่ำ) สำรองกล่องจดหมายไปยังพื้นที่จัดเก็บแยกในประเทศ และพิจารณาบริการพักอีเมลขาเข้า (Email Continuity) ซึ่งช่วยเมื่อเซิร์ฟเวอร์ปลายทางปฏิเสธการรับอีเมล แต่ไม่ช่วยเมื่อผู้ใช้เปิดกล่องจดหมายไม่ได้
ชั้นที่ 3 ระบบอีเมลสำรองบนโครงสร้างพื้นฐานในประเทศ ให้ฝ่ายที่ขาดอีเมลไม่ได้มีกล่องจดหมายบนระบบที่สองในไทย หรือย้ายบางกลุ่มแบบ Hybrid ตามแผนในย้ายอีเมลไป Private Mail Server (เนื้อหาสนับสนุนจาก THAI DATA CLOUD) องค์กรที่ระบบหลักอยู่ในไทยแล้วควรมี DR Site คนละภูมิภาค
| ชั้น | ทำอะไร | ช่วยเมื่อไร | ไม่ได้ช่วยเรื่องอะไร |
|---|---|---|---|
| 1 คนและคู่มือ | ขั้นตอน ช่องทางสื่อสาร สิทธิ์ DNS | ทุกเหตุ ลดความสับสน | ไม่ทำให้อีเมลกลับมาใช้ได้ |
| 2 สำเนาและการพักอีเมล | สำรองกล่องจดหมาย พักอีเมลขาเข้า | ข้อมูลหาย ปลายทางไม่รับอีเมล | ผู้ใช้ยังเปิดกล่องจดหมายหลักไม่ได้ |
| 3 ระบบสำรองในประเทศ | กล่องจดหมายที่สอง DR Site | ระบบหลักล่มนาน | ต้องเตรียมและซ้อมก่อน มีค่าใช้จ่ายรายเดือน |
Checklist รับมืออีเมลล่ม ก่อนเหตุครั้งถัดไป
ใช้ตารางนี้ตรวจความพร้อมรับมืออีเมลล่มทุกไตรมาส และหลังเปลี่ยนผู้ดูแลระบบหรือผู้ให้บริการทุกครั้ง
| รายการ | ตรวจอย่างไร | ผู้รับผิดชอบ |
|---|---|---|
| สิทธิ์เข้าบัญชีโดเมนและ DNS | ล็อกอินได้จริงอย่างน้อย 2 คน | ไอทีและผู้บริหาร |
| รายชื่อติดต่อฉุกเฉิน | พิมพ์เก็บ ไม่ได้อยู่ในอีเมลอย่างเดียว | ฝ่ายบุคคล |
| ช่องทางแจ้งลูกค้า | มีข้อความเตรียมไว้สำหรับหน้าเว็บและบัญชีทางการ | ฝ่ายขายและการตลาด |
| สำเนาอีเมล | รู้ว่าอยู่ที่ไหน และทดสอบกู้คืนแล้ว | ไอที |
| ระบบอีเมลสำรอง | ฝ่ายสำคัญส่งอีเมลจากระบบที่สองได้ | ไอที |
| ผู้ให้บริการที่ติดต่อได้ | มีเบอร์โทรและช่องทางแชตในเวลาไทย | ไอที |
| ซ้อมสลับระบบ | ซ้อมอย่างน้อยปีละครั้ง และจดเวลาที่ใช้ | ไอทีและผู้บริหาร |
THAI DATA CLOUD ช่วยวางแผนรับมืออีเมลล่มบนโครงสร้างพื้นฐานในประเทศ
THAI DATA CLOUD ก่อตั้งปี 2016 มี Data Center ในไทยที่ CS Loxinfo, Cyberworld Tower, Huawei Cloud, Alibaba Cloud และขอนแก่น โดยเชียงใหม่อยู่ระหว่างเตรียมเปิด และมีศูนย์ข้อมูลในสิงคโปร์ ลูกค้าเลือกให้ข้อมูลอยู่ในประเทศไทยได้ ตามหน้า Data Center ศูนย์ข้อมูลออกแบบตาม TIA-942 ระดับ Tier 3+ และได้ใบรับรอง ISO/IEC 27001, ISO 22301, ISO/IEC 20000-1 และ CSA STAR
- Private Mail Server ให้ 1 องค์กรต่อ 1 เซิร์ฟเวอร์ พร้อม IP ของตัวเอง บัญชีอีเมลไม่จำกัด เริ่ม 2,500 บาท/เดือน (Mail 80GB + Backup 420GB) SLA 99.9% ใช้เป็นระบบหลัก หรือเป็นระบบสำรองเพื่อรับมืออีเมลล่มสำหรับบางฝ่ายได้
- Data Center ขอนแก่น เชื่อมกรุงเทพฯ ด้วย Private Link 100 Gbps ที่มีเส้นสำรอง ใช้เป็น DR Site คนละภูมิภาค ออกแบบให้กลับมาให้บริการได้ภายใน 15 นาทีสำหรับระบบแบบ Warm Standby ขึ้นไป
- Microsoft 365 องค์กรที่ใช้ Microsoft 365 ผ่าน THAI DATA CLOUD ได้ทีมดูแลตลอด 24 ชั่วโมงที่ติดต่อเป็นภาษาไทยได้ และวางระบบสำรองในไทยเพิ่มได้โดยไม่ต้องเลิกใช้ Microsoft 365
ไม่มีบริการใดป้องกันเหตุล่มของผู้ให้บริการรายอื่นได้ สิ่งที่บริการเหล่านี้ให้คือเส้นทางที่องค์กรควบคุมเองและทีมที่ติดต่อได้ในเวลาไทย ปรึกษาแผนรับมืออีเมลล่มได้ฟรีที่โทร 098-894-2499 หรือ 082-653-2659 และ LINE @thaidatacloud
คำถามที่พบบ่อย
รับมืออีเมลล่มอย่างไร เมื่อ Outlook เข้าไม่ได้ทั้งบริษัท?
รับมืออีเมลล่มด้วยการแจ้งพนักงานและลูกค้าผ่านช่องทางที่ไม่พึ่งอีเมล เช่น โทรศัพท์ กลุ่มแชตของบริษัท หรือประกาศบนเว็บไซต์ ว่าอีเมลอาจถึงช้าแต่ไม่ได้หายไป ติดตามหน้าสถานะของผู้ให้บริการแทนการเปิด ticket ซ้ำ บันทึกเวลาที่ได้รับผลกระทบไว้ และอย่าเปลี่ยน MX Record ระหว่างเหตุ
ควรเปลี่ยน MX Record ไปเซิร์ฟเวอร์อื่นระหว่างที่อีเมลล่มไหม?
ไม่ควร ระหว่างเหตุ Microsoft 365 ล่ม Microsoft ขยายเวลาเก็บอีเมลที่ล่าช้าไว้ในคิวเป็น 48 ชั่วโมงแล้วส่งต่อภายหลัง ถ้าเปลี่ยน MX ตอนนั้น อีเมลส่วนหนึ่งจะเข้าระบบเดิม อีกส่วนเข้าระบบใหม่ ตามหายาก การรับมืออีเมลล่มด้วยระบบสำรองต้องเตรียมและทดสอบไว้ก่อนเกิดเหตุ
PDPA บังคับให้เก็บอีเมลไว้ในประเทศไทยหรือไม่?
ไม่บังคับเป็นการทั่วไป พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 28–29 ไม่ได้ห้ามส่งข้อมูลไปต่างประเทศ แต่กำหนดเงื่อนไข เช่น ปลายทางต้องมีมาตรฐานการคุ้มครองที่เพียงพอ หรือเข้าข้อยกเว้น การเก็บข้อมูลในประเทศจึงเป็นทางเลือกที่ลดคำถามเรื่องการส่งออก ไม่ใช่ข้อบังคับ ธุรกิจที่มีหน่วยงานกำกับเฉพาะควรตรวจกฎของตนเพิ่ม
ใช้ Data Center ในประเทศแล้วอีเมลจะไม่ล่มเลยใช่ไหม?
ไม่ใช่ ศูนย์ข้อมูลทุกแห่งล่มได้ Google Cloud ในสหราชอาณาจักรเคยล่ม 6 ชั่วโมง 8 นาทีเมื่อ 20 ตุลาคม 2026 เพราะระบบสั่งเครื่องปั่นไฟไม่ทำงาน และ SLA 99.9% ยังเปิดให้ระบบหยุดได้ราว 8.8 ชั่วโมงต่อปี ประโยชน์ของโครงสร้างพื้นฐานในประเทศคือได้เส้นทางที่องค์กรควบคุมเองและทีมดูแลในเวลาไทย การรับมืออีเมลล่มจึงต้องมีสองเส้นทางที่ไม่พึ่งกัน
ธุรกิจเล็กที่ไม่มีทีมไอทีควรเริ่มรับมืออีเมลล่มจากอะไร?
เริ่มจากสิ่งที่ไม่มีค่าใช้จ่าย คือ ตรวจว่าบริษัทเข้าบัญชีโดเมนและ DNS ได้เองอย่างน้อย 2 คน ทำรายชื่อโทรศัพท์ฉุกเฉินที่ไม่ได้เก็บไว้ในอีเมล และกำหนดช่องทางแจ้งลูกค้าเมื่ออีเมลล่ม จากนั้นจึงเพิ่มสำเนาอีเมลและระบบอีเมลสำรองในประเทศสำหรับฝ่ายที่ขาดอีเมลไม่ได้ เช่น ขายและการเงิน
แหล่งอ้างอิง
- Microsoft service health status — Microsoft
- Microsoft Admin Center Status (RSS feed) — Microsoft
- Microsoft 365 data locations — Microsoft Learn
- Helping our customers through the CrowdStrike outage — Microsoft
- Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region — Amazon Web Services
- Cloudflare outage on November 18, 2025 — Cloudflare
- Multiple services are experiencing issues in the europe-west2 region — Google Cloud
- Amazon Web Services unable to restore Bahrain data network knocked out by Iran — The National
- ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์การให้ความคุ้มครองข้อมูลส่วนบุคคลที่ส่งหรือโอนไปยังต่างประเทศ ตามมาตรา 28 พ.ศ. 2566 — สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล
- Data Center มาตรฐาน Tier 3+ ในไทยและสิงคโปร์ — THAI DATA CLOUD
- Data Center ขอนแก่น รับวางเซิร์ฟเวอร์ คลาวด์ และ DR Site — THAI DATA CLOUD
- Private Mail Server — THAI DATA CLOUD
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- องค์กรและบริษัท
- Microsoft245Google Cloud117CrowdStrike8AWS142Cloudflare26สกมช.17สำนักงานคณะกรรมการดิจิทัลเพื่อเศรษฐกิจและสังคมแห่งชาติ5Google242Huawei15Alibaba Cloud12
- ประเทศและสถานที่
- มาเลเซีย169อินโดนีเซีย127สหราชอาณาจักร325ญี่ปุ่น330อินเดีย160ไต้หวัน76เกาหลีใต้139บาห์เรน16อิหร่าน63กรุงเทพฯ404สิงคโปร์274
- ผลิตภัณฑ์และเทคโนโลยี
- Microsoft 36587Outlook35Exchange Online19Windows140Amazon DynamoDB6PeeringDB2Windows Server41LINE66
- กฎหมายและมาตรฐาน
- PDPA332
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ