วิธีการตั้งค่าระเบียน DKIM, SPF และ DMARC สำหรับเซิร์ฟเวอร์ Zimbra

DKIM, SPF และ DMARC แก้ปัญหาการตรวจสอบความถูกต้องของอีเมลขาออกในสามส่วนที่แตกต่างกัน และการใช้งาน Zimbra ที่เชื่อถือได้จำเป็นต้องให้ระบบเหล่านี้ทำงานร่วมกัน SPF จะบอกผู้รับว่าระบบใดบ้างที่ได้รับอนุญาตให้ส่งอีเมลโดยใช้โดเมนซองจดหมายของคุณ DKIM เพิ่มลายเซ็นเข้ารหัสลับที่เชื่อมโยงกับโดเมน DMARC ตรวจสอบว่าข้อมูลประจำตัว SPF หรือ DKIM ที่ผ่านการตรวจสอบนั้นตรงกับโดเมนที่ปรากฏในส่วนหัว From ของข้อความหรือไม่ จากนั้นจึงเผยแพร่นโยบายการจัดการและการรายงาน

รายละเอียดมาตรฐานปัจจุบันข้อหนึ่งที่สำคัญคือ ณ เดือนตุลาคม 2026 ข้อกำหนดโปรโตคอล DMARC ที่ใช้งานอยู่คือRFC 9989ซึ่งเผยแพร่ในเดือนพฤษภาคม 2026 ข้อกำหนดนี้ได้ยกเลิก RFC 7489 ฉบับเก่าและเปลี่ยนแปลงรายละเอียดการใช้งานบางอย่าง รวมถึงการทำให้pctแท็กเก่ากลายเป็นแท็กประวัติศาสตร์และเพิ่มtแท็กสำหรับการทดสอบ สิ่งนี้สำคัญหากคุณกำลังคัดลอกตัวอย่าง DMARC เก่าจากคู่มือ Zimbra หรือบทเรียน DNS ก่อนหน้านี้

สิ่งที่คุณต้องมีก่อนเปลี่ยน DNS

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

ความเข้าใจผิดที่พบบ่อยคือ การเผยแพร่บันทึกสำหรับโฮสต์ Zimbra เพียงอย่างเดียวนั้นเพียงพอแล้ว ความจริงแล้วจะเพียงพอเฉพาะเมื่อ Zimbra เป็นผู้ส่งที่ได้รับอนุญาตเพียงรายเดียวเท่านั้น SPF จะถูกประเมินจากข้อมูลประจำตัว SMTP และ DMARC อาจเปิดเผยผู้ส่งบุคคลที่สามที่ถูกลืมไปเมื่อเปิดใช้งานการบังคับใช้ การดำเนินการ: ตรวจสอบแหล่งที่มาขาออกทั้งหมดก่อนที่จะเผยแพร่นโยบาย SPF หรือ DMARC ที่เข้มงวด

ขั้นตอนที่ 1: สร้างคีย์ DKIM ใน Zimbra

Zimbra มีzmdkimkeyutilเครื่องมือสำหรับการลงนาม DKIM ระดับโดเมน เอกสารอย่างเป็นทางการของ Zimbra ระบุให้ใช้งานบนเซิร์ฟเวอร์ MTA หากต้องการเพิ่มข้อมูล DKIM สำหรับโดเมนที่ยังไม่มี ให้เปลี่ยนไปใช้บัญชี Zimbra แล้วเรียกใช้คำสั่งต่อไปนี้:

su - zimbra
/opt/zimbra/libexec/zmdkimkeyutil -a -d example.com

คำสั่งนี้จะจัดเก็บข้อมูล DKIM ในรายการโดเมน LDAP ของ Zimbra และพิมพ์ตัวเลือกและระเบียน TXT สาธารณะที่คุณต้องเผยแพร่เอกสารเกี่ยวกับการลงนาม DKIM ของ Zimbra ยังอธิบาย-qถึงวิธีการสอบถามข้อมูล DKIM ที่มีอยู่-uการอัปเดต และ-rการลบข้อมูลอีก ด้วย

สำหรับการติดตั้ง Zimbra รุ่นใหม่ ผลลัพธ์อาจแตกต่างจากตัวอย่างที่คุณเห็นทางออนไลน์ในเรื่องค่าตัวเลือก (selector) ตัวเลือกไม่ควรเป็นคำตายตัว เช่นdefaultหรือzimbraให้ใช้ตัวเลือกที่เซิร์ฟเวอร์ของคุณแสดงออกมาอย่างถูกต้อง วิธีแก้ไข: คัดลอกระเบียนคีย์สาธารณะทั้งหมดจากผลลัพธ์คำสั่งของคุณ แทนที่จะสร้างขึ้นใหม่ด้วยตนเอง

ขั้นตอนที่ 2: เผยแพร่ระเบียน DKIM TXT

ตัวตรวจสอบ DKIM จะค้นหาคีย์สาธารณะใน DNS ภายใต้ชื่อที่สร้างขึ้นจากตัวเลือกและ._domainkeyกลไกนี้ถูกกำหนดไว้ในRFC 6376ในทางปฏิบัติสำหรับผู้ให้บริการ DNS เรคอร์ดมักจะมีลักษณะดังนี้:

การป้อนชื่อเต็มYOUR_SELECTOR._domainkeyหรือชื่อเต็ม ขึ้นอยู่กับแผงควบคุม DNS ของคุณ ผู้ให้บริการบางรายจะเพิ่มชื่อโซนโดยอัตโนมัติ คำแนะนำ: ตรวจสอบชื่อระเบียนแบบเต็มสุดท้ายในผู้ให้บริการของคุณก่อนบันทึก เพื่อ ป้องกันYOUR_SELECTOR._domainkey.example.comการสร้างชื่อระเบียนที่ไม่ถูกต้องโดยไม่ได้ตั้งใจ...example.com.example.com

ขั้นตอนที่ 3: สร้างระเบียน SPF TXT หนึ่งรายการสำหรับโดเมนผู้ส่ง

SPF จะถูกเผยแพร่เป็นระเบียน DNS TXT ในโดเมนที่คุณต้องการอธิบายสิทธิ์การส่งอีเมลRFC 7208กำหนดให้ต้องมีระเบียน TXT สำหรับ SPF และระบุว่าการมีระเบียน SPF หลายรายการในชื่อเจ้าของเดียวกันจะทำให้เกิดข้อผิดพลาดถาวร กล่าวอีกนัยหนึ่งคือ อย่าสร้างv=spf1ระเบียน TXT รายการที่สองเพียงเพราะคุณเพิ่มบริการอีเมลอื่น

หากเซิร์ฟเวอร์ Zimbra ของคุณส่งข้อมูลโดยตรงจากที่อยู่ IPv4 สาธารณะที่เสถียรเพียงแห่งเดียว ตัวอย่างที่ง่ายที่สุดคือ:

v=spf1 ip4:203.0.113.10 -all

หากโฮสต์ทั้งหมดที่อ้างอิงโดยระเบียน MX ของโดเมนของคุณเป็นผู้ส่งอีเมลขาออกที่ถูกต้อง คุณอาจใช้ได้mxแต่หากบริการของบุคคลที่สามเผยแพร่โดเมนที่รวม SPF คุณอาจต้องใช้include:กลไกอื่น ระเบียนที่แน่นอนนั้นขึ้นอยู่กับการใช้งาน ดังนั้นจึงไม่มีสตริง SPF ของ Zimbra ที่ถูกต้องเพียงสตริงเดียวในทุกกรณี

อีกหนึ่งข้อผิดพลาดที่พบบ่อยคือการคิดว่าการใช้ การ ~allคัดกรองที่เข้มงวดนั้นปลอดภัยกว่าการใช้-allการคัดกรองที่เข้มงวดเสมอไป คำถามที่แท้จริงคือ รายชื่อผู้ส่งที่ได้รับอนุญาตของคุณครบถ้วนหรือไม่ การใช้การคัดกรอง -allที่เข้มงวดนั้นเหมาะสมเมื่อรายชื่อนั้นครบถ้วนแล้ว การดำเนินการ: อนุญาตผู้ส่งที่ถูกต้องตามกฎหมายทั้งหมดในบันทึก SPF เดียว ตรวจสอบในสภาพแวดล้อมการใช้งานจริง จากนั้นเลือกตัวคัดกรองขั้นสุดท้ายallโดยอิงจากหลักฐานนั้น

รักษาความเรียบง่ายของ SPF ให้เหมาะสม RFC 7208 จำกัดกลไกและตัวแก้ไขที่กระตุ้นการค้นหา DNS ไว้ที่ 10 ระหว่างการประเมิน การเกินขีดจำกัดอาจส่งผลให้เกิดข้อpermerrorผิดพลาด การดำเนินการ: นับจำนวน include และกลไกการขยาย DNS อื่นๆ ก่อนที่จะเพิ่มผู้ให้บริการรายอื่น

ขั้นตอนที่ 4: เผยแพร่ DMARC ในโหมดตรวจสอบก่อน

นโยบาย DMARC เผยแพร่อยู่ที่นี่_dmarc.example.comบันทึกข้อมูลเบื้องต้นที่ควรระมัดระวังคือ:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=noneขอให้ผู้รับอย่าเปลี่ยนแปลงวิธีการจัดการตามนโยบาย DMARC ในขณะที่คุณกำลังรวบรวมข้อมูล ที่อยู่ruaอีเมลนี้ขอรายงานสรุป โดยรูปแบบรายงานสรุปปัจจุบันระบุไว้ในRFC 9990ควรใช้กล่องจดหมายหรือบริการรายงานที่สามารถประมวลผลรายงาน DMARC ได้ แทนที่จะใช้กล่องจดหมายส่วนตัวที่ไม่มีผู้ดูแล

อย่าคัดลอก ตัวอย่างการใช้งาน pct=10, pct=25, หรือตัวอย่างที่คล้ายคลึงกันจากบทความเก่าๆ โดยไม่คิดไตร่ตรอง RFC 9989 ถือเป็นเอกสารpctสำคัญทางประวัติศาสตร์ เนื่องจากประสบการณ์การใช้งานจริงแสดงให้เห็นถึงการนำไปใช้ที่ไม่สอดคล้องกัน มาตรฐานปัจจุบันใช้t=yสำหรับการทดสอบพฤติกรรมเมื่อจำเป็น การดำเนินการ: เริ่มต้นด้วยp=noneและวิเคราะห์รายงาน อย่าพึ่งพาการสุ่มตัวอย่างตามเปอร์เซ็นต์เป็นกลไกความปลอดภัยของคุณ

ขั้นตอนที่ 5: ตรวจสอบความถูกต้องของข้อมูลทั้งสามรายการในระบบ DNS สาธารณะ

หลังจากผู้ให้บริการ DNS เผยแพร่ระเบียนแล้ว ให้สอบถามระเบียนเหล่านั้นจากภายนอกเซิร์ฟเวอร์หลัก หรือจากตัวแก้ไขที่สามารถเข้าถึง DNS สาธารณะได้ ตัวอย่างเช่น:

dig +short TXT example.com
dig +short TXT YOUR_SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com

สำหรับ SPF ให้ตรวจสอบว่ามีเพียงการตอบกลับ TXT เดียวที่ขึ้นต้นด้วยv=spf1ที่มีชื่อเจ้าของนั้น สำหรับ DKIM ให้ตรวจสอบว่าตัวเลือกตรงกับค่าที่ Zimbra จัดเก็บไว้ในปัจจุบัน สำหรับ DMARC ให้ตรวจสอบว่ามีระเบียนนโยบาย DMARC ที่ใช้งานได้เพียงรายการเดียวที่ชื่อที่คาดไว้

การเผยแพร่ DNS ขึ้นอยู่กับผู้ให้บริการของคุณ ค่า TTL และแคชของตัวแก้ไข DNS การเปลี่ยนแปลงที่ปรากฏทันทีบนเนมเซิร์ฟเวอร์หลักอาจยังคงถูกแคชไว้ที่อื่น การดำเนินการ: ทดสอบกับตัวแก้ไขสาธารณะอิสระอย่างน้อยหนึ่งตัวก่อนที่จะตำหนิ Zimbra สำหรับคำตอบเก่า

ขั้นตอนที่ 6: ส่งข้อความจริงและตรวจสอบความถูกต้องของการยืนยันตัวตน

ส่งข้อความจากโดเมน Zimbra ไปยังกล่องจดหมายบนผู้ให้บริการรายอื่น แล้วตรวจสอบส่วนหัวของข้อความทั้งหมด ผลลัพธ์ที่สำเร็จโดยปกติควรแสดงลายเซ็น DKIM และ/หรือผลลัพธ์ SPF ที่ผ่าน รวมถึง DMARC ที่ผ่านด้วย เนื่องจากอย่างน้อยหนึ่งข้อมูลประจำตัวที่ได้รับการตรวจสอบสิทธิ์ตรงกับโดเมน From ที่มองเห็นได้

ตรงนี้เองที่ความเข้าใจผิดอีกประการหนึ่งปรากฏให้เห็น: DMARC ไม่จำเป็นต้องผ่านทั้ง SPF และ DKIM แต่ต้องการเพียงแค่ผ่านการตรวจสอบความถูกต้องของข้อมูลประจำตัว SPF หรือผ่านการตรวจสอบความถูกต้องของข้อมูลประจำตัว DKIM เท่านั้น RFC 9989 กำหนดให้การจัดเรียงแบบผ่อนปรนเป็นค่าเริ่มต้นสำหรับทั้งสองอย่างaspfถึงadkimแม้ว่าคุณจะสามารถขอการจัดเรียงแบบเข้มงวดได้ด้วยsการดำเนินการ: ตรวจสอบAuthentication-Resultsและระบุให้แน่ชัดว่ากลไกใดที่ให้การผ่านการตรวจสอบความถูกต้องของ DMARC

ขั้นตอนที่ 7: เปลี่ยนจากการติดตามตรวจสอบไปเป็นการบังคับใช้กฎหมายก็ต่อเมื่อรายงานต่างๆ ไม่มีข้อผิดพลาด

เมื่อข้อมูล DMARC ของคุณแสดงว่าผู้ส่งที่ถูกต้องได้ยืนยันตัวตนและสอดคล้องกันอย่างถูกต้องแล้ว คุณสามารถเปลี่ยนนโยบายเป็นp=quarantineหรือในที่สุดก็เป็น ได้p=rejectในมาตรฐานปัจจุบัน , none, quarantineและrejectแสดงถึงการประเมินของเจ้าของโดเมนเกี่ยวกับการใช้งานที่ไม่ได้รับการตรวจสอบสิทธิ์ แต่ผู้รับยังคงมีดุลยพินิจในการจัดการในระดับท้องถิ่น

อย่ามองว่าp=rejectDMARC เป็นการเพิ่มประสิทธิภาพการส่งอีเมล DMARC เป็นเครื่องมือหลักในการตรวจสอบความถูกต้องและควบคุมการใช้โดเมนในทางที่ผิด ไม่ได้ทำให้เมลที่ต้องการส่งน่าเชื่อถือโดยอัตโนมัติหรือรับประกันว่าจะส่งถึงกล่องจดหมายเข้า การดำเนินการ: ควรบังคับใช้โดยพิจารณาจากความปลอดภัยตามความครอบคลุมของการตรวจสอบความถูกต้อง ไม่ใช่การรับประกันว่าอีเมลจะส่งถึงกล่องจดหมายเข้าในอัตราที่สูงขึ้น

ขั้นตอนที่ 8: หมุนเวียนคีย์ DKIM โดยไม่ต้องลบระเบียน DNS เก่าทันที

ในการอัปเดตข้อมูล DKIM สำหรับโดเมน Zimbra มีเอกสารดังต่อไปนี้:

/opt/zimbra/libexec/zmdkimkeyutil -u -d example.com

คำสั่งนี้จะสร้างข้อมูล DKIM ที่อัปเดตแล้วและสร้างรายการ DNS ใหม่ Zimbra แนะนำเป็นพิเศษให้คงระเบียน TXT เดิมไว้ใน DNS เป็นระยะเวลาหนึ่ง เพื่อให้ข้อความที่ลงนามด้วยคีย์เดิมยังคงสามารถตรวจสอบได้ในระหว่างการส่งหรืออยู่ในคิว ขั้นตอน: เผยแพร่ตัวเลือกใหม่ก่อน ตรวจสอบความถูกต้อง และเก็บตัวเลือกเดิมไว้ชั่วคราวก่อนที่จะลบออก

ข้อมูลอ้างอิงโดยย่อ: แต่ละสถิติพิสูจน์อะไรบ้าง

สิ่งที่ควรตรวจสอบเกี่ยวกับประเทศซิมบับเวโดยเฉพาะ

คำแนะนำเกี่ยวกับการปกป้องอีเมลของ Zimbra ระบุว่าต้องสร้าง DKIM สำหรับแต่ละโดเมนและเผยแพร่ใน DNS สาธารณะของแต่ละโดเมน นอกจากนี้ยังกล่าวถึงปัญหาการจัดเรียงที่อาจเกิดขึ้นกับบุคลิกบางอย่างหรือพฤติกรรมการตอบกลับอัตโนมัติในการกำหนดค่ารุ่นเก่า รายละเอียดเหล่านั้นเป็นไปตามสถานการณ์มากกว่าจะเป็นสากล: หากการใช้งานของคุณใช้นามแฝง บุคลิก รีเลย์ หรือการเขียนทับซองจดหมายที่ไม่ปกติ ให้ทดสอบเส้นทางข้อความเหล่านั้นแยกต่างหาก

สำหรับการติดตั้ง Zimbra แบบหลายโดเมน ให้ทำการตั้งค่า DKIM และการเผยแพร่ DNS ซ้ำสำหรับแต่ละโดเมนที่ส่งข้อมูล SPF และ DMARC ก็เป็นนโยบายโดเมนเช่นกัน อย่าคิดว่าเรคอร์ดในโดเมนที่โฮสต์อยู่โดเมนหนึ่งจะครอบคลุมโดเมนอื่นที่ไม่เกี่ยวข้องโดยอัตโนมัติ การดำเนินการ: สร้างเมทริกซ์ทดสอบขนาดเล็กสำหรับทุกโดเมนและทุกเส้นทางขาออกก่อนที่จะเปิดใช้งานการบังคับใช้ DMARC อย่างเข้มงวด

รายการตรวจสอบการตรวจสอบขั้นสุดท้าย

• มีระเบียน SPF เพียงหนึ่งรายการที่ขึ้นต้นด้วยv=spf1ที่โดเมนผู้ส่งแต่ละโดเมน
• บันทึก SPF ประกอบด้วยเส้นทางขาออกที่ได้รับอนุญาตทั้งหมด และอยู่ภายในขีดจำกัดการประมวลผล DNS ของ SPF
• Zimbra กำลังลงนามอีเมลขาออกโดยใช้ตัวเลือกที่จัดเก็บไว้สำหรับโดเมนนั้น
• คีย์สาธารณะ DKIM ที่ตรงกันจะปรากฏให้เห็นใน DNS สาธารณะภายใต้selector._domainkey.
• ระเบียน DMARC TXT ได้รับการเผยแพร่ที่_dmarc.domainและใช้ไวยากรณ์ปัจจุบัน
• ข้อความทดสอบจากภายนอกแสดงให้เห็นว่าการตรวจสอบ SPF หรือ DKIM ผ่านเกณฑ์ และดังนั้นจึงผ่านการตรวจสอบ DMARC ด้วย
• รายงานโดยรวมจะได้รับการตรวจสอบก่อนที่จะเปลี่ยนสถานะจากเฝ้าระวังไปเป็นการกักกันหรือปฏิเสธ
• ตัวเลือก DKIM เก่าจะถูกเก็บไว้ชั่วคราวในระหว่างการหมุนเวียน และจะถูกลบออกหลังจากช่วงเวลาการเปลี่ยนผ่านสิ้นสุดลงเท่านั้น

หากการตรวจสอบเหล่านี้ผ่าน เซิร์ฟเวอร์ Zimbra ของคุณไม่ได้เพียงแค่เผยแพร่ระเบียน DNS สามรายการเท่านั้น แต่ยังนำเสนอห่วงโซ่การตรวจสอบความถูกต้องที่สอดคล้องกันซึ่งผู้รับระยะไกลสามารถตรวจสอบได้ ความแตกต่างนี้มีความสำคัญมากกว่าการคัดลอกสตริงตัวอย่างใดตัวอย่างหนึ่งจากคู่มือ เพราะแหล่งที่มาของ SPF ที่ถูกต้อง ตัวเลือก DKIM และช่วงเวลาการบังคับใช้ DMARC ขึ้นอยู่กับวิธีการที่อีเมลของคุณออกจากองค์กรจริง ๆ