MTA-STS: บังคับ TLS ให้อีเมลขาเข้า พร้อมรายงาน TLS-RPT

MTA-STS (SMTP MTA Strict Transport Security ตาม RFC 8461) คือกลไกที่ให้โดเมนประกาศต่อเซิร์ฟเวอร์ผู้ส่งว่า อีเมลที่ส่งมาหาโดเมนนี้ต้องส่งผ่าน TLS ไปยัง MX ที่มีชื่อตรงกับนโยบายและมีใบรับรองที่ถูกต้องเท่านั้น ปกติ SMTP ใช้ STARTTLS แบบ "ถ้าได้ก็ดี" ผู้โจมตีที่อยู่กลางทางจึงตัด STARTTLS ทิ้งแล้วอ่านอีเมลแบบข้อความธรรมดาได้ MTA-STS ปิดช่องนี้

คู่มือนี้เหมาะกับผู้ดูแลโดเมนและระบบอีเมลขององค์กร ไม่ว่าจะใช้เมลเซิร์ฟเวอร์ของตัวเอง Microsoft 365 หรือ Google Workspace เมื่อทำครบ คุณจะมีไฟล์นโยบายที่เผยแพร่ผ่าน HTTPS ระเบียน _mta-sts และ _smtp._tls ใน DNS รายงาน TLS-RPT รายวัน และแผนเปลี่ยนจากโหมด testing เป็น enforce อย่างปลอดภัย

สิ่งที่ต้องเตรียม

• สิทธิ์แก้ DNS ของโดเมน (วิธีตรวจผลดู ตรวจสอบ DNS ด้วย nslookup และ dig)
• เว็บเซิร์ฟเวอร์ที่ให้บริการ HTTPS สำหรับชื่อ mta-sts.example.com ได้ พร้อมใบรับรองจาก CA สาธารณะ เช่น Let's Encrypt
• รายชื่อ MX ทั้งหมดของโดเมน และทุก MX ต้องรองรับ STARTTLS ด้วยใบรับรองที่ตรงกับชื่อโฮสต์ ไม่หมดอายุ และไม่ใช่ self-signed
• กล่องอีเมลรับรายงาน เช่น [email protected]
• ตั้ง SPF, DKIM และ DMARC ไว้แล้ว (MTA-STS ไม่ได้แทนกัน ทำงานคนละด้าน)

กลไกนี้ปกป้องอีเมลขาเข้าของโดเมนคุณ ส่วนอีเมลขาออกจะได้รับการปกป้องเมื่อโดเมนปลายทางตั้งนโยบายไว้และเซิร์ฟเวอร์ผู้ส่งของคุณรองรับการตรวจนโยบาย

ขั้นตอนที่ 1: ตรวจ MX และใบรับรองของทุก MX

ดูรายชื่อ MX แล้วทดสอบ STARTTLS ของแต่ละตัวจากเซิร์ฟเวอร์ที่ออกพอร์ต 25 ได้ (อินเทอร์เน็ตบ้านมักบล็อกพอร์ต 25) ผลต้องแสดงชื่อในใบรับรองตรงกับชื่อ MX และ Verification: OK

dig +short MX example.com
openssl s_client -starttls smtp -connect mail.example.com:25 -verify_hostname mail.example.com -brief </dev/null

ถ้าใช้บริการอีเมลสำเร็จรูป ให้จดชื่อ MX ตามที่ผู้ให้บริการกำหนด เช่น Microsoft 365 ใช้ชื่อลงท้าย mail.protection.outlook.com ซึ่งเขียนในนโยบายเป็น *.mail.protection.outlook.com ได้ ผู้ให้บริการเหล่านี้ดูแลใบรับรองฝั่ง MX ให้แล้ว

ขั้นตอนที่ 2: เขียนไฟล์นโยบายในโหมด testing

สร้างไฟล์ข้อความชื่อ mta-sts.txt โหมด testing หมายถึงผู้ส่งยังส่งอีเมลตามปกติแม้ TLS ไม่ผ่าน แต่จะรายงานปัญหาผ่าน TLS-RPT จึงเป็นจุดเริ่มที่ปลอดภัย

version: STSv1
mode: testing
mx: mail.example.com
mx: backup-mx.example.com
max_age: 86400

• mx: ใส่ทุก MX บรรทัดละหนึ่งชื่อ ใช้ *. แทนหนึ่งระดับซับโดเมนได้ MX ที่ไม่อยู่ในรายการจะถูกมองว่าไม่ผ่านเมื่อเป็น enforce
• max_age: เวลาที่ผู้ส่งจำนโยบายไว้ หน่วยวินาที สูงสุด 31557600 (ประมาณ 1 ปี) ช่วงทดสอบใช้ 86400 (1 วัน)

ขั้นตอนที่ 3: เผยแพร่ไฟล์ผ่าน HTTPS

สร้างระเบียน A ของ mta-sts.example.com ชี้ไปยังเว็บเซิร์ฟเวอร์ เช่น 203.0.113.10 ออกใบรับรองให้ชื่อนี้ แล้ววางไฟล์ให้เปิดได้ที่ https://mta-sts.example.com/.well-known/mta-sts.txt ตัวอย่างสำหรับ Nginx

server {
    listen 443 ssl;
    server_name mta-sts.example.com;
    ssl_certificate     /etc/letsencrypt/live/mta-sts.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.example.com/privkey.pem;
    location = /.well-known/mta-sts.txt {
        root /var/www/sts-policy;
        default_type text/plain;
    }
}

ไฟล์ต้องตอบ HTTP 200 โดยตรง ผู้ส่งจะไม่ตาม redirect ดังนั้นห้ามมีกฎบังคับเปลี่ยนเส้นทางไปหน้าอื่น และใบรับรองต้องถูกต้องเสมอ ถ้าใบรับรองของ mta-sts หมดอายุ ผู้ส่งจะดึงนโยบายใหม่ไม่ได้

ขั้นตอนที่ 4: เพิ่มระเบียน _mta-sts ใน DNS

เพิ่มระเบียน TXT ที่ชื่อ _mta-sts.example.com ค่า v=STSv1; id=20261021T090000 ค่า id เป็นตัวอักษรหรือตัวเลข 1–32 ตัว ใช้วันเวลาจะจำง่าย ผู้ส่งดูค่านี้เพื่อรู้ว่านโยบายเปลี่ยนหรือไม่ ทุกครั้งที่แก้ไฟล์นโยบายต้องเปลี่ยน id ไม่เช่นนั้นผู้ส่งจะใช้นโยบายเดิมที่จำไว้ต่อจนครบ max_age

"summary": {
  "total-successful-session-count": 1520,
  "total-failure-session-count": 3
},
"failure-details": [
  { "result-type": "certificate-host-mismatch",
    "receiving-mx-hostname": "backup-mx.example.com",
    "failed-session-count": 3 }
]