MTA-STS Policy Generator: บังคับใช้ STARTTLS ให้โดเมนคุณด้วย policy ตามมาตรฐาน RFC 8461

STARTTLS ทำให้การเข้ารหัสอีเมลดูเหมือนเป็นเรื่องปกติไปแล้ว: mail server ส่วนใหญ่ประกาศรองรับ และเมื่อทั้งสองฝั่งรองรับ การเชื่อมต่อ SMTP ก็จะอัปเกรดเป็น TLS แต่จุดอ่อนคือการประกาศนั้นเองเป็นแบบ optional และไม่มีการยืนยันตัวตน ผู้โจมตีที่ยืนอยู่บนเส้นทางเครือข่าย — router ที่ถูกแทรกซ้อน, ISP ที่ไม่น่าไว้ใจ หรือ national firewall — แค่ลบบรรทัด STARTTLS ออกจาก greeting ของ server ได้เลย ฝั่งผู้ส่งจะเห็นว่าไม่มีข้อเสนอ TLS จึงยอมส่งต่อแบบ plaintext อย่างสุภาพ พร้อมไฟล์แนบทั้งหมด โดยไม่มี log ความผิดพลาดแม้แต่บรรทัดเดียว นี่คือ STARTTLS downgrade attack แบบคลาสสิก ที่ทั้งผู้ส่งและผู้รับมองไม่เห็นเลย

MTA-STS ตามมาตรฐาน RFC 8461 ถูกออกแบบมาปิดช่องโหว่นี้โดยเฉพาะ โดเมนของคุณ publish policy ที่ระบุว่า MX host ตัวไหนเท่านั้นที่รับเมลของโดเมนได้ และประกาศว่าการส่งต้องผ่าน TLS session ที่ถูกต้องพร้อม certificate ที่ตรงกัน ฝั่งผู้ส่งที่รองรับ MTA-STS จะดึง policy นี้ก่อนเชื่อมต่อ ถ้าเจอการ downgrade แบบด้านบน ก็จะปฏิเสธการส่งแทนที่จะปล่อยข้อความรั่วไปเป็น plaintext

จุดที่ต้องระวังคือ policy ต้องมีอยู่สองที่พร้อมกันและต้องสอดคล้องกันเสมอ: DNS TXT record ที่ _mta-sts.yourdomain.com สำหรับให้ผู้ส่งค้นหา policy และตัวไฟล์ policy เองที่ต้อง serve ผ่าน HTTPS ที่ https://mta-sts.yourdomain.com/.well-known/mta-sts.txt MTA-STS Policy Generator ของเราสร้างทั้งสองส่วนนี้ให้พร้อมกัน — ทั้ง mode, MX pattern และ max_age — โดยประมวลผล 100% ฝั่ง client-side ในเบราว์เซอร์ของคุณ

ทำไมต้องใช้ MTA-STS Policy Generator

• สร้างทั้งสองส่วนในครั้งเดียว — MTA-STS จะทำงานก็ต่อเมื่อ DNS TXT discovery record และไฟล์ policy บน HTTPS ตรงกัน เครื่องมือสร้างทั้งคู่จาก input ชุดเดียว จึงไม่มีทางเพี้ยนตั้งแต่วันแรก
• รูปแบบถูกต้องตาม RFC 8461 — ลำดับ tag, ชื่อ record และ field ของ policy ถูกต้องครบ ซึ่งเป็นรายละเอียดที่ฝั่งผู้ส่งตรวจแบบเข้มงวด และเป็นจุดที่พลาดบ่อยถ้าพิมพ์เอง
• Workflow แบบเริ่มจาก testing ก่อนเสมอ — เครื่องมือออกแบบมาให้ publish ด้วย testing mode ก่อนได้ง่าย จะมอนิเตอร์การส่งโดยไม่เสี่ยงเมลโดนปฏิเสธก่อนที่ policy จะพิสูจน์ตัวเอง
• รองรับ MX pattern ยืดหยุ่น — ใส่ host แบบเจาะจงอย่าง mx1.example.com หรือแบบ wildcard ก็ได้ ทั้งระบบเมล provider เดียวและหลาย provider พร้อมกัน
• จัดการ id และ max_age ให้ถูกสเปก — policy id และอายุ cache เป็นไปตามข้อกำหนด ทำให้การ cache ฝั่งผู้ส่งทำงานตามที่คุณตั้งใจทุกครั้งที่อัปเดต policy
• ประมวลผล 100% ฝั่ง client-side — ชื่อโดเมนและรายละเอียด mail infrastructure ของคุณไม่เคยออกจากเบราว์เซอร์ ไม่อัปโหลด ไม่ต้องสมัครสมาชิก ไม่มี log

ฟีเจอร์เด่น

• คัดลอกไปใช้ได้ทันที — แต่ละส่วนแสดงในรูปแบบที่เอาไปวางลง DNS หรืออัปโหลดขึ้น web server ได้เลย
• จัดการ id ให้สอดคล้องกัน — แก้ policy เมื่อไร เครื่องมือให้ id ใหม่ทันที ซึ่งเป็นสัญญาณเดียวที่บอกผู้ส่งที่ cache ไว้ให้ดึง policy ใหม่

วิธีใช้งาน

1. เปิดเครื่องมือ MTA-STS Policy Generator แล้วกรอก mail domain ของคุณ — คือโดเมนที่ผู้ใช้ส่งเมลถึง ไม่ใช่ subdomain ที่ serve policy
2. เลือก mode — เริ่มที่ testing ก่อนเสมอ เพราะ publish ให้ monitor ได้โดยยังไม่สั่งให้ผู้ส่งปฏิเสธเมล
3. เพิ่ม MX pattern — ระบุทุก hostname ที่รับเมลของโดเมนได้ หนึ่งรายการต่อหนึ่งบรรทัด ให้ตรงกับ MX record ใน DNS พอดี ถ้ามี backup provider ที่รับเมลด้วยก็ใส่ไปด้วย
4. ตั้ง max_age แล้วกดสร้าง — เครื่องมือให้ artifact ทั้งสองส่วน: คัดลอก DNS TXT record ไปเพิ่มที่ DNS provider ของคุณที่ชื่อ _mta-sts.yourdomain.com และ publish ไฟล์ policy ที่ https://mta-sts.yourdomain.com/.well-known/mta-sts.txt โดยต้อง serve ผ่าน HTTPS พร้อม certificate ที่ valid
5. มอนิเตอร์แล้วค่อย enforce — ดู delivery report (TLS-RPT คือคู่หูมาตรฐาน) ยืนยันว่าไม่มีผู้ส่งที่ถูกต้องล้มเหลว แล้วสร้างใหม่ด้วย mode enforce — อย่าลืมเปลี่ยน id ด้วย เพื่อให้ผู้ส่งดึง policy ตัวใหม่

นโยบายหนึ่งชุด ประกอบด้วยสองส่วน

ส่วน DNS เป็น discovery record ผู้ส่งไม่ได้เดาว่า policy ของคุณอยู่ที่ไหน แต่จะ lookup TXT record ที่ _mta-sts.yourdomain.com ค่าภายในสั้นและเข้มงวด: v=STSv1 ประกาศเวอร์ชันของ policy และ id= คือ string สั้น ๆ ที่ระบุ revision ปัจจุบันของ policy ตัว id นี้คือกลไก cache — ผู้ส่งจะเก็บ policy ไว้ได้นานสูงสุด max_age วินาที และจะกลับมาดึงไฟล์บน HTTPS ใหม่ก็ต่อเมื่อ id ที่เห็นใน DNS ต่างจากที่ cache ไว้เท่านั้น ถ้าแก้ไฟล์ policy แต่ไม่เปลี่ยน id ผู้ส่งส่วนใหญ่จะยังใช้ policy เก่าต่อไปจนกว่าจะหมดอายุ

ส่วน HTTPS คือตัว policy เอง เป็นไฟล์ text เล็ก ๆ ที่ serve จาก subdomain mta-sts ผ่าน TLS ที่ถูกต้อง ตัวอย่างฉบับเต็มพร้อมคำอธิบาย:

version: STSv1          # เวอร์ชันรูปแบบ policy ปัจจุบันคือ STSv1 เท่านั้น
mode: testing           # testing ใช้ monitor และรายงาน, enforce บังคับใช้ TLS
mx: mx1.example.com     # host แบบเจาะจงที่รับเมลได้
mx: *.example.net       # wildcard ครอบคลุม server ทั้งกองของ provider
max_age: 86400          # จำนวนวินาทีที่ผู้ส่ง cache policy นี้ได้

field mode คือจุดที่ deployment ส่วนใหญ่ควรเดินช้า ๆ ใน testing mode ผู้ส่งที่รองรับจะนำ policy ไปใช้แต่ยังไม่ปฏิเสธการส่งเมื่อมีความผิดพลาด — เหมาะกับการหา backup MX ที่ลืมใส่ หรือ certificate ที่ไม่ตรงกัน ก่อนที่คุณจะก้าวไปขั้นถัดไป ส่วนใน enforce mode ผู้ส่งที่สร้าง TLS session ที่ถูกต้องกับ MX host ในลิสต์ไม่ได้ จะต้องไม่ส่งเมลนั้น นี่คือการป้องกัน downgrade ที่แท้จริง และเป็นเหตุผลว่าทำไม policy ที่ผิดพลาดใน enforce mode จึงแปลว่าเมลอาจค้างหรือ bounce — ต้องไล่ระดับอย่างมีหลักฐาน

เพราะความผิดพลาดช่วงต้น ๆ คือสิ่งที่คุณอยากเห็นที่สุด MTA-STS จึงจับคู่ได้ดีกับ TLS-RPT (RFC 8460): DNS TXT record อีกตัวที่ _smtp._tls.yourdomain.com บอกผู้ส่งว่าจะส่ง delivery report ไปที่ใด publish ทั้งคู่ ดูรายงานระหว่าง testing mode แล้วค่อยเลื่อนเป็น enforce เมื่อตัวเลขสะอาด

Use Cases ในทางปฏิบัติ

Hardening ระบบเมลระดับองค์กร

องค์กรที่รัน Exchange, Postfix หรือ gateway ของตัวเองจะได้การรับประกันที่จับต้องได้: การดักฟังต้องทลาย TLS ไม่ใช่แค่ยืนอยู่บนเส้นทางเครือข่าย การเพิ่ม policy นี้เข้าไปในแผน hardening ช่วยปิดช่องที่ SPF, DKIM และ DMARC ตั้งใจปล่อยไว้ — สามตัวนั้นยืนยันความถูกต้องของข้อความ แต่ MTA-STS ปกป้องช่องทางที่ข้อความเดินทางผ่าน

ย้าย mail provider

การเปลี่ยน platform เมลคือช่วงที่ MX list ที่ล้าสมัยทำร้ายคุณมากที่สุด สร้าง policy ใหม่ด้วย host ของ provider ตัวใหม่ publish ด้วย id ใหม่ และเก็บ provider เดิมไว้ในลิสต์จนกว่าการ migrate จะเสร็จ ผู้ส่งจะปรับตัวไปหา topology ใหม่โดยไม่มีช่วงเวลาที่การส่งล้มเหลว

Checklist เพื่อการ compliance

Framework ที่กำหนดให้เข้ารหัสข้อมูลระหว่างทางของอีเมล หลายฉบับอ้างอิง MTA-STS กันชัดเจนขึ้นเรื่อย ๆ เครื่องมือนี้สร้าง artifact ที่ auditor ขอพอดี — ทั้ง discovery record และไฟล์ policy ที่ host ไว้ — และแนวทาง testing ไป enforce ช่วยให้คุณมีหลักฐานว่าการบังคับใช้ถูก rollout อย่างมีขั้นตอน

ป้องกันการดักอีเมลแบบ MITM

สำหรับทีมที่แลกเปลี่ยนสัญญา ใบแจ้งหนี้ หรือข้อมูลส่วนบุคคล SMTP แบบ plaintext คือจุดอ่อนที่ผู้โจมตีรออยู่ เมื่อ policy อยู่ใน enforce mode ความพยายาม downgrade ในโลกจริงจะกลายเป็น delivery failure ที่ผู้ส่งเห็นและส่งซ้ำได้ — ไม่ใช่การรั่วไหลแบบเงียบ ๆ

Best Practices

• เริ่มจาก testing mode เสมอ — enforce ก่อนที่ MX list จะพิสูจน์แล้ว คือวิธีทำให้เมลที่ถูกต้องโดนปฏิเสธ
• ดู report ให้ครบก่อนสลับเป็น enforce — ให้เวลา testing mode อย่างน้อยไม่กี่สัปดาห์ และไล่ทุก failure ที่รายงานมาจนเจอสาเหตุใน infrastructure จริง
• ตั้ง max_age ให้สมเหตุสมผล — ราว 86,400 วินาที (หนึ่งวัน) ถึงไม่กี่สัปดาห์ เป็นทางกลางระหว่าง rollback ได้เร็วกับการ cache ฝั่งผู้ส่งที่มีประสิทธิภาพ
• เปลี่ยน id ทุกครั้งที่แก้ policy — id คือสัญญาณเดียวที่ผู้ส่งมีบอกว่า policy ถูกอัปเดต ไฟล์ใหม่ที่ใช้ id เก่าคือไฟล์ที่ไม่มีใครเห็น
• รักษาการ serve policy ด้วย HTTPS ที่ valid — ถ้า certificate ของ mta-sts.yourdomain.com หมดอายุ ผู้ส่งจะกลับไปใช้พฤติกรรม last-known policy หรือเลิกใช้ policy ของคุณ
• สร้าง policy ใหม่ทุกครั้งที่ MX เปลี่ยน — provider ใหม่, gateway ใหม่ หรือ backup host ที่ปลดออก — policy ต้องสะท้อนความจริงทันทีที่มันเปลี่ยน

เริ่มล็อกช่องทางเมลของคุณวันนี้

อีเมลแบบ plaintext คือค่า default ที่โดเมนของคุณเลือกโดยอัตโนมัติ จนกว่าคุณจะบอกว่าไม่ MTA-STS Policy Generator สร้าง MTA-STS policy ครบทั้งสองส่วนตาม RFC 8461 ในไม่กี่วินาที — DNS record, ไฟล์ policy, mode, MX pattern และ max_age — ทั้งหมดในเบราว์เซอร์ของคุณ เริ่มจาก testing mode วันนี้ แล้วทำให้ enforce เป็นระดับที่โดเมนของคุณพิสูจน์แล้วว่าไปถึงได้

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• DKIM Record Generator — สร้าง DKIM DNS TXT record ที่แบ่ง chunk ถูกต้องจาก public key ใดก็ได้
• Security Headers Generator — สร้าง CSP, HSTS และ HTTP security header อื่น ๆ สำหรับเว็บของคุณ
• YAML Formatter — จัดรูปแบบ, ตรวจสอบ และ beautify ไฟล์ YAML config รวมถึงไฟล์ตั้งค่า mail server

อยู่กับ testing จนกว่า report จะสะอาด แล้วค่อย enforce อย่างมั่นใจ Happy sending!

คำถามที่พบบ่อย

ถ: ต้องมีทั้ง DNS TXT record และไฟล์ policy บน HTTPS หรือไม่?

ตอบ: ต้องมีทั้งคู่ DNS record เป็นแค่ตัวชี้ทาง — ผู้ส่งดึงและนำ policy จริงจาก URL บน HTTPS มาใช้ publish ฝั่งเดียวแปลว่า MTA-STS ยังไม่ทำงาน และถ้าสองฝั่งไม่ตรงกัน ผู้ส่งอาจถือว่าเป็นความไม่สอดคล้องและเลือกไม่ใช้ policy นั้น

ถ: testing mode กับ enforce mode ต่างกันอย่างไร?

ตอบ: ใน testing mode ผู้ส่งที่รองรับจะนำ policy ไปใช้แต่ยังส่งเมลต่อเมื่อมีอะไรล้มเหลว ทำให้ rollout ปลอดภัย ส่วนใน enforce mode ผู้ส่งที่สร้าง TLS session ที่ถูกต้องกับ MX host ในลิสต์ไม่ได้ จะต้องไม่ส่งเมลนั้น — นี่คือการป้องกัน downgrade ที่แท้จริง

ถ: ควรตั้ง max_age เท่าไรดี?

ตอบ: หน่วยเป็นวินาที ค่าที่นิยมอยู่ระหว่าง 86,400 (หนึ่งวัน) ถึงหลายสัปดาห์ ค่าสั้นช่วยให้แก้พลาดได้เร็ว ค่ายาวลดความถี่ที่ผู้ส่งต้องกลับมาดึง policy ใหม่

ถ: ต้องเปลี่ยน policy id เมื่อไร?

ตอบ: ทุกครั้งที่เนื้อหา policy เปลี่ยน — ไม่ว่าจะสลับ mode, เพิ่มหรือถอด MX หรือแก้ max_age ผู้ส่งจะ cache policy ไว้จนกว่าจะเห็น id ใหม่ใน DNS ดังนั้น id ที่ไม่เปลี่ยน หมายความว่า policy ยังเป็นตัวเดิมในสายตาของพวกเขา

ถ: MTA-STS ทดแทน SPF, DKIM และ DMARC ได้หรือไม่?

ตอบ: ไม่ได้ ทั้งหมดแก้คนละปัญหา: protocol เหล่านั้นยืนยันว่าใครมีสิทธิส่งและข้อความถูกแก้ไขหรือไม่ ส่วน MTA-STS ปกป้องช่องทางขนส่งจากการ downgrade และการดักฟัง โดเมนที่ hardening ดีควรมีทั้งสองชั้นพร้อมกัน