คำศัพท์ · ตรวจสอบ dkim

ตรวจสอบ DKIM สำหรับอีเมลของแอปพลิเคชันอย่างไร

การตรวจสอบ DKIM ที่เชื่อถือได้ใช้ข้อความที่ส่งถึงจริง อ่านเฮดเดอร์ DKIM-Signature ดึงโดเมนที่ลงลายเซ็น (`d=`) และ selector (`s=`) ค้นหาคีย์ DNS ที่ตรงกันที่ `<selector>._domainkey.<domain>` และตรวจสอบเฮดเดอร์กับ body ที่ลงลายเซ็นด้วยการเข้ารหัสลับ จากนั้นตรวจ Authentication-Results ของผู้รับที่เชื่อถือได้ แยกผลของความพร้อมใช้งานของเรคคอร์ด การตรวจสอบลายเซ็น DMARC alignment การยอมรับโดยเซิร์ฟเวอร์ผู้รับ และการเข้ากล่องจดหมายออกจากกัน

ถือการตรวจสอบ DKIM เป็นสี่การทดสอบแยกกัน

การค้นหา DNS อย่างเดียวไม่ใช่การตรวจสอบ DKIM ที่สมบูรณ์ ขั้นแรก ยืนยันว่าข้อความมีฟิลด์ DKIM-Signature และระบุลายเซ็นที่ต้องการทดสอบ ขั้นที่สอง ดึงและแยกวิเคราะห์เรคคอร์ด public key ที่ลายเซ็นนั้นอ้างถึง ขั้นที่สาม ตรวจสอบว่าเฮดเดอร์ที่ลงลายเซ็นและ body ที่ canonicalize แล้วยังตรงกับลายเซ็นเข้ารหัสลับ ขั้นที่สี่ ตัดสินว่าโดเมนลงลายเซ็นที่ผ่านนั้น aligned กับโดเมน From ที่มองเห็นสำหรับ DMARC หรือไม่ แต่ละเลเยอร์ตอบคำถามต่างกัน เรคคอร์ดที่เผยแพร่อาจไม่ถูกใช้ ข้อความอาจอ้าง selector ที่ไม่มี ลายเซ็นอาจล้มเหลวหลังแก้ไขเนื้อหา และการผ่านด้านการเข้ารหัสลับอาจยังไม่ aligned กับโดเมนผู้เขียน ให้บันทึกผลแต่ละอย่างแทนที่จะแสดงเครื่องหมายสีเขียวเดียว และแยกสถานะการขนส่งและกล่องจดหมายออกจากกัน การยอมรับโดยผู้ให้บริการ การยอมรับโดยเซิร์ฟเวอร์ผู้รับ และการเข้ากล่องจดหมายไม่ใช่ผลการตรวจสอบ DKIM

เริ่มจากลายเซ็นบนข้อความจริง

รับข้อความดิบจากผู้รับที่ควบคุมได้ซึ่งได้รับอีเมลผ่านเส้นทางปกติของแอปพลิเคชัน ในแต่ละฟิลด์ DKIM-Signature ให้บันทึกโดเมนลงลายเซ็น `d=` selector `s=` อัลกอริทึม `a=` โหมด canonicalization `c=` รายการเฮดเดอร์ที่ลงลายเซ็น `h=` body hash `bh=` ข้อมูลลายเซ็น `b=` และเวลาเมื่อมี RFC 6376 กำหนดแท็กโดเมนลงลายเซ็นและ selector และใช้แท็กเหล่านี้หา public key อย่าเดา selector จากแดชบอร์ดของผู้ให้บริการ หรือค้นหา `_domainkey` โดยไม่มี selector ข้อความหนึ่งอาจมีหลายลายเซ็นจากผู้ส่ง ตัวกลาง หรือระบบเมลลิงลิสต์ ดังนั้นให้เก็บผลของแต่ละลายเซ็น หลีกเลี่ยงการวางข้อความในระบบจริงลงในเครื่องมือตรวจสอบสาธารณะ เพราะเฮดเดอร์และ body ดิบอาจเปิดเผยผู้รับ ตัวระบุข้อความ รายละเอียดการกำหนดเส้นทาง โทเค็นยกเลิกการรับ และเนื้อหาของแอปพลิเคชัน ใช้พื้นที่จัดเก็บที่จำกัดสิทธิ์และสำเนาวินิจฉัยที่ปกปิดข้อมูลเมื่อไม่จำเป็นต้องใช้เนื้อหาทั้งหมด

ค้นหา selector และโดเมนลงลายเซ็นที่แน่นอน

สร้างชื่อ DNS จากลายเซ็นเป็น `<selector>._domainkey.<signing-domain>` หากเฮดเดอร์มี `s=app2026` และ `d=notify.example.test` ให้ค้นหา TXT ที่ `app2026._domainkey.notify.example.test` บันทึกชื่อเดิม resolver การตอบกลับ TTL และเชน CNAME ใดก็ตาม แยกวิเคราะห์เรคคอร์ดแบบ tag-value ที่ได้ แทนที่จะค้นหาส่วนของข้อความ เรคคอร์ดอาจระบุเวอร์ชัน ชนิดคีย์ ข้อจำกัดของบริการ แฟล็ก อัลกอริทึมแฮช และข้อมูล public key ค่า public key ที่ว่างหมายถึงเพิกถอนคีย์ แยกแยะ NXDOMAIN คำตอบว่าง เนื้อหาที่ผิดรูปแบบ อัลกอริทึมที่ไม่รองรับ คีย์ที่ใช้ไม่ได้ และความล้มเหลวชั่วคราวของ resolver ทำการค้นหาซ้ำหลังเปลี่ยนแปลงเมื่อ TTL หมดอายุผ่าน resolver อิสระ แต่อย่าสมมติว่าผู้รับทุกรายอัปเดตทันที การค้นหา DNS ที่สำเร็จพิสูจน์เพียงว่ามีเรคคอร์ดถูกส่งกลับ ณ ขณะนั้น ไม่ได้พิสูจน์ว่าข้อความที่ทดสอบผ่านการตรวจสอบ หรือผู้ให้บริการกำลังลงลายเซ็นทราฟฟิกปัจจุบันด้วย selector นั้น

ตรวจสอบเฮดเดอร์ body hash และลายเซ็น

การตรวจสอบ DKIM เป็นไปตามกฎ canonicalization ที่ลายเซ็นประกาศไว้ ผู้ตรวจสอบ canonicalize body คำนวณแฮช และเปรียบเทียบกับ `bh=` จากนั้น canonicalize เฮดเดอร์ที่ลงลายเซ็นตามชื่อใน `h=` รวมฟิลด์ DKIM-Signature ตามที่กำหนด และตรวจสอบ `b=` ด้วย public key ให้ใช้ไลบรารีตรวจสอบที่ยังมีการดูแล หรือผลการยืนยันตัวตนที่เชื่อถือได้ของผู้รับ แทนการสร้างการแปลงเหล่านี้ขึ้นใหม่ด้วยการจัดการสตริง body-hash ไม่ตรงกันมักหมายความว่า body เปลี่ยนหลังลงลายเซ็น ส่วนการล้มเหลวของลายเซ็นเฮดเดอร์อาจบ่งชี้การแก้ไขเฮดเดอร์ที่ลงลายเซ็น คีย์ผิด ข้อมูลลายเซ็นเสียหาย หรือข้อผิดพลาดของการนำไปใช้ ให้บันทึกว่าล้มเหลวในขั้นใด ตรวจดูว่าฟิลด์สำคัญ เช่น From, Subject, Date และ Message-ID ถูกลงลายเซ็นหรือไม่ แต่อย่าคิดนโยบายเฮดเดอร์ที่ลงลายเซ็นแบบสากลขึ้นเอง Canonicalization ยอมรับการเปลี่ยนรูปแบบที่กำหนดไว้ แต่ไม่ได้ทำให้การแทรกท้ายข้อความ การเขียน MIME ใหม่ ความเสียหายของตัวจบบรรทัด หรือการแก้ไขระหว่างขนส่งแบบใดก็ตามปลอดภัย

อ่านผลของผู้รับภายในขอบเขตความเชื่อถือของผู้รับ

RFC 8601 กำหนดเฮดเดอร์ Authentication-Results และผล DKIM ได้แก่ none, pass, fail, policy, neutral, temperror และ permerror ผล pass หมายความว่าผู้รับพบลายเซ็นที่ยอมรับได้และผ่านการทดสอบตรวจสอบ temperror อาจสะท้อนเงื่อนไขที่มีแนวโน้มเปลี่ยน เช่น การค้นหาคีย์ล้มเหลวชั่วคราว ส่วน permerror ไม่น่าจะสำเร็จในความพยายามครั้งต่อไปหากไม่แก้ไข บันทึกบริการยืนยันตัวตนที่รายงาน โดเมนลงลายเซ็น selector และอัลกอริทึมเมื่อมีให้ เชื่อถือเฉพาะผลที่แทรกภายในขอบเขตที่ระบบผู้รับระบุไว้ เพราะผู้ส่งเพิ่มฟิลด์ Authentication-Results ปลอมก่อนส่งได้ ตรวจผลที่เชื่อถือได้บนสุดสำหรับสภาพแวดล้อมผู้รับปลายทาง และคำนึงถึงฮ็อปตัวกลาง หากผู้รับต่างรายให้ผลไม่ตรงกัน ให้เปรียบเทียบเวอร์ชันข้อความที่แน่นอน มุมมอง DNS เวลาที่ประเมิน อัลกอริทึมที่รองรับ และนโยบายภายใน อย่าแปลง `dkim=pass` เป็นข้อกล่าวอ้างว่าผู้ให้บริการกล่องจดหมายรับรองเนื้อหาหรือจัดเข้ากล่องจดหมาย

ตรวจ DMARC alignment แยกจากผล DKIM pass

DKIM pass ยืนยันตัวตนโดเมนใน `d=` ไม่ได้กำหนดให้โดเมนนั้นเท่ากับโดเมน From ของ RFC 5322 ที่มองเห็น RFC 9989 ใช้ตัวระบุที่ยืนยันตัวตนด้วย DKIM ที่ผ่านสำหรับ DMARC เฉพาะเมื่อ aligned กับโดเมนผู้เขียนภายใต้โหมด alignment แบบ strict หรือ relaxed ที่ใช้อยู่ ตัวอย่างเช่น ข้อความจาก `billing.example.test` ที่ลงลายเซ็นด้วย `d=provider.test` ผ่าน DKIM ได้แต่ยังไม่ aligned ลายเซ็นที่ถูกต้องจาก `d=example.test` อาจ aligned ภายใต้โหมด relaxed ขึ้นอยู่กับการคำนวณโดเมนองค์กรและนโยบาย ให้รายงานสามฟิลด์ ได้แก่ ผล DKIM โดเมนลงลายเซ็น และการตัดสิน alignment ข้อความยังผ่าน DMARC ได้ผ่าน SPF ที่ aligned เมื่อ DKIM ล้มเหลวหรือไม่ aligned ดังนั้น DMARC pass ไม่ได้พิสูจน์ว่าลายเซ็น DKIM ที่เฉพาะเจาะจงผ่าน แนวทางผู้ส่งของ Gmail ปัจจุบันมีข้อกำหนดด้านการยืนยันตัวตนและ alignment สำหรับทราฟฟิกที่เข้าข่าย แต่การปฏิบัติตามก็ยังไม่รับประกันการยอมรับโดยเซิร์ฟเวอร์ผู้รับหรือการเข้ากล่องจดหมาย

ตรวจสอบอัลกอริทึมปัจจุบันและการหมุนเวียนคีย์

RFC 8301 ปรับปรุงข้อกำหนดด้านการเข้ารหัสลับของ DKIM โดยผู้ลงลายเซ็นต้องใช้ `rsa-sha256` ผู้ตรวจสอบต้องรองรับ และห้ามใช้ `rsa-sha1` นอกจากนี้ยังกำหนดให้คีย์ลงลายเซ็น RSA ยาวอย่างน้อย 1024 บิต พร้อมอธิบายว่าเหตุใดคีย์ที่ใหญ่กว่าจึงดีกว่าเมื่อทำได้ในทางปฏิบัติ เครื่องมือตรวจสอบควรระบุอัลกอริทึมและแจ้งวัสดุที่ล้าสมัยหรือใช้ไม่ได้ โดยไม่อ้างว่าความยาวคีย์อย่างเดียวทำให้สตรีมอีเมลน่าเชื่อถือ เวิร์กโฟลว์ของผู้ให้บริการต่างกัน Amazon SES ระบุว่า Easy DKIM ใช้คีย์ 2048 บิตเป็นค่าเริ่มต้น และเตือนว่าการเปลี่ยนวิธีลงลายเซ็นโดยไม่มีขั้นตอนกลางอาจทำให้มีช่วงที่ข้อความไม่ถูกลงลายเซ็น DKIM วางแผนการหมุนเวียนด้วย selector ที่ถูกต้องสองตัวหรือกลไกซ้อนทับตามที่ผู้ให้บริการระบุ ยืนยันว่าข้อความใหม่ใช้ selector ใหม่ เก็บ public key เก่าไว้ตราบที่อีเมลที่ล่าช้ายังอาจมาถึง และลบเมื่อพ้นช่วงซ้อนทับเท่านั้น ห้ามเผยแพร่คีย์ลงลายเซ็นส่วนตัวใน DNS ล็อก ตั๋ว หรือพรอมต์

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

เมื่อการตรวจสอบล้มเหลว ให้เก็บข้อความดิบและผลจากผู้รับก่อนเปลี่ยน DNS ยืนยันว่าแอปพลิเคชันและผู้ให้บริการที่คาดไว้เป็นผู้สร้างข้อความจริง หากไม่มีลายเซ็น ให้ตรวจว่าเปิดการลงลายเซ็นสำหรับตัวตน ภูมิภาค tenant หรือประเภทข้อความนั้นหรือไม่ หากการค้นหา selector ล้มเหลว ให้เปรียบเทียบค่า `d=` และ `s=` ที่แน่นอน โซน DNS เป้าหมาย CNAME TTL และการหมุนเวียนล่าสุด หากคีย์แยกวิเคราะห์ได้แต่ body hash ล้มเหลว ให้ตรวจเกตเวย์ ท้ายเมลลิงลิสต์ การเขียนทับลิงก์ติดตาม การแปลง MIME ตัวจบบรรทัด และผลิตภัณฑ์ความปลอดภัยที่อาจแก้ไขเนื้อหาหลังลงลายเซ็น หากลายเซ็นเข้ารหัสลับล้มเหลวทั้งที่ body hash ตรงกัน ให้ตรวจการเปลี่ยนแปลงเฮดเดอร์ที่ลงลายเซ็น คีย์ไม่ตรงกัน และการนำไปใช้ของการลงลายเซ็น หาก DKIM ผ่านแต่ DMARC ล้มเหลว ให้ทดสอบ alignment แทนการเผยแพร่คีย์เดิมซ้ำ ทดสอบซ้ำผ่านผู้รับที่ควบคุมได้หลัง TTL หรือการกระจายการกำหนดค่าที่เกี่ยวข้อง และบันทึกหลักฐานสำหรับแต่ละประเภทข้อความ แทนที่จะประกาศว่าทั้งโดเมนแก้ไขแล้วจากตัวอย่างที่สำเร็จเพียงหนึ่งฉบับ

เก็บบันทึกการตรวจสอบ DKIM ที่ตรวจสอบย้อนหลังได้

สำหรับข้อความที่ควบคุมได้ทุกฉบับ ให้เก็บตัวระบุความสัมพันธ์ที่ไม่ละเอียดอ่อน ระบบที่ส่ง บัญชีหรือเวิร์กสเปซของผู้ให้บริการ โดเมน From ที่มองเห็น ระบบผู้รับ เวลาของข้อความ และผลที่สมบูรณ์ของแต่ละลายเซ็น รวม `d=`, `s=`, `a=`, canonicalization, เฮดเดอร์ที่ลงลายเซ็น, ชื่อ DNS ที่ค้นหา, เวลาตอบกลับและ TTL ของ DNS, สถานะเรคคอร์ดคีย์, ผล body hash, ผลลายเซ็น, ค่า Authentication-Results ที่เชื่อถือได้, การตัดสิน DMARC alignment และเจ้าของการแก้ไข เก็บข้อความดิบเฉพาะในที่ที่มีการควบคุมการเข้าถึงและการเก็บรักษาที่เหมาะสม เพิ่มสถานการณ์ทดสอบ ได้แก่ การส่งปกติของแอปพลิเคชัน การย้ายผู้ให้บริการ การหมุนเวียนคีย์ เส้นทางผ่านเกตเวย์ หรือกรณีการส่งต่อ วิธีนี้ทำให้เปรียบเทียบการถดถอยได้ และป้องกันไม่ให้ภาพหน้าจอกลายเป็นหลักฐานถาวรหลัง selector หรือการประมวลผลข้อความเปลี่ยนไป ตรวจซ้ำหลังการตั้งค่าผู้ให้บริการ DNS วิธีลงลายเซ็น การกำหนดเส้นทางเปลี่ยน หรือมีประเภทข้อความใหม่ แดชบอร์ดการดำเนินงานควรแสดงสถานะไม่ทราบและไม่พร้อมใช้งานอย่างชัดเจน แทนที่จะถือว่าเป็น pass หรือ fail โดยไม่แจ้ง

SendHQ เกี่ยวข้องกับการตรวจสอบนี้อย่างไร

SendHQ กำหนดให้ใช้โดเมน From ที่ยืนยันแล้วและมีอีเวนต์การส่ง สำหรับการตรวจสอบ DKIM ให้ส่งข้อความที่ควบคุมได้ผ่านเส้นทางแอปพลิเคชันที่ตั้งใจ ตรวจสอบลายเซ็นที่ได้รับ query ค่า `d=` และ `s=` จริง และบันทึก alignment แยกต่างหาก อย่าอนุมาน selector ความยาว key อัลกอริทึมการลงลายเซ็น การเข้ากล่องจดหมาย หรือการรับประกันการส่งจากเอกสารผลิตภัณฑ์เพียงอย่างเดียว

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

จะหา DKIM selector ได้จากที่ไหน

เปิดข้อความดิบและหาฟิลด์ DKIM-Signature selector คือค่า `s=` และโดเมนที่ใช้ลงลายเซ็นคือค่า `d=` ใช้ทั้งสองค่าสร้าง `<selector>._domainkey.<signing-domain>` สำหรับการค้นหา DNS

การพบเรคคอร์ด DNS ของ DKIM หมายความว่า DKIM ผ่านหรือไม่

ไม่ เรคคอร์ดให้เพียงเนื้อคีย์และแท็กนโยบาย ผู้ตรวจสอบต้องใช้เรคคอร์ดนั้นเพื่อตรวจ body ที่ canonicalize แล้ว เฮดเดอร์ที่ลงลายเซ็น body hash ข้อมูลลายเซ็น และอัลกอริทึมของข้อความนั้นจริง ๆ ให้ทดสอบกับข้อความที่ส่งถึงจริง

DKIM ผ่านแต่ DMARC ล้มเหลวได้หรือไม่

ได้ DKIM ตรวจสอบผ่านด้วยโดเมนลงลายเซ็นที่ไม่ aligned กับโดเมน From ที่มองเห็นได้ DMARC ต้องมีตัวระบุ SPF หรือ DKIM ที่ผ่านและ aligned ภายใต้โหมด alignment ที่ใช้อยู่ ดังนั้นให้รายงานการตรวจสอบและ alignment แยกกัน

อะไรทำให้ DKIM body-hash ไม่ตรงกัน

body ที่ canonicalize แล้วซึ่งผู้ตรวจสอบได้รับต่างจากที่ผู้ลงลายเซ็นแฮชไว้ จุดที่ควรตรวจสอบทั่วไปได้แก่ เกตเวย์ ท้ายข้อความ การเขียนทับลิงก์ติดตาม การแปลง MIME เครื่องมือด้านความปลอดภัย และการเปลี่ยนตัวจบบรรทัดหลังลงลายเซ็น เก็บข้อความที่แน่นอนไว้ก่อนวินิจฉัย

ควรลบ DKIM selector เก่าทันทีหลังหมุนเวียนคีย์หรือไม่

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

DKIM pass พิสูจน์การเข้ากล่องจดหมายหรือไม่

ไม่ เป็นเพียงการตรวจสอบลายเซ็นที่ยอมรับได้สำหรับข้อความที่ทดสอบ ณ ผู้รับที่ประเมิน ผู้รับยังคงใช้สัญญาณด้าน alignment ของการยืนยันตัวตน ชื่อเสียง เนื้อหา การร้องเรียน ผู้รับ และนโยบายภายในเมื่อยอมรับและจัดประเภทอีเมล