Network & Security

MTA-STS และ TLS-RPT คืออะไร? ยกระดับความปลอดภัยอีเมลองค์กรด้วย Transport Security สำหรับ SME

เรียนรู้มาตรฐาน MTA-STS (Mail Transfer Agent Strict Transport Security) และ TLS-RPT ที่ช่วยบังคับให้อีเมลองค์กรเข้ารหัส TLS ระหว่างเซิร์ฟเวอร์ ป้องกัน Downgrade Attack และ MITM พร้อมขั้นตอนตั้งค่า DNS จริง

AF
ADS FIT Team
·9 นาที
Share:
MTA-STS และ TLS-RPT คืออะไร? ยกระดับความปลอดภัยอีเมลองค์กรด้วย Transport Security สำหรับ SME

# MTA-STS และ TLS-RPT คืออะไร? ยกระดับความปลอดภัยอีเมลองค์กรด้วย Transport Security สำหรับ SME

อีเมลเป็นช่องทางการสื่อสารที่สำคัญที่สุดของธุรกิจ แต่ยังเป็นจุดอ่อนที่ถูกโจมตีมากที่สุดเช่นกัน องค์กรส่วนใหญ่ตั้งค่า SPF, DKIM และ DMARC เพื่อยืนยันตัวตนของผู้ส่งเรียบร้อยแล้ว แต่หลายคนมองข้ามชั้นความปลอดภัยที่สำคัญอีกชั้นหนึ่ง — การเข้ารหัสระหว่าง Mail Server ด้วย TLS

การเชื่อมต่อ SMTP แบบ Opportunistic TLS (STARTTLS) เป็นค่าเริ่มต้นของโปรโตคอลอีเมล แต่ไม่ได้บังคับใช้ ทำให้ผู้ไม่หวังดีสามารถทำ Downgrade Attack บังคับให้เซิร์ฟเวอร์ส่งอีเมลแบบ Plain Text และอ่านข้อมูลได้ทั้งหมด บทความนี้จะอธิบายวิธีแก้ปัญหาด้วยมาตรฐาน MTA-STS (RFC 8461) และ TLS-RPT (RFC 8460) ที่ Google, Microsoft และ Comcast บังคับใช้อยู่แล้วในปี 2026

MTA-STS คืออะไร?

MTA-STS ย่อมาจาก Mail Transfer Agent Strict Transport Security เป็นมาตรฐานที่ประกาศให้ผู้ส่งอีเมลทราบว่า โดเมนของเรารองรับ TLS ขั้นต่ำระดับใด และบังคับให้ผู้ส่งใช้ TLS ที่ผ่านการตรวจสอบ Certificate เท่านั้น หากใช้ไม่ได้ ให้ตีกลับอีเมล

เปรียบเหมือน HSTS (HTTP Strict Transport Security) ของเว็บเบราว์เซอร์ที่บังคับ HTTPS เสมอ MTA-STS ก็บังคับให้ Email Server เชื่อมต่อด้วย TLS อย่างปลอดภัย

TLS-RPT คืออะไร?

TLS-RPT (SMTP TLS Reporting) เป็นคู่หูของ MTA-STS ที่ให้ Mail Server ของผู้ส่งรายงานกลับมาเมื่อพบปัญหาการเชื่อมต่อ TLS เช่น Certificate หมดอายุ, Cipher Suite ไม่ตรง, หรือ MTA-STS Policy Error องค์กรสามารถวิเคราะห์ว่ามีคนพยายามโจมตีหรือมีการตั้งค่าผิดพลาดจากฝั่งไหน

Subtopic 1: ความแตกต่างระหว่าง SMTP Security แต่ละมาตรฐาน

| มาตรฐาน | หน้าที่ | Record Type |

|---|---|---|

| SPF | ยืนยัน IP ที่ส่งแทนโดเมน | TXT |

| DKIM | ลายเซ็นดิจิทัลของเนื้อหาอีเมล | TXT |

| DMARC | นโยบายเมื่อ SPF/DKIM ไม่ผ่าน | TXT |

| MTA-STS | บังคับเข้ารหัส TLS ระหว่างเซิร์ฟเวอร์ | TXT + HTTPS Policy |

| TLS-RPT | รายงานปัญหา TLS | TXT |

| DANE | ใช้ DNSSEC ระบุ Cert ที่ถูกต้อง | TLSA |

MTA-STS เป็นทางเลือกที่ Implement ง่ายกว่า DANE เพราะไม่ต้องใช้ DNSSEC ทำให้เหมาะกับ SME ที่ไม่ได้ใช้ DNS Provider ที่รองรับ DNSSEC

Subtopic 2: ทำไม SME ต้องใช้ MTA-STS ในปี 2026

  • **ป้องกัน Downgrade Attack** — ป้องกันผู้โจมตีบังคับให้ส่งอีเมลแบบ Plain Text
  • **ป้องกัน MITM (Man-in-the-Middle)** — ใช้ Certificate Validation เพื่อยืนยันปลายทางไม่ใช่ Server ปลอม
  • **Compliance** — PDPA, GDPR และ HIPAA กำหนดให้เข้ารหัสข้อมูลระหว่างส่ง
  • **Gmail และ Microsoft 365 บังคับใช้** — ตั้งแต่ปี 2024 ทั้งสองบริษัทเริ่มบังคับ Bulk Sender ใช้ MTA-STS
  • **ฟรีและใช้งานง่าย** — ใช้แค่ DNS TXT Record และไฟล์ Policy บน HTTPS ไม่ต้องเสียเงินเพิ่ม
  • Subtopic 3: ขั้นตอน Deploy MTA-STS บน Production

  • **Step 1: ตรวจสอบ MX Record** — ต้องรู้ว่า Mail Server ของเราคือเซิร์ฟเวอร์ใด เช่น `mx.google.com.` สำหรับ Google Workspace
  • **Step 2: สร้าง Policy File** — สร้างไฟล์ `mta-sts.txt` วางที่ `https://mta-sts.yourdomain.com/.well-known/mta-sts.txt` โดยมีเนื้อหาประมาณ
  • ```

    version: STSv1

    mode: testing

    mx: mx.google.com

    mx: *.googlemail.com

    max_age: 86400

    ```

  • **Step 3: เพิ่ม DNS TXT Record** — สร้าง `_mta-sts.yourdomain.com` เป็น TXT ค่า `v=STSv1; id=20260424000000Z;`
  • **Step 4: ตรวจสอบ HTTPS Certificate** — ต้องใช้ Certificate ที่ Trust ได้ (เช่น Let's Encrypt) เพราะ MTA-STS ตรวจสอบ CA
  • **Step 5: เริ่มจาก mode: testing** — เปิด testing 30 วันเพื่อดู Report ก่อนเปลี่ยนเป็น enforce
  • **Step 6: เพิ่ม TLS-RPT Record** — TXT ที่ `_smtp._tls.yourdomain.com` ค่า `v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com`
  • **Step 7: Upgrade เป็น mode: enforce** — เมื่อมั่นใจว่า Report ไม่มีปัญหาแล้ว เปลี่ยนเป็น `mode: enforce`
  • Comparison Table: MTA-STS vs DANE vs Opportunistic TLS

    | หัวข้อ | Opportunistic TLS | MTA-STS | DANE |

    |---|---|---|---|

    | ต้องใช้ DNSSEC | ไม่ต้อง | ไม่ต้อง | ต้องใช้ |

    | ตรวจสอบ Certificate | ไม่ | ใช่ (ผ่าน CA) | ใช่ (ผ่าน TLSA) |

    | ป้องกัน Downgrade Attack | ไม่ | ใช่ | ใช่ |

    | ความซับซ้อนในการติดตั้ง | ต่ำ | กลาง | สูง |

    | รองรับโดย Gmail | ใช่ | ใช่ | ใช่ |

    | เหมาะกับ SME | Default | แนะนำ | ต้องใช้ทีม IT เฉพาะทาง |

    เครื่องมือตรวจสอบ MTA-STS สำหรับ Admin

  • **HardenThatPolicy** — ตรวจสอบ Policy Syntax
  • **MXToolbox MTA-STS Check** — ทดสอบ DNS และ HTTPS Config
  • **Postmark DMARC Digest** — รวม TLS-RPT Report
  • **Google Postmaster Tools** — ดู Deliverability และ TLS Status
  • **dnsviz.net** — ตรวจสอบ DNS Chain และ Certificate
  • สรุปและ Call-to-Action

    MTA-STS และ TLS-RPT คือชั้นความปลอดภัยอีเมลที่องค์กรไทยมักลืมตั้งค่า แม้จะมี SPF, DKIM, DMARC แล้วก็ตาม การ Implement ทั้งคู่ใช้ความพยายามเพียงไม่กี่ชั่วโมง แต่ช่วยลดความเสี่ยงจาก MITM, Downgrade Attack และทำให้องค์กรปฏิบัติตาม PDPA ได้ตรงมาตรฐานสากล

    Key Takeaways:

  • MTA-STS บังคับ TLS และ Validate Certificate ระหว่าง Mail Server
  • TLS-RPT ให้ข้อมูลเชิงลึกว่าใครส่งอีเมลมาไม่ผ่าน TLS
  • เริ่มจาก mode: testing 30 วันก่อน Enforce เสมอ
  • MTA-STS เป็นทางเลือกที่เหมาะกับ SME กว่า DANE
  • หากคุณต้องการให้ทีม ADS FIT ช่วยออกแบบและ Deploy Email Security ทั้งชุด (SPF, DKIM, DMARC, MTA-STS, TLS-RPT) รวมถึงระบบ Monitoring อีเมลองค์กร [ติดต่อเราเลยวันนี้](/contact) หรืออ่านบทความเพิ่มเติมเกี่ยวกับ [Email Authentication](/blog) และ [Network Security](/blog)

    Tags

    #MTA-STS#TLS-RPT#Email Security#Transport Security#DNS#Enterprise

    สนใจโซลูชันนี้?

    ปรึกษาทีม ADS FIT ฟรี เราพร้อมออกแบบระบบที่ฟิตกับธุรกิจของคุณ

    ติดต่อเรา →

    บทความที่เกี่ยวข้อง