ตั้ง DKIM ให้ Google Workspace: ส่งเมลได้ยังไม่แปลว่าลายเซ็นผ่าน

การตั้ง DKIM ให้ Google Workspace ต้องสร้างคีย์ของโดเมนใน Admin console เพิ่มคีย์สาธารณะเป็นระเบียน TXT ใน DNS แล้วกลับมาเปิด Start authentication งานจะเสร็จเมื่อเมลที่ส่งออกมีลายเซ็น และส่วนหัวของข้อความที่ผู้รับได้รับแสดงผลตรวจ DKIM ผ่านสำหรับโดเมนที่ต้องการ การส่งถึงกล่องจดหมายหรือการเห็น TXT ในหน้าจัดการ DNS ยังบอกผลตรวจลายเซ็นไม่ได้

ตรวจแยกกันเป็นสองช่วง: ชื่อระเบียนและคีย์ต้องเผยแพร่ให้ระบบภายนอกค้นพบก่อน จากนั้นข้อความที่ส่งผ่านเส้นทางใช้งานจริงต้องถูกลงลายเซ็นและตรวจผ่าน หาก DNS ถูกต้องแต่ผลในเมลไม่ผ่าน จุดที่ต้องดูต่อคือสถานะใน Admin console, selector ที่ปรากฏในลายเซ็น และบริการที่ส่งข้อความนั้นจริง

สร้างคีย์ให้ตรงโดเมนและเลือก selector

คู่มือ DKIM ของ Google Workspace ให้ผู้ดูแลสร้างคีย์ เพิ่ม TXT แล้วจึงกด Start authentication ก่อนตรวจผลจากเมลที่ผู้รับได้รับ ลงชื่อเข้า Admin console ด้วยบัญชีผู้ดูแลระบบระดับสูง ไปที่ Apps > Google Workspace > Gmail > Authenticate email เลือกโดเมนในช่อง Selected domain แล้วกด Generate new record เลือกโดเมนให้ตรงกับที่อยู่ผู้ส่งที่จะทดสอบ เพราะคีย์ของแต่ละโดเมนต้องสร้างแยกกัน

หากเพิ่งเปิด Gmail ให้องค์กร ระบบอาจยังไม่ยอมสร้างคีย์ทันที โดยช่วงรอที่ Google ระบุคือ 24–72 ชั่วโมง สำหรับความยาวคีย์ ให้เลือก 2048 บิตเมื่อผู้ให้บริการ DNS รองรับ และเลือก 1024 บิตเมื่อผู้ให้บริการไม่รองรับคีย์ที่ยาวกว่า เมื่อกด Generate แล้ว Admin console จะแสดงทั้ง DNS host name และ TXT record value ซึ่งต้องคัดลอกไปใช้เป็นคู่เดียวกัน

selector คือชื่อที่กำกับว่าผู้รับควรค้นคีย์สาธารณะรายการใด ค่าเริ่มต้นของ Google คือ google จึงมักได้ชื่อระเบียน google._domainkey หากชื่อนี้มีคีย์ที่ใช้อยู่ ให้กำหนด selector อื่นขณะสร้างระเบียนและยึดชื่อที่ Admin console แสดงจริง อย่านำค่า TXT ตัวอย่างจากคู่มือหรือคีย์ของอีกโดเมนมาใช้ เพราะลายเซ็นที่สร้างด้วยคีย์ส่วนตัวชุดหนึ่งต้องตรวจด้วยคีย์สาธารณะที่เข้าคู่กัน

TXT record value มักเริ่มด้วย v=DKIM1; k=rsa; p= แล้วตามด้วยคีย์สาธารณะยาวต่อเนื่อง คัดลอกค่าให้ครบและระวังช่องว่างที่แทรกเข้าไปโดยไม่ได้ตั้งใจ หากผู้ให้บริการ DNS จำกัดความยาวของข้อความในช่อง TXT ให้ตรวจวิธีป้อนค่าของผู้ให้บริการนั้นก่อนบันทึก การตัดท้ายคีย์เพื่อให้ใส่ได้จะทำให้ข้อมูลที่เผยแพร่ไม่ตรงกับคีย์ใน Admin console

เพิ่ม TXT ใน DNS ทั่วไปหรือ Cloudflare

ในระบบ DNS ทั่วไป ให้เปิดโซนของโดเมนที่ใช้ส่งเมลและสร้างระเบียนชนิด TXT ช่อง Host หรือ Name ใส่ DNS host name ที่ได้จาก Google ส่วนช่อง Value ใส่ TXT record value ทั้งชุด ตรวจรูปแบบชื่อที่ผู้ให้บริการต้องการด้วย บางระบบรับชื่อย่อย google._domainkey แล้วเติมชื่อโดเมนให้อัตโนมัติ ขณะที่บางระบบให้ใส่ชื่อเต็ม การใส่ชื่อเต็มในระบบที่เติมท้ายให้อยู่แล้วอาจสร้างระเบียนผิดชื่อ

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

สำหรับโดเมนที่ใช้ Cloudflare ให้เข้า DNS > Records เลือก Add record กำหนด Type เป็น TXT ใส่ selector ที่ Google แสดงในช่อง Name และวางคีย์ในช่อง Content คู่มือ DNS ของ Cloudflare ระบุว่า MX และ TXT เป็น DNS-only อยู่แล้ว จึงไม่มี proxy ให้เปิดหรือปิดสำหรับระเบียน DKIM อย่าใส่คีย์ไว้ที่ @ ซึ่งเป็นชื่อรากของโดเมนในตัวอย่างระเบียน SPF; DKIM ต้องอยู่ใต้ชื่อ selector._domainkey

หากจัดการหลายโดเมนในบัญชี Google Workspace เดียวกัน สามารถใช้ระเบียนบางชนิดร่วมเป็นแบบตั้งต้นได้ แต่ค่า DKIM เป็นคีย์เฉพาะของแต่ละโดเมน ต้องสร้างและเพิ่มแยกกัน การย้ายผู้ให้บริการ DNS ก็ต้องย้ายระเบียน DKIM ไปยังโซนใหม่ด้วย โดยตรวจชื่อและค่าจาก Admin console ปัจจุบัน ไม่อาศัยเพียงสำเนาระเบียนเก่าที่อาจไม่ใช่คีย์ที่ใช้งานแล้ว

ตรวจ DNS จากภายนอกก่อนเปิดการลงลายเซ็น

หลังบันทึก TXT ให้ถาม DNS ด้วยชื่อเต็มของระเบียน แทนการดูเฉพาะรายการในแผงควบคุม สำหรับตัวอย่างสมมติข้างต้น ใช้คำสั่ง dig +short TXT google._domainkey.example.com หรือ nslookup -type=TXT google._domainkey.example.com แล้วเปลี่ยน example.com เป็นโดเมนจริง ผลควรแสดงค่าที่ขึ้นต้นด้วย v=DKIM1 และมีคีย์สาธารณะตรงกับค่าที่ Admin console ให้มา

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

เมื่อพบ TXT ที่ชื่อถูกต้องแล้ว ให้กลับไปเลือกโดเมนเดิมที่ Apps > Google Workspace > Gmail > Authenticate email และกด Start authentication เมื่อระบบทำงาน สถานะจะแสดง Authenticating email with DKIM ข้อความเตือนให้ปรับ DNS ในหน้านี้อาจค้างอยู่ได้ถึง 48 ชั่วโมงหลังเพิ่มคีย์ และการยืนยัน DKIM อาจใช้เวลาถึง 48 ชั่วโมงจึงเริ่มทำงาน ระหว่างรอให้เทียบผล DNS กับคีย์ที่แสดงอยู่ แทนการสร้างคีย์ใหม่ซ้ำโดยไม่มีหลักฐานว่าคีย์เดิมผิด

ส่งเมลใหม่แล้วอ่านผลที่ฝั่งผู้รับ

ส่งเมลใหม่จากบัญชีในโดเมนที่ตั้งค่าไปยังผู้รับที่ใช้ Gmail หรือ Google Workspace อีกบัญชีหนึ่ง การส่งข้อความกลับหาตัวเองใช้ยืนยันว่าเปิด DKIM แล้วไม่ได้ เมื่อข้อความถึงผู้รับ ให้เปิดเมลในกล่องขาเข้า กดเมนูเพิ่มเติมข้างปุ่มตอบกลับ แล้วเลือก Show original เพื่อดูส่วนหัวเต็ม ผลในส่วนหัวนี้เป็นการประเมินข้อความจริงที่ผ่านเส้นทางส่งเมล ไม่ใช่เพียงสถานะการตั้งค่าของฝั่งส่ง

มองหา Authentication-Results และผล dkim=pass หรือ dkim=OK จากนั้นดูว่าเป็นผลของโดเมนใด ในส่วนหัว DKIM-Signature ค่า d= บอกโดเมนที่ลงลายเซ็น ส่วน s= บอก selector ที่ใช้ค้นคีย์ ตัวอย่างสมมติของ example.com อาจแสดง d=example.com และ s=google โดยผู้รับตรวจได้ dkim=pass หากผลผ่านเป็นของอีกโดเมนหนึ่ง ต้องแยกออกจากผลของโดเมนที่กำลังตั้งค่า

ควรตรวจข้อความใหม่หลังเปิด Start authentication เพราะเมลที่ส่งก่อนหน้านั้นไม่ใช่ตัวอย่างของสถานะปัจจุบัน หากไม่มี DKIM-Signature หรือไม่มีผล DKIM ในส่วนหัว ให้ย้อนดูว่ากดเปิดใช้กับโดเมนถูกตัวและข้อความออกผ่าน Google Workspace ตามที่ตั้งใจหรือไม่ หากมีลายเซ็นแต่ตรวจไม่ผ่าน ให้เทียบ s= กับชื่อ TXT ที่ค้นได้ และเทียบคีย์ที่ DNS ตอบกับค่าใน Admin console ก่อนเปลี่ยนการตั้งค่าอื่น

เส้นทางส่งมีผลต่อการแปลผลด้วย เมลที่ออกจากบริการส่งจดหมายภายนอกอาจใช้คีย์และ selector ของบริการนั้น ไม่ได้ใช้คีย์ที่สร้างสำหรับ Gmail ใน Google Workspace ส่วนเกตเวย์ขาออกที่แก้เนื้อหาหลังข้อความถูกลงลายเซ็น เช่น เพิ่มข้อความท้ายเมล อาจทำให้การตรวจลายเซ็นล้มเหลว จึงควรใช้ข้อความที่ออกจากเส้นทางเดียวกับงานจริงในการทดสอบ

แยกอาการผิดพลาดออกจากผล SPF และ DMARC

อาการที่พบช่วยระบุว่าจะตรวจ DNS, การเปิดใช้ หรือเส้นทางส่งก่อน การเปลี่ยนคีย์พร้อมกับแก้หลายระเบียนทำให้ตามสาเหตุได้ยาก:

• ค้น TXT ไม่พบ: ตรวจชื่อเต็มของ selector._domainkey และดูว่าผู้ให้บริการเติมชื่อโดเมนซ้ำหรือไม่ จากนั้นยืนยันว่ากำลังแก้ DNS ของโซนที่เผยแพร่จริง
• TXT พบแล้ว แต่สถานะยังไม่เปิดใช้: กลับไปเลือกโดเมนที่ถูกต้องใน Admin console และกด Start authentication หากเพิ่งเพิ่มระเบียน ให้เผื่อเวลาให้ DNS และสถานะอัปเดต
• เมลทดสอบไม่มีลายเซ็น DKIM: ตรวจว่าเมลถูกส่งหลังเปิดใช้ และตรวจบริการหรือเกตเวย์ที่ส่งข้อความจริง บริการภายนอกอาจต้องตั้งการลงลายเซ็นแยกต่างหาก
• มีลายเซ็นแต่ dkim=fail: เทียบค่า s= กับชื่อระเบียนที่ค้นได้ เทียบคีย์สาธารณะกับค่าใน Admin console แล้วตรวจว่ามีระบบแก้เนื้อหาข้อความหลังลงลายเซ็นหรือไม่
• dkim=pass แต่ DMARC ไม่ผ่าน: ตรวจโดเมนใน d= เทียบกับโดเมนในช่อง From ผล DKIM ที่ผ่านสำหรับโดเมนอื่นอาจไม่เข้าเงื่อนไขการจับคู่โดเมนของ DMARC

SPF ตรวจสิทธิ์ของเซิร์ฟเวอร์ที่ส่งโดยอาศัยโดเมนผู้ส่งระดับระบบ ส่วน DKIM ให้ผู้รับตรวจลายเซ็นของข้อความด้วยคีย์สาธารณะใน DNS ดังนั้น spf=pass ใช้แทน dkim=pass ไม่ได้ และการที่เมลเข้ากล่องขาเข้าก็ไม่ได้แสดงว่าทั้งสองวิธีผ่าน หากใช้ผู้ส่งภายนอกหลายบริการ ต้องพิจารณาว่าแต่ละบริการลงลายเซ็นด้วยโดเมนใด แทนการดูผลจากเมลที่ส่งผ่าน Gmail เพียงเส้นทางเดียว

คำแนะนำ DMARC ของ Google อธิบายว่าข้อความจะผ่าน DMARC ได้เมื่อ SPF หรือ DKIM ผ่านพร้อมกับจับคู่โดเมนกับช่อง From ตามเกณฑ์ที่กำหนด จึงเป็นไปได้ที่ DMARC ผ่านด้วย SPF แม้ DKIM ยังล้มเหลว และเป็นไปได้ที่ DKIM ผ่านแต่ DMARC ไม่ผ่านเพราะโดเมนไม่สัมพันธ์กัน หากเริ่มใช้นโยบาย DMARC ให้ใช้ p=none ระหว่างตรวจรายงานและผู้ส่งที่ใช้งานจริง ก่อนพิจารณา p=quarantine หรือ p=reject สำหรับงานตั้ง DKIM ผลที่ต้องเห็นคือ dkim=pass ของโดเมนที่ตั้งค่าในข้อความที่ผู้รับได้รับ

อ่านเพิ่มเติม:

• Google Workspace หรือ Microsoft 365: AI ที่แถมมาอาจไม่ใช่ตัวที่ทีมต้องใช้