ระบบ SPF และ DKIM อาจล่มได้แม้ไม่ได้แก้ DNS
การตั้งค่าอีเมลแอดเดรสครั้งเดียวไม่เพียงพอ เพราะการเปลี่ยนแปลงจากภายนอกและการเพิ่มบริการใหม่สามารถทำให้ SPF และ DKIM ล้มเหลวได้โดยที่คุณไม่ได้แตะต้อง DNS
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การตั้งค่า SPF และ DKIM แบบครั้งเดียวอาจล่มได้ภายหลังแม้ไม่ได้แก้ไข DNS
- การใช้ include อาจทำให้ยอดการค้นหา DNS เกินขีดจำกัด 10 ครั้งตามมาตรฐาน RFC 7208
- การลบ CNAME ที่ผู้ให้บริการใช้หมุนเวียนคีย์อาจทำให้ระบบเซ็นชื่อ DKIM พังอย่างเงียบๆ
- การเพิ่มบริการภายนอกโดยไม่มีการตั้งค่า SPF และ DKIM จะส่งผลกระทบเมื่อเปลี่ยนนโยบายเป็น quarantine หรือ reject
การตั้งค่าการยืนยันตัวตนอีเมลเพียงครั้งเดียวเปรียบเสมือนภาพถ่ายในเวลาใดเวลาหนึ่ง บันทึกที่คุณเผยแพร่อาจยังคงเหมือนเดิมทุกประการในระดับไบต์ แต่ผลลัพธ์การตรวจสอบอาจเปลี่ยนแปลงไปได้ เนื่องจากองค์ประกอบหลายส่วนของการตรวจสอบนั้นอยู่นอกเหนือเขตข้อมูล DNS ของคุณเอง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ปัญหาแรกเกิดจากการใช้คำสั่ง include ซึ่งดึงบันทึกของโดเมนอื่นเข้ามา และอาจมีการซ้อนทับโดเมนอื่นๆ เพิ่มเติม ตามมาตรฐาน RFC 7208 ส่วน 4.6.4 กำหนดให้ SPF อนุญาตกลไกการสืบค้น DNS สูงสุด 10 ครั้งต่อการประเมิน หากผู้ให้บริการที่คุณดึงข้อมูลมาเพิ่มคำสั่ง include ของตัวเองเข้าไป ยอดรวมการสืบค้นของคุณอาจเกิน 10 ครั้งทันทีโดยที่คุณไม่ได้แก้ไขอะไรเลย ฝ่ายผู้รับจดหมายจึงส่งค่า permerror กลับมาและทำให้ SPF ล้มเหลวในที่สุด
คุณสามารถตรวจสอบและนับจำนวนแบบเรียกซ้ำได้ด้วยคำสั่งต่างๆ ดังนี้
- dig +short TXT example.com
- dig +short TXT _spf.provider.example
ให้ทำซ้ำขั้นตอนนี้สำหรับทุกคำสั่ง include ที่คุณพบ โดยกลไกประเภท ip4, ip6 และ all จะไม่เสียค่าใช้จ่ายในการสืบค้นเพิ่มเติม
ในมุมมองด้านความปลอดภัยและการดูแลระบบไอที การตั้งค่าอีเมลในปัจจุบันมีความซับซ้อนมากกว่าแค่การบันทึกค่าพื้นฐาน การพึ่งพาบริการภายนอก (Third-party services) เช่น เครื่องมือการตลาดหรือระบบช่วยเหลือลูกค้า ทำให้โดเมนของเรามีความเสี่ยงจากปัจจัยภายนอกที่ควบคุมได้ยาก การตรวจสอบระบบอัตโนมัติและการอ่านรายงานรวบรวม (Aggregate Reports) จึงเป็นหัวใจสำคัญในการป้องกันไม่ให้อีเมลสำคัญตกไปอยู่ในโฟลเดอร์สแปมโดยไม่รู้ตัว
อีกหนึ่งสาเหตุคือผู้ให้บริการที่ใช้ตัวเลือกแบบ CNAME-delegated ซึ่งสามารถหมุนเวียนคีย์ฝั่งของตนเองได้ หาก CNAME ในโซนของคุณถูกลบระหว่างกระบวนการทำความสะอาด DNS การเซ็นชื่อจะหยุดทำงานอย่างเงียบๆ ทันที
คำสั่งสำหรับตรวจสอบ CNAME และ TXT มีดังนี้
- dig +short CNAME selector1._domainkey.example.com
- dig +short TXT selector1._domainkey.example.com
หากผลลัพธ์ว่างเปล่าสำหรับตัวเลือกที่คุณยังคงใช้เซ็นชื่ออยู่ หมายความว่าอีเมลจากผู้ส่งรายนั้นจะแสดงสถานะ dkim=fail หรือ dkim=none ทันที
นอกจากนี้ ทีมการตลาดมักจะเพิ่มเครื่องมือจดหมายข่าว และทีมซัพพอร์ตอาจเพิ่มระบบช่วยเหลือลูกค้า แต่บริการเหล่านี้ไม่ได้อยู่ใน SPF และไม่ได้เซ็นชื่อด้วยโดเมนของคุณ ภายใต้นโยบาย p=none จะยังไม่มีสิ่งใดเสียหายให้เห็นชัดเจน จนกระทั่งวันที่นโยบายถูกเปลี่ยนไปเป็น quarantine หรือ reject อีเมลเหล่านั้นจะเริ่มร่วงลงสู่ถังขยะสแปมหรือตีกลับทันที
รายงานรวบรวมที่ส่งไปยังที่อยู่ rua= ของคุณจะแสดงรายการ IP ต้นทางทั้งหมดพร้อมผลลัพธ์การจัดวาง SPF และ DKIM หากพบแหล่งที่มาที่ไม่รู้จัก หรือแหล่งที่มาคุ้นเคยแต่จู่ๆ ก็แสดงสถานะ fail นั่นคือสัญญาณเตือนว่ามีบางอย่างเปลี่ยนแปลงไป การตรวจสอบเหล่านี้ทำได้ง่ายในตอนแรก แต่ปัญหาคือไม่มีใครทำซ้ำอย่างสม่ำเสมอ ซึ่งเป็นเหตุผลว่าทำไมโดเมนเดียวกันจึงอาจมีสุขภาพดีในเดือนกันยายนแต่กลับส่งอีเมลเด้งในเดือนพฤศจิกายน
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น