วิธีตั้งค่า SPF DKIM DMARC ให้อีเมล B2B ไม่ตกเป็นสแปม

ก่อนกดส่งแคมเปญ cold email หาลูกค้าใหม่ หลายทีมมองข้าม SPF DKIM DMARC dns records แล้วมาเจอปัญหาทีหลังว่าอีเมลตกสแปมหรือถูก bounce ทั้งชุด บทความนี้พาอ่าน DNS record แต่ละบรรทัดทีละตัว อธิบายวิธี check spf dkim dmarc records ด้วยตัวเอง และรวมข้อผิดพลาดที่ทีม SDR เจอบ่อยที่สุดก่อนเปิดแคมเปญจริง

ทำไมอีเมล cold email หาลูกค้าใหม่ต้องพึ่ง SPF DKIM DMARC dns records

ทีม SDR ที่เพิ่งเริ่มแคมเปญ cold email มักโฟกัสที่เนื้อหาอีเมลและ subject line ก่อนเป็นอันดับแรก แต่ปัญหาที่แท้จริงมักเกิดขึ้นก่อนอีเมลจะไปถึงสายตาผู้รับด้วยซ้ำ คือระบบกรองสแปมของ Gmail, Outlook และ Yahoo ตัดสินใจตั้งแต่ระดับ DNS ว่าจะส่งอีเมลเข้ากล่องขาเข้า โฟลเดอร์โปรโมชั่น หรือบล็อกทิ้งไปเลย

SPF DKIM DMARC dns records คือชุดกฎที่ประกาศไว้บน DNS ของโดเมนผู้ส่ง เพื่อยืนยันตัวตนว่าอีเมลฉบับนี้มาจากเซิร์ฟเวอร์ที่ได้รับอนุญาตจริง ไม่ใช่คนอื่นปลอมโดเมนขึ้นมาส่งฟิชชิ่ง ตั้งแต่ Google และ Yahoo เริ่มบังคับให้โดเมนที่ส่งอีเมลจำนวนมากต่อวันต้องมี SPF DKIM DMARC ครบทั้งสามอย่าง โดเมนที่ตั้งค่าไม่ครบจะถูก bounce กลับทันทีโดยไม่มีโอกาสแม้แต่จะเข้าโฟลเดอร์สแปม

สำหรับแคมเปญ B2B ที่ส่งอีเมลปริมาณน้อยแต่เจาะจงถึงผู้ติดต่อรายบุคคล การตั้งค่า DNS records ให้ถูกต้องสำคัญยิ่งกว่าแคมเปญอีเมลจำนวนมาก เพราะโดเมนธุรกิจมักมีประวัติการส่งไม่มากพอที่ผู้ให้บริการอีเมลจะ 'เชื่อใจ' โดยอัตโนมัติ ต้องอาศัย SPF DKIM DMARC เป็นหลักฐานยืนยันตัวตนแทน

SPF Record คืออะไร อ่านและตรวจสอบอย่างไร

SPF (Sender Policy Framework) คือ TXT record บน DNS ที่ระบุว่าเซิร์ฟเวอร์หรือบริการใดบ้างมีสิทธิ์ส่งอีเมลในนามของโดเมนนั้น ตัวอย่าง record ทั่วไปหน้าตาแบบนี้: v=spf1 include:_spf.google.com include:sendgrid.net ~all

อ่านทีละส่วน: v=spf1 บอกเวอร์ชันของ SPF, include: บอกว่าอนุญาตให้เซิร์ฟเวอร์ของบริการนั้น (เช่น Google Workspace, SendGrid, LDM) ส่งแทนได้ ส่วน ~all ท้ายบรรทัดคือ soft fail หมายถึงถ้ามีเซิร์ฟเวอร์อื่นนอกรายการส่งแทน ให้ทำเครื่องหมายสงสัยแต่ยังไม่บล็อกทันที ต่างจาก -all ที่เป็น hard fail และบล็อกเด็ดขาด

วิธี check spf dkim dmarc records ด้วยตัวเองทำได้ผ่านคำสั่ง dig txt yourdomain.com บนเทอร์มินัล หรือใช้เว็บตรวจสอบ DNS record ทั่วไป สิ่งที่ต้องระวังที่สุดคือโดเมนหนึ่งมี SPF record ได้แค่บรรทัดเดียวเท่านั้น ถ้ามีสองบรรทัดขึ้นไป ระบบจะตีความว่า SPF ล้มเหลวทั้งหมด ต้องรวมทุก include เข้าไปในบรรทัดเดียว

DKIM คืออะไร ตั้งค่าอย่างไรให้ถูกต้อง

DKIM (DomainKeys Identified Mail) ทำงานต่างจาก SPF ตรงที่ไม่ได้ระบุว่าใครส่งได้ แต่เซ็นลายเซ็นดิจิทัลลงในหัวอีเมลทุกฉบับด้วย private key แล้วผู้รับใช้ public key ที่ประกาศไว้บน DNS ตรวจสอบว่าเนื้อหาอีเมลไม่ถูกแก้ไขระหว่างทาง

DKIM record จะอยู่ในรูปแบบ selector._domainkey.yourdomain.com เช่น google._domainkey.yourdomain.com โดย selector คือชื่อที่ผู้ให้บริการอีเมลกำหนด (Google Workspace, LDM, SendGrid ต่างก็มี selector ของตัวเอง) เนื้อหาข้างในจะเป็น public key ยาวๆ ขึ้นต้นด้วย v=DKIM1; k=rsa; p=...

ข้อผิดพลาดที่พบบ่อยคือลืม publish DKIM record หลังเปลี่ยนผู้ให้บริการส่งอีเมล หรือใช้ selector เก่าที่ provider ยกเลิกไปแล้ว ทำให้อีเมลส่งได้ปกติแต่ authentication ล้มเหลวแบบเงียบๆ ควรตรวจสอบ header Authentication-Results ของอีเมลที่ส่งจริงเป็นระยะว่า dkim=pass เสมอ

DMARC Record คืออะไร ทำไมต้องขยับจาก p=none ไป reject

DMARC (Domain-based Message Authentication, Reporting and Conformance) คือ dmarc record ที่บอกผู้ให้บริการอีเมลปลายทางว่าจะทำอย่างไรถ้าอีเมลฉบับหนึ่งผ่าน SPF หรือ DKIM ไม่ครบ ตัวอย่าง record: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100

ค่า p= มีสามระดับ: none (ไม่ทำอะไร แค่เก็บรายงาน), quarantine (ส่งเข้าสแปมถ้า authentication ล้มเหลว), reject (บล็อกทันที) โดเมนที่เพิ่งตั้งค่าใหม่ควรเริ่มที่ p=none เพื่อเก็บรายงาน rua ดูก่อนว่ามีอีเมลถูกต้องของบริษัทเองที่ authentication ไม่ผ่านหรือไม่ เช่น ระบบ CRM หรือ helpdesk ที่ลืม whitelist แล้วค่อยขยับเป็น quarantine และ reject ตามลำดับ

การมี DMARC record ยังช่วยป้องกันมิจฉาชีพปลอมโดเมนบริษัทไปส่งฟิชชิ่งหาลูกค้าของบริษัทเอง ซึ่งเป็นความเสี่ยงด้านชื่อเสียงที่แยกจากเรื่อง deliverability โดยตรง แต่ส่งผลกระทบต่อความน่าเชื่อถือของแบรนด์ในระยะยาว

ข้อผิดพลาดที่พบบ่อยเมื่อตั้งค่า SPF DKIM DMARC dns records

โดเมนธุรกิจจำนวนมากตั้งค่า DNS records ไว้ครั้งเดียวตอนสมัครใช้อีเมลบริษัท แล้วไม่เคยกลับมาตรวจสอบอีกเลย ทั้งที่ผู้ให้บริการอีเมลเปลี่ยนกฎการยืนยันตัวตนอยู่เรื่อยๆ และทีมงานก็มักเพิ่มบริการส่งอีเมลใหม่โดยไม่อัปเดต SPF ตาม

• มี SPF record มากกว่าหนึ่งบรรทัดในโดเมนเดียว ทำให้ authentication ล้มเหลวทั้งหมด
• ตั้ง DMARC เป็น p=reject ทันทีบนโดเมนใหม่ ก่อนตรวจสอบ rua report ทำให้อีเมลปกติของบริษัทเองถูกบล็อกไปด้วย
• ใช้โดเมนหลักของบริษัทส่ง cold email ปริมาณมากโดยตรง แทนที่จะแยก subdomain เฉพาะสำหรับแคมเปญ
• ลืมอัปเดต DKIM selector หลังเปลี่ยนผู้ให้บริการอีเมลหรือแพลตฟอร์ม cold email
• ไม่มีใครอ่าน rua report ที่ DMARC ส่งมา ทำให้ไม่รู้ตัวว่ามีคนปลอมโดเมนส่งอีเมลอยู่

Checklist ก่อนเปิดแคมเปญ cold email และวิธี LDM ตรวจสอบให้ลูกค้า

ก่อนเปิดแคมเปญ cold email หาลูกค้าใหม่ทุกครั้ง ทีมงานควรตรวจสอบ DNS records ด้วยเครื่องมือ spf dkim dmarc record checker อย่างน้อยหนึ่งตัว และยืนยันว่าอีเมลทดสอบที่ส่งไปยัง Gmail และ Outlook จริงมี Authentication-Results ระบุ spf=pass, dkim=pass, dmarc=pass ครบทั้งสามค่า

ที่ LDM ทีมงานตรวจสอบ SPF DKIM DMARC dns records ของโดเมนลูกค้าทุกรายก่อนเปิดแคมเปญจริง พร้อมแนะนำให้แยก subdomain สำหรับ cold email โดยเฉพาะ เพื่อไม่ให้ปัญหา deliverability กระทบอีเมลหลักของบริษัทที่ใช้ติดต่อลูกค้าเดิม และมอนิเตอร์ผลลัพธ์การส่งอย่างต่อเนื่องตลอดแคมเปญ ไม่ใช่ตรวจครั้งเดียวตอนเริ่มต้นแล้วปล่อยผ่าน

• โดเมนหรือ subdomain ที่ใช้ส่งมี SPF record เดียว ไม่ซ้ำซ้อน
• DKIM publish ครบและตรงกับ selector ของผู้ให้บริการที่ใช้งานจริง
• DMARC ตั้งค่าอย่างน้อย p=none พร้อม rua ไว้เก็บรายงาน และมีแผนขยับไป quarantine ภายในไม่กี่สัปดาห์
• โดเมนใหม่ผ่านช่วง warm up ส่งปริมาณน้อยค่อยๆ เพิ่มก่อนยิงแคมเปญเต็มจำนวน
• รายชื่อผู้ติดต่อที่จะส่งเก็บและใช้ตามฐานสิทธิ์ที่ชอบด้วยกฎหมายภายใต้ PDPA (พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562) ไม่ใช่การซื้อลิสต์อีเมลมาส่งจำนวนมากแบบสุ่ม

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