ทีมผลิตภัณฑ์ควรตั้งค่า DKIM อย่างปลอดภัยอย่างไร

จัดทำแผนที่เส้นทางขาออกจริงทุกเส้นทางก่อนสร้างคีย์

เริ่มจากรายการสินทรัพย์ ไม่ใช่เรคคอร์ด DNS ระบุทุกระบบที่ส่งอีเมลโดยใช้โดเมน From ที่มองเห็นขององค์กร ได้แก่ worker แอปพลิเคชัน ผู้ให้บริการ transactional แพลตฟอร์มการตลาด เครื่องมือซัพพอร์ต ระบบตัวตน ซอฟต์แวร์ ticketing relay และเส้นทางฉุกเฉิน สำหรับแต่ละระบบ ให้บันทึกเจ้าของ ประเภทข้อความ envelope sender โดเมน From ที่มองเห็น โดเมน DKIM d= ปัจจุบัน selector องค์ประกอบที่ลงลายเซ็น และมี relay อื่นแก้ไขข้อความภายหลังหรือไม่ key DKIM ที่เผยแพร่สำหรับผู้ให้บริการหนึ่งไม่มีผลกับเส้นทางอื่นที่ไม่เคยใช้ private key นั้น เช่นเดียวกัน แดชบอร์ดผู้ให้บริการทั่วไปที่แสดงโดเมนที่ยืนยันแล้วหนึ่งโดเมน ไม่ได้พิสูจน์ว่า tenant region stream เทมเพลต หรือ fallback ทุกส่วนได้รับการลงลายเซ็น ใช้ตัวอย่างที่ควบคุมได้จากทุกเส้นทางและเก็บ header ต้นฉบับ ตัดสินใจว่าเส้นทางใดได้รับอนุญาตก่อนเปิดใช้การลงลายเซ็น DKIM ยืนยันความรับผิดชอบของโดเมนต่อลายเซ็น ไม่ใช่ความยินยอมของผู้รับหรือความจริงของเนื้อหาข้อความ

เลือกโดเมนลงลายเซ็นที่รองรับ DMARC alignment

แท็ก d= ของ DKIM ระบุโดเมนลงลายเซ็น เลือกโดเมนที่องค์กรควบคุมและกำกับดูแลได้ตลอดอายุของสตรีมอีเมล เมื่อ DMARC จะพึ่งพา DKIM โดเมน d= ต้อง aligned กับโดเมนในฟิลด์ From ของ RFC 5322 ที่มองเห็นภายใต้กฎ alignment แบบ relaxed หรือ strict ที่ใช้อยู่ โดเมนลงลายเซ็นที่ผู้ให้บริการเป็นเจ้าของอาจให้ผล DKIM ที่ถูกต้องแต่ยังไม่ aligned กับโดเมน From ขององค์กร ตัดสินว่าจะให้ apex หรือซับโดเมนเฉพาะวัตถุประสงค์ลงลายเซ็นแต่ละสตรีม โดยพิจารณาความเป็นเจ้าของ การแยกชื่อเสียง DNS ที่มอบหมาย และการแยกเหตุการณ์ อย่าสร้างโดเมนเพิ่มเพียงเพื่อหลบปัญหาชื่อเสียงหรือนโยบาย บันทึกความสัมพันธ์ของโดเมนองค์กรและโหมด DMARC ที่ตั้งใจ ทดสอบ alignment จากเฮดเดอร์สุดท้ายที่ได้รับ อย่าอนุมานจากการค้นหา selector เพียงอย่างเดียว เพราะข้อความอาจใช้ค่า d= อื่น

จัดสรร selector เป็นตัวตนในการดำเนินงาน

selector ช่วยให้โดเมนเผยแพร่ key ได้หลายตัวและเปลี่ยนได้โดยไม่ต้องแทนที่เรคคอร์ดส่วนกลาง สร้างนโยบาย selector ที่กำหนดได้แน่นอนซึ่งระบุผู้ให้บริการหรือผู้ลงลายเซ็นและรุ่นการหมุนเวียนโดยไม่เปิดเผยความลับ ตัวอย่างเช่น product-a-2026q3 อาจชัดเจนกว่า default แต่ให้คงชื่อไว้ในแบบแผน DNS และขีดจำกัดของเครื่องมือ อย่าใช้ private key เดียวซ้ำกับผู้ให้บริการ สภาพแวดล้อม หรือ tenant ที่ไม่เกี่ยวข้องกันเพียงเพื่อลดเรคคอร์ด DNS รักษา registry ที่มี selector โดเมน d= วัตถุประสงค์ บริการลงลายเซ็น เจ้าของ เวลาสร้าง อัลกอริทึม fingerprint ของ public key สถานะการปรับใช้ กำหนดเวลาหมุนเวียน และหลักฐานการเลิกใช้ ตรวจสอบชื่อ selector ที่แน่นอนก่อนเผยแพร่: lookup คือ `selector._domainkey.signing-domain` เรคคอร์ดที่วางผิดโดยไม่ตั้งใจที่โดเมน From ที่มองเห็น โดเมน return-path หรือ DNS zone ผิด จะไม่ยืนยันลายเซ็นที่ตั้งใจ หลีกเลี่ยงการลบ selector เก่าจนกว่าอีเมลล่าช้าและการลองใหม่ที่ลงลายเซ็นด้วย selector นั้นจะหมดอายุ

สร้างและปกป้องคีย์ส่วนตัว

สร้างคู่คีย์ภายในบริการจัดการคีย์หรือระบบลงลายเซ็นที่ควบคุมอย่างเข้มงวดเมื่อผู้ให้บริการรองรับ คีย์ส่วนตัวต้องไม่เข้าสู่ DNS สาธารณะ ระบบควบคุมซอร์ส โค้ดเบราว์เซอร์ เอาต์พุต CI ระบบวิเคราะห์ ล็อกทั่วไป ตั๋ว เอกสาร พรอมต์ หรือแชตที่ใช้ร่วมกัน ให้สิทธิ์ลงลายเซ็นเฉพาะส่วนประกอบเมลที่ต้องใช้คีย์ แยกระบบจริงจากสภาพแวดล้อมระดับล่าง และบันทึกการเข้าถึงของผู้ดูแล RFC 8301 ปรับปรุงข้อกำหนดด้านการเข้ารหัสลับของ DKIM และระบุว่าผู้ลงลายเซ็นต้องใช้คีย์ RSA อย่างน้อย 1024 บิต และควรใช้อย่างน้อย 2048 บิต พร้อมระบุข้อจำกัดด้านการดำเนินงานของ DNS สำหรับคีย์ที่ใหญ่กว่า ใช้ความสามารถและคำแนะนำปัจจุบันของผู้ลงลายเซ็นและกลุ่มผู้รับที่เลือก แทนการคัดลอกตัวอย่างที่ล้าสมัย หากพิจารณา Ed25519 RFC 8463 กำหนดการใช้กับ DKIM แต่ต้องทดสอบการทำงานร่วมกัน และคงกลยุทธ์ลายเซ็นที่เข้ากันได้ไว้เมื่อจำเป็น การหมุนเวียนคีย์ต้องทำได้โดยไม่ต้องส่งออกคีย์ส่วนตัว

เผยแพร่ public key ให้ถูกต้องแม่นยำ

เผยแพร่เรคคอร์ด TXT ที่ชื่อ owner `selector._domainkey.signing-domain` ที่แน่นอน เรคคอร์ด key DKIM มี tag เช่น v=DKIM1 ประเภท key หากจำเป็น และ p= ที่มีข้อมูล public key โดยไม่มี wrapper ของ private key ทำตามรูปแบบเรคคอร์ดที่แน่นอนของผู้ลงลายเซ็นและพฤติกรรมการใส่เครื่องหมายคำพูดของผู้ให้บริการ DNS ก่อนบันทึก ตรวจสอบว่าอินเทอร์เฟซ DNS เติม zone โดยอัตโนมัติ แยกสตริงยาว หรือ escape อักขระหรือไม่ query authoritative name server โดยตรงหลังเผยแพร่ จากนั้น query recursive resolver อิสระและประกอบค่า TXT เต็มกลับมา สตริงอักขระหลายสตริงในเรคคอร์ด TXT เดียวถูกต่อกันโดยไคลเอ็นต์ DNS ขณะที่ resource record ที่แข่งขันกันหลายรายการอาจก่อความกำกวม เก็บคำตอบก่อนหน้าและ TTL เพื่อ rollback อย่าลดความปลอดภัยด้วยการเผยแพร่ key ที่กว้างขึ้นหรือปล่อย test flag ไว้ในระบบจริงเพียงเพื่อหยุด checker เรคคอร์ดที่มองเห็นพิสูจน์การเผยแพร่ DNS ไม่ได้พิสูจน์ว่าผู้ส่งใช้ private key ที่ตรงกัน

กำหนดค่าผู้ลงลายเซ็นสุดท้ายและฟิลด์ที่ลงลายเซ็น

กำหนดค่าส่วนประกอบที่ส่งข้อความสุดท้ายให้ระบบขนส่งขาออก หรือทำให้แน่ใจว่าไม่มีส่วนประกอบถัดไปเปลี่ยนเนื้อหาที่ลงลายเซ็น ลายเซ็น DKIM ครอบคลุม body hash และฟิลด์เฮดเดอร์ที่ระบุใน h= RFC 6376 กำหนดให้ต้องลงลายเซ็นฟิลด์เฮดเดอร์ From เพื่อให้ลายเซ็นถูกต้อง ใส่เฮดเดอร์ที่สำคัญต่อตัวตนซึ่งเหมาะกับผลิตภัณฑ์ เข้าใจวิธีเลือกเฮดเดอร์ที่ซ้ำ และหลีกเลี่ยงการลงลายเซ็นฟิลด์ที่ระบบปลายทางที่จำเป็นต้องเขียนใหม่ เว้นแต่การแปลงนั้นควบคุมได้ เลือก canonicalization อย่างตั้งใจ Relaxed canonicalization ยอมรับการเปลี่ยนแปลงช่องว่างและรูปแบบเฮดเดอร์ที่กำหนดไว้ แต่ไม่อนุญาตให้แก้ไข body ตามใจ Simple canonicalization เปราะบางกว่า การแทรกท้ายข้อความ การเขียนทับลิงก์ การเปลี่ยนขอบเขต MIME การแปลง transfer-encoding แท็กในหัวเรื่อง และการปรับตัวจบบรรทัดหลังลงลายเซ็น อาจทำให้การตรวจสอบพัง ลงลายเซ็นข้อความที่เรนเดอร์เสร็จสมบูรณ์หลังการแปลงที่ได้รับอนุมัติ และป้องกันไม่ให้ผู้ใช้ที่ไม่น่าเชื่อถือเลือก d=, s=, รายการเฮดเดอร์ หรือคีย์

ตรวจสอบข้อความต้นฉบับที่ได้รับแบบครบวงจร

ส่งข้อความที่ควบคุมได้ผ่านทุกเส้นทางที่เหมือนระบบจริงไปยังกล่องจดหมายทดสอบภายนอกที่ทีมดูแล เก็บข้อความต้นฉบับดิบ ไม่ใช่ body ที่คัดลอกหรือไฟล์แนบตั๋วที่ serialize ใหม่ ตรวจค่า d= และ s= ของ DKIM-Signature รายการเฮดเดอร์ที่ลงลายเซ็น body hash อัลกอริทึม canonicalization เวลา และวันหมดอายุใด ๆ ค้นหา public key จากเครือข่ายอิสระ และรันตัวตรวจสอบที่เข้าใจมาตรฐานกับไบต์ต้นฉบับ เปรียบเทียบเฮดเดอร์ Authentication-Results ของผู้รับที่เชื่อถือได้กับตัวตรวจสอบของคุณ โดยเคารพขอบเขตความเชื่อถือของ RFC 8601 ทดสอบข้อความธรรมดา multipart alternative ไฟล์แนบที่คาดไว้ หัวเรื่อง Unicode เฮดเดอร์ยาว เทมเพลต การแปลงลิงก์ติดตาม การลองใหม่ และเส้นทางรีเลย์ การทดสอบเชิงลบควรรวมการเปลี่ยนเฮดเดอร์ที่ลงลายเซ็นใน fixture โดยตั้งใจ selector ที่หายไป selector ที่หมดอายุหรือเลิกใช้ และเส้นทางที่ข้ามการลงลายเซ็น ห้ามแก้ไขอีเมลจริงของลูกค้าเพื่อสร้างการทดสอบ

ประเมิน DKIM, DMARC และการส่งถึงเป็นผลแยกกัน

DKIM pass หมายความว่าผู้ตรวจพบลายเซ็นที่ใช้ได้สำหรับโดเมนลงลายเซ็นที่ระบุ ครอบคลุมฟิลด์และ body ที่ลงลายเซ็น ไม่ได้ยืนยัน header ที่ไม่ได้ลงลายเซ็นทุกตัว ยืนยันผู้เขียนที่เป็นมนุษย์ พิสูจน์ความยินยอมของผู้รับ สร้างการปฏิบัติตามกฎหมาย หรือรับประกันการยอมรับและการเข้ากล่องจดหมาย DMARC ประเมินแยกต่างหากว่าโดเมน DKIM หรือ SPF ที่ผ่านมี alignment กับโดเมน From ที่มองเห็นหรือไม่ และใช้นโยบายของเจ้าของโดเมน สำหรับการทดสอบแบบควบคุม ให้บันทึกอย่างน้อยผลและเหตุผล DKIM โดเมน d= selector โดเมน From ที่มองเห็น ผล alignment ผล SPF ผล DMARC ผู้รับ และเวลา อย่าใส่ที่อยู่อีเมลผู้รับเต็มหรือเนื้อหาใน metrics ตามปกติ การยอมรับจากผู้ให้บริการ SMTP การยอมรับจากเซิร์ฟเวอร์ผู้รับ bounce ภายหลัง ตำแหน่งโฟลเดอร์กล่องจดหมาย และ engagement เป็นสถานะภายหลัง หาก DKIM ผ่านแต่อีเมลถูกปฏิเสธหรือกรอง ให้ตรวจสอบ DMARC alignment, SPF ชื่อเสียง IP และโดเมน อัตราการร้องเรียน นโยบายข้อความ อัตรา และคำแนะนำของผู้รับ แทนการหมุน key ซ้ำ ๆ

หมุนเวียนคีย์โดยไม่สร้างช่องว่างของการตรวจสอบ

ใช้ selector ที่ซ้อนทับกัน ขั้นแรกสร้างคีย์ใหม่ที่ได้รับการปกป้องและเผยแพร่เรคคอร์ดสาธารณะภายใต้ selector ใหม่ ตรวจสอบ DNS ทั้งแบบเป็นแหล่งข้อมูลที่เชื่อถือได้และ recursive กำหนดค่าผู้ลงลายเซ็นให้ใช้ selector ใหม่ และส่งการทดสอบที่ควบคุมได้ผ่านทุกเส้นทาง ติดตามสัดส่วนลายเซ็นที่ใช้ selector เก่าและใหม่ และผลการตรวจสอบ เก็บ public key เก่าไว้ตลอดอายุข้อความสูงสุดในคิว ช่วงเวลาลองใหม่ และช่วงแคช DNS บวกส่วนเผื่อความปลอดภัยที่ชัดเจน จากนั้นหยุดลงลายเซ็นทั้งหมดด้วย selector เก่า ยืนยันว่าไม่มีการกำหนดค่าที่ใช้งานอ้างอิงถึง และเลิกใช้เรคคอร์ดตามนโยบาย การเพิกถอนฉุกเฉินหลังคีย์ส่วนตัวรั่วไหลอาจต้องลบเร็วขึ้น หยุดทราฟฟิก หมุนเวียนข้อมูลรับรองของผู้ให้บริการ และสื่อสารเหตุการณ์ ให้บันทึกข้อแลกเปลี่ยนนี้ไว้ล่วงหน้า อย่าเขียนทับ selector เดียวกันในการหมุนเวียนตามปกติ เพราะ public key เก่าที่ถูกแคชอาจทำให้การตรวจสอบล้มเหลวสำหรับข้อความที่ลงลายเซ็นด้วยคีย์ส่วนตัวใหม่

วินิจฉัยความล้มเหลวจากลายเซ็นออกไปด้านนอก

กรณีไม่มีลายเซ็น ให้ระบุว่าข้อความใช้สตรีมที่ไม่ได้ลงลายเซ็น โดเมน From ที่ไม่ได้รับอนุญาต รีเลย์สำรอง หรือเส้นทางเทมเพลตใด กรณีไม่พบคีย์ ให้ตรวจการค้นหา s= และ d= ที่แน่นอน การมอบหมายโซน คำตอบจากแหล่งข้อมูลที่เชื่อถือได้ ข้อผิดพลาด DNSSEC หรือ resolver และการกระจาย กรณี body-hash ไม่ตรงกัน ให้เปรียบเทียบ MIME ดิบก่อนลงลายเซ็นกับที่ได้รับเพื่อหาการแปลงหลังลงลายเซ็น กรณีลายเซ็นไม่ตรงกัน ให้ตรวจสอบว่า public key ที่เผยแพร่ตรงกับคีย์ส่วนตัวที่ใช้งานอยู่ และตรวจ canonicalization กับเฮดเดอร์ที่ลงลายเซ็น กรณี DKIM ผ่านแต่ DMARC ล้มเหลว ให้ประเมิน alignment กับโดเมน From ที่มองเห็น แยกความผิดพลาดในการค้นหา DNS ชั่วคราวออกจากข้อบกพร่องด้านการกำหนดค่าที่คงอยู่ และใช้การลองใหม่ของการขนส่งที่มีขอบเขตเฉพาะเมื่อการตอบกลับ SMTP เป็นแบบชั่วคราว หยุดสตรีมที่ได้รับผลกระทบเมื่อพบการลงลายเซ็นข้ามโดเมน คีย์ที่ไม่รู้จัก ความล้มเหลวในการตรวจสอบในวงกว้าง หรือสงสัยว่าคีย์รั่วไหล เก็บหลักฐานที่ลดข้อมูลส่วนบุคคลและเปลี่ยนตัวแปรเดียวต่อการทดสอบซ้ำที่ควบคุมได้

ใช้เอกสาร DKIM ของระบบส่งอีเมลของคุณ

ตั้งค่า DKIM ในระบบส่งจริงและ DNS authority ตรวจสอบข้อความต้นฉบับที่ได้รับ และอ้างอิงมาตรฐาน IETF ปัจจุบันกับเอกสารเฉพาะของผู้ให้บริการ

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

แหล่งอ้างอิง

• ข้อกำหนด RFC 6376: DomainKeys Identified Mail Signatures — RFC Editor
• ข้อกำหนด RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM — RFC Editor
• ข้อกำหนด RFC 8463: A New Cryptographic Signature Method for DKIM — RFC Editor
• ข้อกำหนด RFC 7489: Domain-based Message Authentication, Reporting, and Conformance — RFC Editor
• ข้อกำหนด RFC 8601: Message Header Field for Indicating Message Authentication Status — RFC Editor
• ข้อกำหนด RFC 5321: Simple Mail Transfer Protocol — RFC Editor