DomainKeys ได้รับการคุ้มครองโดยสิทธิบัตรของสหรัฐอเมริกาหมายเลข 6,986,049 ^ซึ่งหมดอายุแล้ว Yahoo! ได้อนุญาตให้ใช้สิทธิบัตรภายใต้รูปแบบใบอนุญาตแบบคู่: ข้อตกลงใบอนุญาตสิทธิบัตร DomainKeys v1.2 [ ^{9 ]}หรือใบอนุญาตสาธารณะทั่วไปของ GNU v2.0 (และไม่มีเวอร์ชันอื่น ) ^{[ 10 ] [ 11 ]}

โดยพื้นฐานแล้ว ทั้ง DKIM และSPF ต่าง ก็มีมาตรการที่แตกต่างกันในการตรวจสอบ ความถูกต้องของอีเมล DMARCFrom: ช่วยให้องค์กรสามารถเผยแพร่นโยบายที่ระบุว่าจะใช้กลไกใด (DKIM, SPF หรือทั้งสองอย่าง) เมื่อส่งอีเมลจากโดเมนนั้น วิธีการตรวจสอบ ฟิลด์ที่แสดงต่อผู้ใช้ปลายทาง วิธีที่ผู้รับควรจัดการกับความล้มเหลว และกลไกการรายงานสำหรับการดำเนินการภายใต้นโยบายเหล่านั้น^{[ 12 ]}

DKIM เป็นวิธีการติดฉลากข้อความ และตัวมันเองไม่ได้กรองหรือระบุสแปม อย่างไรก็ตาม การใช้ DKIM อย่างแพร่หลายสามารถป้องกันผู้ส่งสแปมจากการปลอมแปลงที่อยู่ต้นทางของข้อความ ซึ่งเป็นเทคนิคที่พวกเขามักใช้ในปัจจุบัน หากผู้ส่งสแปมถูกบังคับให้แสดงโดเมนต้นทางที่ถูกต้อง เทคนิคการกรองอื่นๆ ก็จะทำงานได้อย่างมีประสิทธิภาพมากขึ้น โดยเฉพาะอย่างยิ่ง โดเมนต้นทางสามารถป้อนเข้าสู่ระบบชื่อเสียงเพื่อระบุสแปมได้ดียิ่งขึ้น ในทางกลับกัน DKIM สามารถทำให้การระบุอีเมลที่ทราบว่าไม่ใช่สแปมและไม่จำเป็นต้องกรองทำได้ง่ายขึ้น หากระบบรับมีรายการโดเมนผู้ส่งที่ดีที่ทราบอยู่แล้ว ไม่ว่าจะได้รับการดูแลในพื้นที่หรือจากผู้รับรองบุคคลที่สาม ระบบก็สามารถข้ามการกรองอีเมลที่ลงนามจากโดเมนเหล่านั้น และอาจกรองอีเมลที่เหลืออย่างเข้มงวดมากขึ้น^{[ 13 ]}

DKIM มีประโยชน์ในฐานะเทคโนโลยีป้องกันฟิชชิงผู้ส่งอีเมลในโดเมนที่มีการฟิชชิงอย่างหนักสามารถลงนามในอีเมลของตนเพื่อแสดงว่าเป็นของแท้ ผู้รับสามารถตีความการไม่มีลายเซ็นที่ถูกต้องในอีเมลจากโดเมนเหล่านั้นว่าเป็นข้อบ่งชี้ว่าอีเมลนั้นน่าจะเป็นของปลอม วิธีที่ดีที่สุดในการกำหนดชุดของโดเมนที่สมควรได้รับการตรวจสอบในระดับนี้ยังคงเป็นคำถามที่เปิดกว้าง DKIM เคยมีฟีเจอร์เสริมที่เรียกว่าADSPซึ่งช่วยให้ผู้เขียนที่ลงนามในอีเมลทั้งหมดสามารถระบุตัวตนได้ แต่ถูกลดระดับเป็นสถานะในอดีตในเดือนพฤศจิกายน 2013 ^{[ 14 ]}ในทางกลับกันDMARCสามารถใช้เพื่อวัตถุประสงค์เดียวกันได้^{[ 15 ]}และอนุญาตให้โดเมนเผยแพร่เทคนิค (รวมถึงSPFและ DKIM) ที่พวกเขาใช้ ซึ่งทำให้ผู้รับสามารถตัดสินใจได้อย่างมีข้อมูลมากขึ้นว่าอีเมลใดเป็นสแปมหรือไม่^{[ 16 ]}ตัวอย่างเช่น การใช้ DMARC ทั้งeBayและPayPalต่างก็เผยแพร่นโยบายที่ระบุว่าอีเมลทั้งหมดของพวกเขาจะต้องได้รับการตรวจสอบความถูกต้อง และขอให้ระบบรับอีเมลใดๆ เช่นGmailปฏิเสธอีเมลใดๆ ที่ไม่ได้รับการตรวจสอบความถูกต้อง^{[ 17 ]}

เนื่องจากมีการใช้งานโดยใช้ระเบียน DNS และฟิลด์ส่วนหัว RFC 5322 เพิ่มเติม DKIM จึงเข้ากันได้กับโครงสร้างพื้นฐานอีเมลที่มีอยู่ โดยเฉพาะอย่างยิ่ง ระบบอีเมลที่มีอยู่ซึ่งไม่รองรับ DKIM จะโปร่งใส^{[ 18 ]}

แนวทางการออกแบบนี้ยังเข้ากันได้กับบริการอื่นๆ ที่เกี่ยวข้อง เช่นมาตรฐานการปกป้องเนื้อหาS/MIMEและOpenPGP นอกจากนี้ DKIM ยังเข้ากันได้กับมาตรฐาน DNSSECและSPF อีก ด้วย

DKIM กำหนดให้ต้องสร้าง checksum การเข้ารหัสสำหรับแต่ละข้อความที่ส่งผ่านเซิร์ฟเวอร์อีเมล ซึ่งส่งผลให้เกิดภาระการคำนวณที่ไม่จำเป็นสำหรับการส่งอีเมล ภาระการคำนวณเพิ่มเติมนี้เป็นลักษณะเด่นของตราประทับดิจิทัล ทำให้การส่งสแปมจำนวนมากมีค่าใช้จ่าย (ในการคำนวณ) มากขึ้น^{[ 19 ]} ลักษณะนี้ของ DKIM อาจดูคล้ายกับhashcashยกเว้นว่าการตรวจสอบฝั่งผู้รับเป็นงานที่น้อยมาก ในขณะที่อัลกอริทึม hashcash ทั่วไปจะต้องใช้ความพยายามมากกว่ามาก

คุณสมบัติ การปฏิเสธความรับผิดชอบของ DKIM ป้องกันไม่ให้ผู้ส่ง (เช่น สแปมเมอร์) ปฏิเสธได้อย่างน่าเชื่อถือว่าไม่ได้ส่งอีเมล ซึ่งพิสูจน์แล้วว่ามีประโยชน์ต่อแหล่งข่าวอย่างWikiLeaksซึ่งสามารถใช้ลายเซ็นเนื้อหา DKIM เพื่อพิสูจน์ว่าอีเมลที่รั่วไหลนั้นเป็นของแท้และไม่ได้ถูกดัดแปลง^{[ 20 ]}ในทางปฏิบัติ การตรวจสอบอีเมลเก่าจำนวนมากทำได้ยากเนื่องจากการหมุนเวียนคีย์และความยากลำบากในการค้นหาคีย์ดั้งเดิมก่อนการหมุนเวียน เนื่องจากไม่มีการเผยแพร่ที่ใดเลย วิธีหนึ่งในการตรวจสอบอีเมลเก่าคือการใช้คลังข้อมูลที่รวบรวมลายเซ็นและตัวเลือกจากอีเมลที่มีอยู่ และสามารถกู้คืนคีย์สาธารณะที่หมดอายุจากคู่ลายเซ็นที่ทำโดยคีย์เดียวกันได้^{[ 21 ]}

Matthew D. Greenถือว่าการไม่สามารถปฏิเสธได้เป็นคุณสมบัติที่ไม่พึงประสงค์ของ DKIM ซึ่งถูกบังคับโดยพฤติกรรมต่างๆ เช่นที่ได้อธิบายไว้ข้างต้น อันที่จริง โปรโตคอล DKIM กำหนดให้มีการหมดอายุ มี แท็ก x ที่เป็นตัวเลือก ในแต่ละลายเซ็น ซึ่งกำหนดเวลาหมดอายุอย่างเป็นทางการ อย่างไรก็ตาม ผู้ตรวจสอบสามารถเพิกเฉยได้ นอกจากนี้ เจ้าของโดเมนสามารถเพิกถอนคีย์สาธารณะได้โดยการลบข้อมูลการเข้ารหัสออกจากบันทึก ซึ่งจะป้องกันการตรวจสอบลายเซ็น เว้นแต่จะมีคนบันทึกข้อมูลคีย์สาธารณะไว้ก่อนหน้านี้ การหมุนเวียนคีย์ DKIM มักได้รับการแนะนำเพื่อลดผลกระทบของคีย์ที่ถูกบุกรุก อย่างไรก็ตาม เพื่อปิดใช้งานการไม่สามารถปฏิเสธได้อย่างแน่นอน คีย์ลับที่หมดอายุแล้วสามารถเผยแพร่ได้ ซึ่งจะทำให้ทุกคนสามารถสร้างลายเซ็นปลอมได้ จึงทำให้ความสำคัญของลายเซ็นดั้งเดิมเป็นโมฆะ^{[ 22 ] [ 23 ] [ 24 ]}

โดยค่าเริ่มต้น การเผยแพร่อีเมลที่ถูกแก้ไขจะไม่สามารถตรวจสอบได้ เนื่องจากไม่สามารถสร้างแฮชเนื้อหา DKIM ได้ อย่างไรก็ตาม คุณยังสามารถตรวจสอบอีเมลดังกล่าวได้ หากเจ้าของสร้างหลักฐานความรู้เป็นศูนย์ของลายเซ็น DKIM บนส่วนหัวหรือข้อความเนื้อหาที่ถูกปิดบังไว้ ในขณะที่จำกัดส่วนที่เปิดเผยให้ตรงกับข้อความที่ลงนาม การใช้งานมักใช้ regex หรือการปิดบังเพื่อซ่อนหรือแสดงเนื้อหาที่เลือก หลักฐานนี้สามารถให้แทนลายเซ็น DKIM แก่บุคคลที่สามเพื่อให้ทุกคนสามารถตรวจสอบความถูกต้องของอีเมลได้^{[ 25 ]}หลักฐานเหล่านี้ยังสามารถสร้างขึ้นในเครื่องของผู้ใช้ได้ เพื่อไม่ให้ข้อมูลที่ถูกแก้ไขถูกส่งไปยังบุคคลที่สาม สามารถใช้เพื่อสร้างกระดานข้อความนิรนามที่ปลอดภัยด้วยข้อมูลประจำตัวที่เป็นส่วนตัว แต่มีการตรวจสอบความสัมพันธ์ เช่น Blind ที่เป็นส่วนตัวอย่างสมบูรณ์ นอกจากนี้ยังสามารถใช้เมื่อจำเป็นต้องตรวจสอบความถูกต้องของการอ้างสิทธิ์ของผู้ส่ง แต่ผู้รับต้องการคงความเป็นนิรนาม

ดังที่กล่าวไว้ข้างต้น การตรวจสอบสิทธิ์ไม่เหมือนกับการป้องกันการละเมิด ผู้ใช้อีเมลที่เป็นอันตรายของโดเมนที่มีชื่อเสียงสามารถเขียนข้อความที่ไม่ดีและให้มีการลงนาม DKIM แล้วส่งจากโดเมนนั้นไปยังกล่องจดหมายใดก็ได้ที่พวกเขาสามารถดึงข้อมูลเป็นไฟล์ได้ เพื่อให้ได้สำเนาข้อความที่ลงนามแล้ว การใช้ แท็ก lในลายเซ็นทำให้การแก้ไขข้อความดังกล่าวทำได้ง่ายยิ่งขึ้น จากนั้นสำเนาที่ลงนามแล้วสามารถส่งต่อไปยังผู้รับนับล้านคน เช่น ผ่านบอทเน็ตโดยไม่มีการควบคุม ผู้ให้บริการอีเมลที่ลงนามในข้อความสามารถบล็อกผู้ใช้ที่กระทำผิดได้ แต่ไม่สามารถหยุดการแพร่กระจายของข้อความที่ลงนามแล้วได้ ความถูกต้องของลายเซ็นในข้อความดังกล่าวสามารถจำกัดได้โดยการรวมแท็กเวลาหมดอายุไว้ในลายเซ็นเสมอ หรือโดยการเพิกถอนคีย์สาธารณะเป็นระยะ หรือเมื่อได้รับการแจ้งเตือนเกี่ยวกับเหตุการณ์ ประสิทธิภาพของสถานการณ์แทบจะไม่สามารถจำกัดได้ด้วยการกรองอีเมลขาออก เนื่องจากนั่นหมายถึงความสามารถในการตรวจจับว่าข้อความอาจเป็นประโยชน์ต่อผู้ส่งสแปมหรือไม่^{[ 28 ]}

ปัจจุบัน DKIM มี อัลกอริ ธึมการทำให้เป็นมาตรฐาน สองแบบ คือแบบง่ายและแบบผ่อนปรนซึ่งทั้งสองแบบไม่ได้คำนึงถึงMIME ^{[ 29 ]} เซิร์ฟเวอร์อีเมลสามารถแปลงเป็นชุดอักขระอื่นได้อย่างถูกต้องตามกฎหมาย และมักจะบันทึกสิ่งนี้ไว้ในฟิลด์ส่วนหัว นอกจากนี้ ในบางสถานการณ์ เซิร์ฟเวอร์ต้องเขียนโครงสร้าง MIME ใหม่ ซึ่งจะทำให้คำนำคำลงท้ายและขอบเขตของเอนทิตีเปลี่ยนแปลงไป ซึ่งทั้งหมดนี้จะทำให้ลายเซ็น DKIM เสียหาย มีเพียงข้อความธรรมดาที่เขียนด้วยus-ascii เท่านั้น โดยที่ฟิลด์ส่วนหัว MIME ไม่ได้รับการลงนาม^{[ 30 ]}ที่จะได้รับความทนทานที่ความสมบูรณ์แบบ end-to-end ต้องการX-MIME-Autoconverted:

โครงการ OpenDKIM ได้รวบรวมข้อมูลที่เกี่ยวข้องกับเซิร์ฟเวอร์อีเมล 21 เครื่องและข้อความหลายล้านข้อความ ลายเซ็นที่สังเกตได้ 92.3% ได้รับการตรวจสอบสำเร็จ ซึ่งอัตราความสำเร็จนี้ลดลงเล็กน้อย (90.5%) เมื่อพิจารณาเฉพาะการรับส่งข้อมูลของรายชื่อผู้รับอีเมลเท่านั้น^{[ 31 ]}

ในเดือนตุลาคม 2012 นิตยสาร Wiredรายงานว่า แซค แฮร์ริส นักคณิตศาสตร์ ตรวจพบและสาธิตช่องโหว่การปลอมแปลงแหล่งที่มาของอีเมลด้วยคีย์ DKIM สั้นๆ สำหรับgoogle.comโดเมนขององค์กร รวมถึงโดเมนสำคัญอื่นๆ อีกหลายโดเมน เขาชี้แจงว่า การตรวจสอบสิทธิ์ด้วยคีย์ 384 บิต สามารถถอดรหัสได้ภายในเวลาเพียง 24 ชั่วโมง "บนแล็ปท็อปของเขา" และคีย์ 512 บิต ใช้เวลาประมาณ 72 ชั่วโมง ด้วยทรัพยากรการประมวลผลบนคลาวด์ แฮร์ริสพบว่าหลายองค์กรลงนามอีเมลด้วยคีย์สั้นๆ ดังกล่าว เขาจึงถอดรหัสคีย์เหล่านั้นทั้งหมดและแจ้งให้องค์กรเหล่านั้นทราบถึงช่องโหว่ เขาชี้แจงว่า คีย์ 768 บิต สามารถถอดรหัสได้ด้วยการเข้าถึงพลังการประมวลผลจำนวนมหาศาล ดังนั้นเขาจึงแนะนำว่า การลงนาม DKIM ควรใช้ความยาวคีย์มากกว่า 1,024 บิต

Wiredระบุว่า Harris รายงาน และ Google ยืนยันว่าพวกเขาเริ่มใช้คีย์ที่ยาวขึ้นใหม่หลังจากที่เขาเปิดเผยข้อมูลไม่นาน ตาม RFC 6376 ฝ่ายผู้รับจะต้องสามารถตรวจสอบลายเซ็นด้วยคีย์ที่มีความยาวตั้งแต่ 512 บิตถึง 2048 บิต ดังนั้นการใช้คีย์ที่สั้นกว่า 512 บิตอาจไม่เข้ากันและควรหลีกเลี่ยง RFC 6376 ยังระบุด้วยว่าผู้ลงนามต้องใช้คีย์ที่มีความยาวอย่างน้อย 1024 บิตสำหรับคีย์ที่มีอายุการใช้งานยาวนาน แม้ว่าอายุการใช้งานที่ยาวนานจะไม่ได้ระบุไว้ก็ตาม^{[ 36 ]}

DomainKeysดั้งเดิมได้รับการออกแบบโดย Mark Delany จาก Yahoo! และได้รับการปรับปรุงแก้ไขผ่านความคิดเห็นจากบุคคลอื่นๆ อีกมากมายนับตั้งแต่ปี 2004 มีการระบุไว้ใน RFC 4870 ฉบับประวัติศาสตร์ ซึ่งต่อมาถูกแทนที่ด้วย RFC 4871 ฉบับมาตรฐาน DomainKeys Identified Mail (DKIM) Signatures ทั้งสองฉบับเผยแพร่ในเดือนพฤษภาคม 2007 หลังจากนั้นได้มีการรวบรวมคำชี้แจงและแนวคิดต่างๆ และระบุไว้ใน RFC 5672 เดือนสิงหาคม 2009 ในรูปแบบของการแก้ไขข้อกำหนดที่มีอยู่ ในเดือนกันยายน 2011 RFC 6376 ได้รวมและปรับปรุงเอกสารสองฉบับหลังเข้าด้วยกัน โดยยังคงรักษาสาระสำคัญของโปรโตคอล DKIM ไว้ ความเข้ากันได้ของคีย์สาธารณะกับ DomainKeys รุ่นก่อนหน้าก็เป็นไปได้เช่นกัน

DKIM ถูกพัฒนาขึ้นครั้งแรกโดยกลุ่มผู้เชี่ยวชาญในอุตสาหกรรมที่ไม่เป็นทางการ จากนั้นจึงถูกส่งไปปรับปรุงและกำหนดมาตรฐานโดยคณะทำงาน DKIM ของIETF ซึ่งมี Barry Leibaและ Stephen Farrell เป็นประธาน โดยมี Eric Allmanจากsendmail , Jon CallasจากPGP Corporation , Mark Delany และ Miles Libbey จากYahoo!และ Jim Fenton กับ Michael Thomas จากCisco Systemsเป็นผู้เขียนหลัก

การพัฒนารหัสต้นฉบับของไลบรารีทั่วไปหนึ่งรายการนั้นดำเนินการโดยโครงการ OpenDKIMโดยปฏิบัติตามการเพิ่มโปรโตคอลล่าสุด และได้รับอนุญาตภายใต้ใบอนุญาต New BSD ^{[ 53 ]}