DKIM Record Generator: สร้าง DNS TXT Record สำหรับ DKIM พร้อมแบ่ง chunk 255 ตัวอักษรอัตโนมัติ

ความล้มเหลวของ DKIM เกิดขึ้นแบบเงียบ ๆ เมื่อ DNS TXT record ที่อยู่เบื้องหลัง signature มีปัญหา — chunk เกิน 255 ตัวอักษร, quote หายไป หรือ key ถูกตัดขาด — mail server จะไม่แจ้ง error ให้คุณรู้ แค่ตรวจ signature ไม่ผ่านเฉย ๆ แล้ว deliverability ของคุณก็ทยอยแย่ลงทั้งที่ dashboard ยังขึ้นเขียวหมด ที่สำคัญคือ public key แบบ RSA แทบไม่เคยพอดีกับขีดจำกัดความยาวของ DNS ทำให้ DKIM record เกือบทุกตัวต้องถูกแบ่งเป็นหลาย chunk แบบ quoted และการแบ่งมือคือจุดที่ record พังบ่อยที่สุด

DKIM Record Generator ช่วยกำจัดปัญหากลุ่มนี้ทั้งหมด วาง public key ที่ได้จาก mail provider หรือ openssl ตั้งชื่อ selector แล้วเครื่องมือจะประกอบ TXT record ฉบับเต็ม selector._domainkey ให้ทันที พร้อมตรวจรูปแบบ key, ใส่ tag ให้ถูกต้อง และแบ่ง base64 payload เป็น chunk ที่ปลอดภัยต่อ provider โดยอัตโนมัติ ทุกอย่างประมวลผล 100% ฝั่ง client-side key ของคุณจึงไม่เคยหลุดออกจากเบราว์เซอร์

บทความนี้จะพาใช้งานทีละขั้น อธิบายว่าทำไม TXT string ถึงโดนจำกัดที่ 255 ตัวอักษร การแบ่ง chunk ทำงานอย่างไร และนิสัยการดูแลระยะยาวที่ทำให้ DKIM deployment ของคุณแข็งแรงไปอีกหลายปี

ทำไมต้องใช้ DKIM Record Generator

• แบ่ง chunk 255 ตัวอักษรอัตโนมัติ — เครื่องมือตัด record ที่ขอบเขตที่ถูกต้องพอดี เพื่อให้ตรงข้อกำหนด quoted string ของ DNS provider หลายเจ้า และฝั่งผู้รับต่อกลับได้ครบถ้วน
• ตรวจสอบรูปแบบ key — ตรวจ key ที่วางก่อนสร้าง record เสมอ จับ error คลาสสิกอย่าง PEM header ที่ลืมลบ, ช่องว่างเกิน, ขึ้นบรรทัดใหม่ หรือหลุดวาง private key แทน public key
• รูปแบบ record ถูกต้องทุกครั้ง — ส่งออกโครงสร้างมาตรฐาน v=DKIM1; k=rsa; p=... พร้อม quote ที่เรียบร้อย ไม่ต้องประกอบ record เองอีกต่อไป
• ใช้ได้กับ key จากทุก provider — Gmail, Microsoft 365, Zoho, Mailgun หรือคู่ key ที่สร้างเองด้วย openssl
• ประมวลผล 100% ฝั่ง client-side — key ไม่เคยออกจากเบราว์เซอร์ ไม่อัปโหลด ไม่เก็บ log ไม่ต้องสมัครสมาชิก
• คัดลอกไปใช้ได้ทันที — คลิกเดียวคัดลอก record เต็มหรือแยกทีละ chunk

ฟีเจอร์เด่น

• รองรับ selector ทุกแบบ — ชื่อ record เปลี่ยนตาม selector ที่พิมพ์ จะเป็น s1, google หรือแบบระบุวันที่ก็ใช้ flow เดียวกัน
• ไม่มีการเก็บข้อมูล — ปิดแท็บปุ๊บ key หายปั๊บ ไม่มีการจัดเก็บที่ใดทั้งสิ้น

วิธีใช้งาน

1. เปิดเครื่องมือ DKIM Record Generator แล้ววาง public key ของ DKIM — จะมีหรือไม่มี PEM header ก็ได้
2. ตั้งชื่อ selector ตามที่ provider ระบุ (google, s1, 2026-09) ตัวอย่างจะแสดงชื่อ record ที่แน่นอนให้ทันที
3. ตรวจ record ที่สร้างได้: เครื่องมือ validate key, ประกอบ DKIM tag และแบ่ง key เป็น chunk แบบ quoted ที่ไม่เกิน 255 ตัวอักษร
4. คัดลอก record ไปเพิ่มที่ DNS provider — สร้าง TXT record ด้วยชื่อที่แสดง วางค่าทั้งหมด (ครบทุก chunk ตามลำดับ) แล้วบันทึก
5. ตรวจสอบผล — ส่งอีเมลจริงที่ sign แล้วดู header ฝั่งผู้รับว่ามี DKIM-Signature และผล dkim=pass หรือใช้เครื่องมือ DNS lookup ยืนยันว่าทุก chunk resolve ครบ

DKIM Record กับข้อจำกัด 255 ตัวอักษร

DKIM public record คือ DNS TXT record ที่ publish ที่ชื่อ <selector>._domainkey.<โดเมนของคุณ> ค่าภายในเป็น tag list คั่นด้วยเซมิโคลอน: v=DKIM1 ประกาศเวอร์ชัน, k=rsa ระบุชนิด key และ p= คือ public key แบบ base64 ที่ฝั่งผู้รับใช้ verify signature ส่วน private key ไม่มีวันปรากฏใน DNS — ถ้าไหนเผลอจะ publish ค่าที่มีคำว่า "PRIVATE KEY" อยู่ข้างใน หยุดแล้วเริ่มใหม่ทันที

ข้อจำกัด 255 ตัวอักษรมาจากตัวสเปก DNS เอง: character-string หนึ่งชุดภายใน TXT record ถูกจำกัดที่ 255 octets แต่ RSA key ขนาด 2048-bit เมื่อ encode เป็น base64 จะยาวราว 340–380 ตัวอักษร จึงใส่ string เดียวไม่พอ วิธีแก้คือแบ่งค่าเป็น quoted string ต่อเนื่องกันหลายชุด ซึ่ง resolver จะต่อกลับให้เองตอน lookup ต้องเข้าใจว่านี่ไม่ใช่การสร้าง TXT record แยกหลาย record ที่ชื่อเดียวกัน — แบบนั้นคือกำกวมหรือพังตรง ๆ — แต่เป็น record เดียวที่ค่าประกอบจากหลาย chunk เรียงตามลำดับ บาง DNS console แบ่งให้เอง แต่อีกหลายเจ้าต้องทำเองให้ถูก ซึ่งเป็นสิ่งที่เครื่องมือนี้ทำแทนคุณ

selector คือเครื่องมือแบ่ง namespace ของคุณ โดเมนเดียว publish key ได้หลายตัวพร้อมกัน — แยกตาม platform หรือตามรอบการ generate key — และบอกผู้รับได้ว่า message นั้น sign ด้วย key ตัวไหน ตั้งชื่อให้มีความหมาย (google, mailer2026-09) แล้ววันหน้าต้อง rotate จะง่ายขึ้นเยอะ ลองดูตัวอย่าง record พร้อมคำอธิบาย:

s1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A"
                                      "MIIBCgKCAQEA7k3mQpXv8zR2dJ9hNq5wF2xKvT"
                                      "LmZa0eQ8bAsC3uD1oGnH6yW4rJ7tP9uXsV"

• s1 — selector ฝั่งผู้รับจะไป look up ชื่อนี้เมื่อ header ระบุไว้
• v=DKIM1 — tag ระบุเวอร์ชัน ต้องมา first ในลิสต์
• k=rsa — ตระกูล algorithm ของ key ที่ publish
• p= — ตัว key ถูกแบ่งเป็นสาม quoted string แล้วต่อกลับตอน lookup

แล้ว DKIM อยู่ตรงไหนของครอบครัวนี้? SPF กำหนดว่า server ใดส่งเมลแทนโดเมนได้, DKIM sign ข้อความแต่ละฉบับแบบเข้ารหัสลับเพื่อให้รอดจากการ forward และ DMARC บอกผู้รับว่าถ้าเช็คไม่ผ่านจะทำอย่างไรและส่งรายงานไปที่ใด DKIM อย่างเดียวจำเป็นแต่ไม่พอ — deployment จะแข็งแรงก็ต่อเมื่อมีทั้งสามอย่างพร้อม aligned กัน

Use Cases ในทางปฏิบัติ

ตั้งค่าอีเมลให้โดเมนใหม่

โดเมนใหม่ควรมี authentication ครบสามตัวก่อนยิง campaign แรก วาง public key ลง DKIM Record Generator publish ควบคู่กับ SPF และ DMARC แบบ p=none แล้วเริ่มจาก monitoring ก่อนค่อยเข้มโหดเป็น enforcement

แก้ปัญหา deliverability ที่พัง

เมลตกถังขยะโดยหาสาเหตุไม่เจอ มักย้อนกลับไปเจอ record ที่ resolve ได้แต่ parse ไม่ผ่าน — chunk ยาวเกิน, quote โดนลบ หรือมีขึ้นบรรทัดใหม่ติดมา สร้าง record ใหม่ด้วยการแบ่ง chunk ที่ validate แล้ว publish ทับ ใช้เวลาไม่กี่นาทีแต่ตัดโอกาสล้มเหลวแบบเงียบ ๆ ที่พบบ่อยที่สุดออกไป

ย้าย email provider

ตอนเปลี่ยน platform ส่งเมล selector เดิมยังคง sign เมลอยู่ระหว่างช่วงเปลี่ยน ให้ publish record ที่สองใต้ selector ใหม่สำหรับ provider ตัวใหม่ แล้วรันคู่กันไปจน propagation เสร็จ — กลไก selector มีไว้เพื่อให้ช่วง overlap แบบนี้ปลอดภัยโดยเฉพาะ

Rotate key อย่างปลอดภัย

Key มีอายุ ให้ publish record ใหม่ใต้ selector แบบระบุวันที่ ยืนยันว่า provider เปลี่ยนมา sign ด้วยตัวใหม่แล้ว จึงลบ record ตัวเก่า เครื่องมือนี้ทำแต่ละขั้นให้เสร็จในสามสิบวินาที

Best Practices

• Rotate key เป็นงานประจำ — เปลี่ยน selector และ key ใหม่ทุก 6–12 เดือน ช่วยจำกัดความเสียหายถ้า key รั่ว และ selector แบบระบุวันที่ทำให้ audit ง่าย
• ตรวจด้วยอีเมลจริงที่ sign แล้ว — DNS lookup พิสูจน์แค่ว่า record มีอยู่ มีแต่ dkim=pass ใน header ฝั่งผู้รับเท่านั้นที่พิสูจน์ว่าใช้งานได้จริง
• รักษา DMARC ให้ aligned — โดเมนที่ sign ต้องตรงกับ From: และควรมี SPF กับ DMARC policy คู่กันเสมอ
• ลบ selector ที่เลิกใช้ — record ที่ถูกทิ้งไว้คือ key ที่ยัง valid แต่ไม่มีใครดูแล ลบ record ของ provider ที่เลิกใช้ทุกครั้ง
• ห้าม publish private key เด็ดขาด — เครื่องมือนี้สำหรับ public key เท่านั้น ค่า p= ต้องเป็นของที่ publish ได้เสมอ
• แยก selector ต่อ service — selector ต่างกันต่อ platform ทำให้ rotation, debugging และการ revoke เป็นอิสระจากกัน

เริ่มสร้าง DKIM Record วันนี้

DKIM record ที่อ่อนแอที่สุดมักเป็นตัวที่ประกอบด้วยมือก่อนวัน launch DKIM Record Generator เปลี่ยนการเตรียม key ให้เหลือแค่วาง, ตั้งชื่อ selector และกดคัดลอก — validate แล้ว แบ่ง chunk เรียบร้อย เสร็จในไม่กี่วินาที ทั้งหมดในเบราว์เซอร์ของคุณ publish แล้วส่งเมลทดสอบหาตัวเอง แล้วรอดู dkim=pass ได้เลย

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• Security.txt Generator — สร้างไฟล์ security.txt เพื่อให้นักวิจัยรายงานช่องโหว่ได้อย่างรับผิดชอบ
• URL Parser — แยก URL เป็น protocol, host, path และ query component ในเบราว์เซอร์
• JSON Formatter — จัดรูปแบบ, ตรวจสอบ และ beautify JSON จาก API และ log

ขอให้ทุก signature verify ผ่านตั้งแต่ครั้งแรก Happy sending!

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

ถ: วาง DKIM key ลงเครื่องมือนี้ปลอดภัยไหม?

ตอบ: ปลอดภัยครับ เครื่องมือประมวลผลทั้งหมดในเบราว์เซอร์ ไม่มีการส่งข้อมูลไป server ใด และถูกออกแบบมาสำหรับ public key ซึ่งเป็นส่วนที่ตั้งใจให้ publish ลง DNS อยู่แล้ว

ถ: ทำไม key ต้องถูกแบ่งที่ 255 ตัวอักษร?

ตอบ: สเปก DNS จำกัด character-string แต่ละชุดใน TXT record ไว้ที่ 255 octets และ RSA key เมื่อ encode เป็น base64 ยาวกว่านั้น Provider จึงคาดหวังค่าแบบ quoted string หลายชุดที่ resolver ต่อกลับตอน lookup — เครื่องมือแบ่งให้ที่ขอบเขตที่ปลอดภัยโดยอัตโนมัติ

ถ: public key เอามาจากไหน?

ตอบ: Platform แบบ managed (Google Workspace, Microsoft 365, ผู้ส่งเมลส่วนใหญ่) แสดง key ไว้ใน admin console ให้นำไป publish ส่วนถ้ารัน mail server เอง ให้ใช้ openssl สร้างคู่ key แล้ววาง public key ครึ่งหนึ่งลงที่นี่

ถ: ควรตั้ง selector เป็นอะไรดี?

ตอบ: ใช้ค่าที่ provider แนะนำ หรือตั้งเองให้มีความหมาย เช่น mail2026-09 selector ที่ตั้งชื่อดีจะทำให้การ rotate และเก็บกวาดภายหลังง่ายขึ้นมาก