SPF, DKIM และ DMARC: คู่มือ Email Authentication ฉบับสมบูรณ์

Email authentication คือรากฐานของการส่งอีเมลที่เชื่อถือได้ หากไม่ตั้งค่า SPF, DKIM และ DMARC ให้ถูกต้อง อีเมลที่คุณตั้งใจส่งอาจไม่มีวันถึงกล่องจดหมายของลูกค้า แต่กลับไปอยู่ในโฟลเดอร์สแปมหรือถูกปฏิเสธทั้งหมด

คู่มือฉบับสมบูรณ์นี้จะอธิบายว่าแต่ละโปรโตคอลทำหน้าที่อะไร พร้อมคำแนะนำการตั้งค่า DNS ทีละขั้นตอน การแก้ปัญหาที่พบบ่อย และวิธีตรวจสอบว่าการตั้งค่าทำงานถูกต้อง

ทำไม Email Authentication จึงสำคัญ

อีเมลถูกออกแบบมาในยุคที่ความปลอดภัยไม่ใช่ความกังวลหลัก โปรโตคอล SMTP ดั้งเดิมไม่มีกลไกยืนยันตัวตนในตัวเพื่อยืนยันว่าอีเมลมาจากผู้ส่งที่อ้างจริง จุดอ่อนนี้ทำให้เกิดการปลอมแปลงอีเมล (email spoofing) การโจมตีแบบฟิชชิ่ง และสแปม

โปรโตคอล email authentication แก้ปัญหานี้โดยให้เจ้าของโดเมนระบุ:

• เซิร์ฟเวอร์ใดบ้างที่ส่งอีเมลแทนตนได้ (SPF)
• หลักฐานทางคริปโตกราฟีว่าข้อความเป็นของแท้และไม่ถูกแก้ไข (DKIM)
• จะทำอย่างไรกับข้อความที่ไม่ผ่านการยืนยัน (DMARC)

ผลกระทบทางธุรกิจเมื่อ Authentication ไม่ดี

หากไม่มี email authentication ที่ถูกต้อง:

• อัตราการส่งถึงต่ำลง: ผู้ให้บริการรายใหญ่อย่าง Gmail, Microsoft และ Yahoo กรองอีเมลที่ไม่ผ่านการยืนยันอย่างเข้มงวดกว่า
• อัตราสแปมสูงขึ้น: อีเมลที่ถูกต้องของคุณต้องแข่งกับข้อความปลอมที่ใช้โดเมนของคุณ
• ความเสียหายต่อแบรนด์: การโจมตีฟิชชิ่งที่แอบอ้างเป็นแบรนด์ของคุณทำลายความไว้วางใจของลูกค้า
• สูญเสียรายได้: แคมเปญการตลาดไม่สามารถเข้าถึงสมาชิกที่ลงทะเบียนรับอีเมล
• ความเสี่ยงด้านการปฏิบัติตามกฎหมาย: กฎระเบียบหลายฉบับในปัจจุบันกำหนดให้ต้องมี email authentication ที่ถูกต้อง

สามเสาหลักของ Authentication

SPF, DKIM และ DMARC ทำงานร่วมกันเป็นระบบ authentication ที่สมบูรณ์:

แต่ละโปรโตคอลแก้ไขเวกเตอร์การโจมตีที่แตกต่างกัน SPF ป้องกันเซิร์ฟเวอร์ที่ไม่ได้รับอนุญาตไม่ให้ส่งในนามคุณ DKIM ป้องกันการแก้ไขข้อความหลังส่ง DMARC เชื่อมทั้งสองเข้าด้วยกันและให้ visibility ในผลการ authentication

ทำความเข้าใจ SPF (Sender Policy Framework)

SPF (Sender Policy Framework) คือวิธีการ email authentication แบบ DNS ที่ระบุว่าเมลเซิร์ฟเวอร์ใดได้รับอนุญาตให้ส่งอีเมลในนามโดเมนของคุณ

SPF ทำงานอย่างไร

เมื่ออีเมลมาถึงเซิร์ฟเวอร์ผู้รับ เซิร์ฟเวอร์จะค้นหา SPF record ของโดเมนผู้ส่ง จากนั้นตรวจสอบว่า IP address ที่ส่งอีเมลอยู่ในรายการที่ได้รับอนุญาตหรือไม่ ถ้าตรงกัน SPF ผ่าน ถ้าไม่ตรง SPF ล้มเหลว

กระบวนการยืนยัน SPF:

1. คุณส่งอีเมลจากแพลตฟอร์มการตลาด
2. เซิร์ฟเวอร์ผู้รับดึงโดเมนของคุณจาก Return-Path (envelope sender)
3. เซิร์ฟเวอร์ query DNS เพื่อหา SPF record ของโดเมน
4. เปรียบเทียบ IP ที่ส่งกับรายการที่ได้รับอนุญาตใน SPF record
5. เซิร์ฟเวอร์บันทึกผล pass, fail, softfail หรือ neutral

ไวยากรณ์ SPF Record

SPF records เผยแพร่เป็น TXT records ใน DNS ของโดเมน โครงสร้างพื้นฐาน:

v=spf1 [mechanisms] [qualifier]all

Version tag: เริ่มด้วย v=spf1 เสมอ

Mechanisms: กำหนดว่าใครส่งได้

Qualifiers: กำหนดวิธีจัดการกับการ match

The all mechanism: ใช้กับสิ่งที่ไม่ match กับ mechanisms ก่อนหน้า

ตัวอย่าง SPF Record

การตั้งค่าพื้นฐานกับผู้ให้บริการอีเมลหนึ่งราย:

v=spf1 include:spf.brevo.com -all

อนุญาตให้ Brevo ส่งอีเมลสำหรับโดเมนของคุณและปฏิเสธผู้ส่งอื่นทั้งหมด

หลายบริการอีเมล:

v=spf1 include:spf.brevo.com include:_spf.google.com include:spf.protection.outlook.com -all

อนุญาต Brevo, Google Workspace และ Microsoft 365

รวมเมลเซิร์ฟเวอร์ของคุณ:

v=spf1 ip4:203.0.113.10 include:spf.brevo.com -all

อนุญาต IP address เฉพาะ (เซิร์ฟเวอร์ของคุณ) บวก Brevo

เริ่มด้วย soft fail ระหว่างทดสอบ:

v=spf1 include:spf.brevo.com ~all

การใช้ ~all แทน -all ทำเครื่องหมาย failures แต่ไม่ปฏิเสธ เหมาะสำหรับการตั้งค่าเริ่มต้น

การตั้งค่า SPF Records

ขั้นตอนที่ 1: ระบุแหล่งการส่งของคุณ

แสดงรายการทุกบริการที่ส่งอีเมลจากโดเมนของคุณ:

• แพลตฟอร์มการตลาดทางอีเมล (Brevo, Mailchimp ฯลฯ)
• บริการ transactional email
• ระบบ CRM
• ซอฟต์แวร์ help desk
• อีเมลบริษัท (Google Workspace, Microsoft 365)
• เมลเซิร์ฟเวอร์ของคุณ

ขั้นตอนที่ 2: รวบรวม SPF include statements

ผู้ให้บริการอีเมลแต่ละรายระบุ SPF include ที่จำเป็น ตัวอย่างที่พบบ่อย:

ขั้นตอนที่ 3: สร้าง SPF record ของคุณ

รวม includes ทั้งหมดเป็น record เดียว:

v=spf1 include:spf.brevo.com include:_spf.google.com -all

ขั้นตอนที่ 4: เพิ่ม DNS record

ในอินเทอร์เฟซการจัดการ DNS:

• Type: TXT
• Host/Name: @ (หรือเว้นว่างสำหรับ root domain)
• Value: SPF record ที่สมบูรณ์ของคุณ
• TTL: 3600 (หรือค่าเริ่มต้น)

ขั้นตอนที่ 5: ยืนยัน record

ใช้เครื่องมือ DNS lookup เพื่อยืนยัน:

dig TXT yourdomain.com

หรือใช้เครื่องมือออนไลน์เช่น MXToolbox SPF Lookup

ข้อจำกัดและแนวทางปฏิบัติที่ดีของ SPF

ขีดจำกัด 10 DNS lookups:

SPF มีขีดจำกัดสูงสุด 10 DNS lookups แต่ละ include: นับเป็น 1 lookup และ records ที่รวมอยู่อาจมี includes ของตัวเองซึ่งนับรวมด้วย การเกินขีดจำกัดนี้ทำให้เกิด SPF permerror ทำให้การตรวจสอบทั้งหมดล้มเหลว

กลยุทธ์เพื่อให้อยู่ภายในขีดจำกัด:

• ใช้ IP addresses โดยตรงเมื่อเป็นไปได้ (ip4: ไม่นับเป็น lookup)
• รวมบริการที่ใช้ผู้ให้บริการเดียวกัน
• ใช้บริการ SPF flattening ที่แปลง includes เป็น IP addresses
• ลบ includes ที่ไม่ใช้แล้วออกจากบริการเก่า

แนวทางปฏิบัติที่ดีอื่นๆ ของ SPF:

• มี SPF record เดียวต่อโดเมน (หลาย records ทำให้เกิดความล้มเหลว)
• เริ่มด้วย ~all (softfail) ระหว่างตั้งค่า ย้ายไป -all เมื่อยืนยันแล้ว
• อัปเดต SPF เมื่อเปลี่ยนผู้ให้บริการอีเมล
• อย่าใช้ mechanism ptr ที่เลิกใช้แล้ว
• รักษา records ให้เรียบง่ายที่สุด

ข้อผิดพลาดทั่วไปของ SPF

หลาย SPF records:

ผิด:
v=spf1 include:spf.brevo.com -all
v=spf1 include:_spf.google.com -all

ถูก:
v=spf1 include:spf.brevo.com include:_spf.google.com -all

เกินขีดจำกัด DNS lookup:

ถ้ามี includes มาก ตรวจสอบจำนวน lookups รวม ใช้ SPF analyzers เพื่อยืนยันว่าน้อยกว่า 10

ลืมอัปเดตหลังเปลี่ยนผู้ให้บริการ:

เมื่อเปลี่ยนจากบริการอีเมลหนึ่งไปอีกบริการ ให้ลบ include เก่าและเพิ่มใหม่

การใช้ +all:

อย่าใช้ +all เพราะอนุญาตให้ทุกคนส่งในนามโดเมนของคุณ

ทำความเข้าใจ DKIM (DomainKeys Identified Mail)

DKIM (DomainKeys Identified Mail) เพิ่มลายเซ็นทางคริปโตกราฟีในอีเมลของคุณ พิสูจน์ว่าข้อความมาจากโดเมนของคุณและไม่ถูกแก้ไขระหว่างส่ง

DKIM ทำงานอย่างไร

DKIM ใช้ public-key cryptography:

1. ผู้ให้บริการอีเมลสร้างคู่ public/private key
2. คุณเผยแพร่ public key ใน DNS
3. ผู้ให้บริการลงนามอีเมลขาออกด้วย private key
4. เซิร์ฟเวอร์ผู้รับดึง public key จาก DNS
5. ใช้ public key เพื่อยืนยันลายเซ็น
6. ลายเซ็นที่ถูกต้องพิสูจน์ความถูกต้องและความสมบูรณ์

สิ่งที่ DKIM ลงนาม:

ลายเซ็น DKIM มักครอบคลุม headers และ body ของข้อความที่เฉพาะเจาะจง:

• From header (จำเป็น)
• Subject header
• Date header
• Message body
• Headers อื่นๆ ตามที่กำหนด

ป้องกันไม่ให้ผู้โจมตีแก้ไของค์ประกอบเหล่านี้หลังส่ง

โครงสร้าง DKIM Record

DKIM records เผยแพร่เป็น TXT records ในรูปแบบชื่อเฉพาะ:

selector._domainkey.yourdomain.com

selector คือตัวระบุเฉพาะที่อนุญาตให้มีหลาย DKIM keys บริการอีเมลแต่ละรายใช้ selectors ต่างกัน (เช่น brevo, google, s1, s2)

เนื้อหา DKIM record:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

การตั้งค่า DKIM

ขั้นตอนที่ 1: สร้าง DKIM keys

ผู้ให้บริการอีเมลมักสร้าง keys ให้คุณ ใน Brevo:

1. ไปที่ Settings > Senders, Domains & Dedicated IPs
2. เลือกโดเมนของคุณ
3. ไปที่ส่วน DKIM
4. คัดลอก DNS record ที่ให้มา

สำหรับเมลเซิร์ฟเวอร์ที่โฮสต์เอง สร้าง keys โดยใช้ OpenSSL:

openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key

ขั้นตอนที่ 2: เพิ่ม DKIM DNS record

ในการจัดการ DNS:

• Type: TXT
• Host/Name: selector._domainkey (เช่น brevo._domainkey)
• Value: DKIM record จากผู้ให้บริการ
• TTL: 3600

ขั้นตอนที่ 3: เปิดใช้งาน DKIM signing

ในการตั้งค่าของผู้ให้บริการอีเมล เปิดใช้งาน DKIM signing สำหรับโดเมนของคุณ สิ่งนี้บอกผู้ให้บริการให้ลงนามข้อความขาออก

ขั้นตอนที่ 4: ยืนยันการตั้งค่า

ส่งอีเมลทดสอบและตรวจสอบ headers สำหรับ DKIM-Signature ใช้เครื่องมือเช่น:

• mail-tester.com
• DKIM Validator
• MXToolbox DKIM Lookup

แนวทางปฏิบัติที่ดีของ DKIM

ใช้ 2048-bit keys:

Keys ขนาด 1024-bit รุ่นเก่าถือว่าอ่อนแอ มาตรฐานความปลอดภัยสมัยใหม่แนะนำ RSA keys ขนาด 2048-bit เป็นอย่างน้อย

หมุนเวียน keys เป็นประจำ:

แม้ไม่จำเป็นอย่างเคร่งครัด การหมุนเวียน DKIM keys ทุกปีเป็นแนวทางปฏิบัติด้านความปลอดภัยที่ดี เพิ่ม key ใหม่ก่อนลบ key เก่าเพื่อหลีกเลี่ยงช่องว่าง

ติดตามการถูก compromise ของ key:

ถ้า private key ของคุณถูก compromise ผู้โจมตีสามารถลงนามข้อความในนามคุณได้ ติดตามรูปแบบ authentication ที่ผิดปกติ

ใช้ selectors ต่างกันสำหรับบริการต่างกัน:

ผู้ให้บริการอีเมลแต่ละรายควรใช้ selector ที่เป็นเอกลักษณ์ ช่วยให้จัดการ keys ได้อิสระและไม่ขัดแย้งกับบริการอื่น

ตรวจสอบการแพร่กระจาย DNS:

DKIM keys อาจยาว ตรวจสอบว่าผู้ให้บริการ DNS รองรับ TXT records ที่มีความยาวเพียงพอ บางผู้ให้บริการต้องแบ่ง key เป็นหลาย strings

การอ่าน DKIM Headers

เมื่อรับอีเมล DKIM-Signature header แสดง:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=brevo;
  h=from:to:subject:date:message-id;
  bh=base64hashofbody;
  b=base64signature;

ทำความเข้าใจ DMARC (Domain-based Message Authentication, Reporting, and Conformance)

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

DMARC ทำงานอย่างไร

DMARC เพิ่มความสามารถสำคัญสองอย่าง:

1. การบังคับใช้นโยบาย: กำหนดว่าผู้รับควรจัดการกับความล้มเหลวในการ authentication อย่างไร
2. การรายงาน: รับข้อมูลเกี่ยวกับใครที่ส่งอีเมลโดยใช้โดเมนของคุณ

กระบวนการยืนยัน DMARC:

1. เซิร์ฟเวอร์ผู้รับได้รับอีเมลที่อ้างว่ามาจากโดเมนของคุณ
2. ตรวจสอบ SPF (IP ที่ส่งตรงกันหรือไม่?)
3. ตรวจสอบ DKIM (ลายเซ็นถูกต้องหรือไม่?)
4. ตรวจสอบ DMARC alignment (โดเมนที่ผ่านการยืนยันตรงกับ From header หรือไม่?)
5. หาก alignment ล้มเหลว ใช้นโยบาย DMARC ของคุณ
6. ส่งรายงาน aggregate และ/หรือ forensic ให้คุณ

DMARC Alignment

DMARC ต้องการ alignment ระหว่างโดเมนใน From header และโดเมนที่ผ่าน SPF หรือ DKIM:

SPF Alignment: โดเมนใน Return-Path (envelope sender) ต้องตรงกันหรือเป็น subdomain ของโดเมนใน From header

DKIM Alignment: โดเมนใน DKIM signature (d= tag) ต้องตรงกันหรือเป็น subdomain ของโดเมนใน From header

Alignment modes:

ด้วย relaxed alignment หาก From header แสดง [email protected] และ DKIM ลงนามด้วย brevo.example.com alignment ผ่านเพราะทั้งสองใช้โดเมนองค์กร example.com

ไวยากรณ์ DMARC Record

DMARC records เผยแพร่เป็น TXT records ที่ _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

Tags ที่จำเป็น:

Tags ตัวเลือก:

อธิบาย DMARC Policies

p=none (เฉพาะติดตาม):

ไม่มีการดำเนินการกับความล้มเหลว อีเมลส่งถึงตามปกติ ใช้ขณะวิเคราะห์รายงานและแก้ปัญหา authentication

v=DMARC1; p=none; rua=mailto:[email protected]

p=quarantine (โฟลเดอร์สแปม):

อีเมลที่ล้มเหลวถูกส่งไปยังโฟลเดอร์สแปม/junk ขั้นตอนกลางที่ดีก่อนการปฏิเสธเต็มรูปแบบ

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

p=reject (บล็อก):

อีเมลที่ล้มเหลวถูกปฏิเสธทั้งหมด ป้องกันสูงสุดแต่ตรวจสอบให้แน่ใจว่าแหล่งส่งที่ถูกต้องทั้งหมดผ่านก่อน

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

การตั้งค่า DMARC

ขั้นตอนที่ 1: ตรวจสอบว่า SPF และ DKIM ทำงาน

DMARC ขึ้นอยู่กับ SPF และ DKIM ยืนยันทั้งสองตั้งค่าถูกต้องก่อนเพิ่ม DMARC

ขั้นตอนที่ 2: เริ่มด้วยการติดตาม (p=none)

เริ่มด้วยนโยบายที่ผ่อนปรนที่สุดเพื่อรวบรวมข้อมูลโดยไม่กระทบการส่ง:

v=DMARC1; p=none; rua=mailto:[email protected]

ขั้นตอนที่ 3: เพิ่ม DNS record

ในการจัดการ DNS:

• Type: TXT
• Host/Name: _dmarc
• Value: DMARC record ของคุณ
• TTL: 3600

ขั้นตอนที่ 4: วิเคราะห์รายงาน 2-4 สัปดาห์

รายงาน aggregate ของ DMARC มาถึงทุกวันเป็นไฟล์ XML แสดง:

• IP ใดส่งอีเมลโดยใช้โดเมนของคุณ
• อัตรา SPF และ DKIM pass/fail
• ผล DMARC alignment
• การดำเนินการของเซิร์ฟเวอร์ผู้รับ

ใช้เครื่องมือวิเคราะห์รายงาน DMARC เพื่อแสดงข้อมูลนี้:

• DMARC Analyzer
• Postmark DMARC
• Valimail
• dmarcian

ขั้นตอนที่ 5: แก้ไขปัญหา authentication

ปัญหาทั่วไปที่รายงานเปิดเผย:

• บริการที่ถูกต้องที่ขาดหายไปจาก SPF
• DKIM ไม่ได้เปิดใช้งานสำหรับบริการส่ง
• บริการบุคคลที่สามส่งโดยไม่มี authentication ที่เหมาะสม
• การ forwarding ทำลาย SPF alignment

ขั้นตอนที่ 6: บังคับใช้ทีละน้อย

เมื่อแหล่งส่งที่ถูกต้องผ่านอย่างสม่ำเสมอ:

1. ย้ายไป p=quarantine; pct=10 (กักกัน 10% ของความล้มเหลว)
2. เพิ่ม pct เป็น 25, 50, 75, 100
3. ย้ายไป p=reject; pct=10
4. เพิ่มเป็นการปฏิเสธเต็มรูปแบบ

ขั้นตอนที่ 7: ดูแลและติดตาม

ตรวจสอบรายงานต่อไป แหล่งส่งใหม่ การเปลี่ยนผู้ให้บริการ หรือการเปลี่ยนแปลงการกำหนดค่าอาจทำให้เกิดความล้มเหลวใน authentication

ทำความเข้าใจรายงาน DMARC

รายงาน Aggregate (rua):

สรุป XML รายวันแสดง:

• องค์กรที่รายงาน
• ช่วงวันที่
• นโยบายที่เผยแพร่
• ผลการ authentication ตาม source IP
• ปริมาณอีเมล

ตัวอย่างข้อมูล:

<record>
  <source_ip>203.0.113.10</source_ip>
  <count>1250</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>
    <spf>pass</spf>
  </policy_evaluated>
</record>

รายงาน Forensic (ruf):

รายละเอียดข้อความแต่ละรายการสำหรับความล้มเหลว รายละเอียดมากกว่าแต่มีความอ่อนไหวด้านความเป็นส่วนตัว ผู้รับหลายรายไม่ส่งรายงาน forensic

แนวทางปฏิบัติที่ดีของ DMARC

เริ่มด้วย p=none เสมอ:

การข้ามไป reject โดยตรงอาจบล็อกอีเมลที่ถูกต้อง ติดตามก่อน

ใช้ที่อยู่อีเมลเฉพาะสำหรับรายงาน:

รายงาน DMARC อาจมีจำนวนมาก ใช้ที่อยู่เฉพาะหรือบริการบุคคลที่สาม

กำหนดนโยบาย subdomain (sp=):

ถ้าคุณไม่ส่งอีเมลจาก subdomains ตั้งค่า sp=reject เพื่อป้องกันจากการปลอมแปลง

ใช้เปอร์เซ็นต์ (pct=) สำหรับการ rollout ทีละน้อย:

Tag pct ช่วยให้คุณบังคับใช้นโยบายกับเปอร์เซ็นต์ของความล้มเหลวขณะติดตามส่วนที่เหลือ

พิจารณาบริการ DMARC เฉพาะทาง:

สำหรับองค์กรขนาดใหญ่ บริการเช่น Valimail, dmarcian หรือ Postmark DMARC ให้การวิเคราะห์รายงานที่ดีกว่าไฟล์ XML ดิบ

การตั้งค่า DNS Record: การดำเนินการฉบับสมบูรณ์

การตั้งค่า email authentication ต้องเพิ่ม DNS records เฉพาะ ส่วนนี้ให้การดำเนินการฉบับสมบูรณ์สำหรับผู้ให้บริการ DNS หลัก

รวบรวมค่าที่จำเป็น

ก่อนเริ่ม รวบรวมค่าเหล่านี้จากผู้ให้บริการอีเมลของคุณ:

สำหรับ SPF:

• Include statements ทั้งหมด (เช่น include:spf.brevo.com)
• IP addresses เฉพาะที่คุณต้องการอนุญาต

สำหรับ DKIM:

• ชื่อ selector (เช่น brevo, google, s1)
• ค่า DKIM key เต็มรูปแบบ

สำหรับ DMARC:

• ที่อยู่อีเมลสำหรับรายงาน

การเพิ่ม Records ในผู้ให้บริการ DNS ทั่วไป

Cloudflare:

1. เข้าสู่ระบบ Cloudflare Dashboard
2. เลือกโดเมนของคุณ
3. ไปที่ DNS > Records
4. คลิก Add Record
5. สำหรับ SPF: Type=TXT, Name=@, Content=SPF record ของคุณ
6. สำหรับ DKIM: Type=TXT, Name=selector._domainkey, Content=DKIM key
7. สำหรับ DMARC: Type=TXT, Name=_dmarc, Content=DMARC record
8. คลิก Save

Google Domains/Squarespace:

1. ไปที่การตั้งค่า DNS สำหรับโดเมนของคุณ
2. เลื่อนไปที่ Custom Records
3. คลิก Manage Custom Records
4. เพิ่มแต่ละ record ด้วย type, host และ data ที่เหมาะสม
5. สำหรับ SPF: Host=@, Type=TXT, Data=SPF record
6. สำหรับ DKIM: Host=selector._domainkey, Type=TXT, Data=DKIM key
7. สำหรับ DMARC: Host=_dmarc, Type=TXT, Data=DMARC record

GoDaddy:

1. ไปที่ My Products > Domains
2. คลิก DNS ถัดจากโดเมนของคุณ
3. เลื่อนไปที่ส่วน Records
4. คลิก Add สำหรับแต่ละ record ใหม่
5. เลือก TXT สำหรับ Type
6. ใส่ Name (@ สำหรับ SPF, selector._domainkey สำหรับ DKIM, _dmarc สำหรับ DMARC)
7. ใส่ Value
8. Save

Namecheap:

1. ไปที่ Domain List > Manage
2. คลิก Advanced DNS
3. Add New Record สำหรับแต่ละรายการ
4. เลือก TXT Record
5. Host: @ สำหรับ SPF, selector._domainkey สำหรับ DKIM, _dmarc สำหรับ DMARC
6. Value: เนื้อหา record ของคุณ
7. Save All Changes

การแพร่กระจาย DNS

หลังเพิ่ม records การเปลี่ยนแปลงใช้เวลาแพร่กระจายทั่วโลก โดยทั่วไปใช้เวลา:

• 5-30 นาทีสำหรับการมองเห็นเริ่มต้น
• สูงสุด 48 ชั่วโมงสำหรับการแพร่กระจายทั่วโลก

ใช้ dig หรือ nslookup เพื่อยืนยัน:

dig TXT yourdomain.com
dig TXT selector._domainkey.yourdomain.com
dig TXT _dmarc.yourdomain.com

หรือใช้เครื่องมือออนไลน์เช่น whatsmydns.net เพื่อตรวจสอบการแพร่กระจายทั่วโลก

ตัวอย่างการตั้งค่าที่สมบูรณ์

สำหรับโดเมนที่ใช้ Brevo และ Google Workspace:

SPF record (TXT ที่ @):

v=spf1 include:spf.brevo.com include:_spf.google.com -all

DKIM record สำหรับ Brevo (TXT ที่ brevo._domainkey):

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA... [key จาก Brevo dashboard]

DKIM record สำหรับ Google (TXT ที่ google._domainkey):

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BA... [key จาก Google Admin]

DMARC record (TXT ที่ _dmarc):

v=DMARC1; p=none; rua=mailto:[email protected]

การแก้ปัญหาทั่วไป

แม้ตั้งค่าอย่างระมัดระวัง email authentication อาจล้มเหลวได้ ต่อไปนี้คือปัญหาทั่วไปและวิธีแก้ไข

การแก้ปัญหา SPF

ไม่พบ SPF record:

อาการ: การตรวจสอบ SPF แสดง “none” หรือ “no record”

สาเหตุ:

• ไม่ได้เพิ่ม record ใน DNS
• เพิ่ม record ในตำแหน่งผิด (subdomain แทน root)
• การแพร่กระจาย DNS ยังไม่สมบูรณ์

วิธีแก้:

• ยืนยัน record มีอยู่ด้วย dig TXT yourdomain.com
• ตรวจสอบฟิลด์ Name/Host (ควรเป็น @ หรือว่างสำหรับ root domain)
• รอการแพร่กระจาย DNS (สูงสุด 48 ชั่วโมง)

SPF PermError (lookups มากเกินไป):

อาการ: ผล SPF แสดง “permerror”

สาเหตุ:

• มากกว่า 10 DNS lookups ใน SPF record
• Includes ที่มี nested includes มากเกินไป

วิธีแก้:

• ตรวจสอบ includes และลบที่ไม่ใช้แล้ว
• แทนที่ includes ด้วย ip4: entries ที่เป็นไปได้
• ใช้บริการ SPF flattening
• รวมบริการในผู้ให้บริการน้อยลง

SPF SoftFail หรือ Fail สำหรับอีเมลที่ถูกต้อง:

อาการ: อีเมลที่ถูกต้องล้มเหลว SPF

สาเหตุ:

• บริการส่งไม่รวมอยู่ใน SPF
• ส่งจาก IP ที่ไม่ได้รับอนุญาต
• การใช้ relay ที่เปลี่ยน envelope sender

วิธีแก้:

• เพิ่ม include ที่ขาดหายสำหรับบริการส่ง
• ตรวจสอบว่า IP ใดที่ส่งอีเมลจริง (จาก headers)
• ติดต่อผู้ให้บริการอีเมลเพื่อการตั้งค่า SPF ที่ถูกต้อง

หลาย SPF records:

อาการ: SPF แสดง permerror หรือความล้มเหลวแบบสุ่ม

สาเหตุ:

• สอง TXT records ขึ้นไปที่มี v=spf1

วิธีแก้:

• รวม mechanisms ทั้งหมดเป็น SPF record เดียว
• ลบ SPF records ที่ซ้ำกัน

การแก้ปัญหา DKIM

ไม่มีลายเซ็น DKIM:

อาการ: ไม่มี DKIM-Signature header ในอีเมล

สาเหตุ:

• DKIM signing ไม่ได้เปิดใช้งานในผู้ให้บริการอีเมล
• การยืนยันโดเมนยังไม่สมบูรณ์
• ส่งผ่านเส้นทางที่ไม่มี DKIM

วิธีแก้:

• เปิดใช้งาน DKIM ในการตั้งค่าผู้ให้บริการ
• ทำขั้นตอนการยืนยันโดเมนให้สมบูรณ์
• ตรวจสอบเอกสารผู้ให้บริการสำหรับการตั้งค่า DKIM

การยืนยัน DKIM ล้มเหลว:

อาการ: DKIM แสดง “fail” ในผลการ authentication

สาเหตุ:

• ไม่ได้เผยแพร่ DNS record หรือผิดพลาด
• ใช้ selector ผิด
• ไม่ตรงกันระหว่าง DNS และการลงนาม
• ข้อความถูกแก้ไขระหว่างส่ง

วิธีแก้:

• ยืนยัน DNS record มีอยู่ที่ selector._domainkey.domain
• เปรียบเทียบ selector ใน DKIM-Signature header กับ DNS
• สร้าง keys ใหม่หากสงสัยว่าไม่ตรงกัน
• ตรวจสอบ mail filters หรือ relays ที่แก้ไขข้อความ

DKIM key ยาวเกินไปสำหรับ DNS:

อาการ: ไม่สามารถบันทึก DKIM record ได้ ข้อผิดพลาดการตัด

สาเหตุ:

• 2048-bit keys เกินความยาว single TXT record
• ผู้ให้บริการ DNS มีขีดจำกัดตัวอักษร

วิธีแก้:

• แบ่ง key เป็นหลาย quoted strings (ผู้ให้บริการส่วนใหญ่จัดการนี้โดยอัตโนมัติ)
• ตรวจสอบว่าผู้ให้บริการ DNS รองรับ TXT records ยาว
• ใช้ 1024-bit keys ชั่วคราว (ความปลอดภัยน้อยกว่า)

ตัวอย่าง DKIM record ที่แบ่ง:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
"...ต่อ key..."

การแก้ปัญหา DMARC

ความล้มเหลวใน DMARC alignment:

อาการ: SPF และ DKIM ผ่านแต่ DMARC ล้มเหลว

สาเหตุ:

• โดเมนที่ผ่านการยืนยันไม่ตรงกับโดเมนใน From header
• บริการส่งบุคคลที่สามใช้โดเมนของตนเอง
• envelope sender กำหนดค่าผิดพลาด

วิธีแก้:

• ตรวจสอบว่าผู้ให้บริการอีเมลลงนามด้วยโดเมนของคุณ (custom DKIM)
• กำหนดค่า Return-Path/envelope sender แบบกำหนดเอง
• ใช้ relaxed alignment mode (adkim=r; aspf=r)

ไม่รับรายงาน DMARC:

อาการ: ไม่มีรายงาน aggregate มาถึง

สาเหตุ:

• ที่อยู่ rua ไม่ถูกต้อง
• ที่อยู่อีเมลไม่สามารถรับอีเมลภายนอก
• รายงานไปอยู่ในสแปม
• เซิร์ฟเวอร์ผู้รับไม่ส่งรายงาน

วิธีแก้:

• ยืนยัน syntax rua: rua=mailto:[email protected]
• ทดสอบว่าที่อยู่รายงานสามารถรับอีเมลภายนอก
• ตรวจสอบโฟลเดอร์สแปมสำหรับรายงาน
• หมายเหตุ: ไม่ใช่ผู้รับทุกรายส่งรายงาน DMARC

ไม่พบ DMARC record:

อาการ: การตรวจสอบ DMARC แสดง “no record”

สาเหตุ:

• Record เผยแพร่ในตำแหน่งผิด
• ใช้รูปแบบผิด (ต้องเป็น TXT ที่ _dmarc subdomain)

วิธีแก้:

• Record ต้องอยู่ที่ _dmarc.yourdomain.com
• ยืนยันด้วย dig TXT _dmarc.yourdomain.com

เครื่องมือแก้ปัญหาทั่วไป

ตัวตรวจสอบออนไลน์:

• MXToolbox (mxtoolbox.com) - SPF, DKIM, DMARC lookups
• Mail Tester (mail-tester.com) - ส่งอีเมลทดสอบสำหรับการวิเคราะห์เต็มรูปแบบ
• DMARC Analyzer - การแสดงผลรายงาน
• Google Admin Toolbox - ตรวจสอบ MX, SPF, DKIM

เครื่องมือ command line:

# ตรวจสอบ SPF
dig TXT yourdomain.com

# ตรวจสอบ DKIM
dig TXT selector._domainkey.yourdomain.com

# ตรวจสอบ DMARC
dig TXT _dmarc.yourdomain.com

# ตรวจสอบจาก DNS server เฉพาะ
dig @8.8.8.8 TXT yourdomain.com

การวิเคราะห์ email header:

ตรวจสอบ Authentication-Results header ในอีเมลที่รับ:

Authentication-Results: mx.google.com;
  dkim=pass header.d=example.com header.s=brevo;
  spf=pass smtp.mailfrom=example.com;
  dmarc=pass action=none header.from=example.com

Email Authentication กับ Brevo

Brevo รองรับ email authentication อย่างครอบคลุม ทำให้การกำหนดค่า SPF, DKIM และ DMARC สำหรับโดเมนการส่งของคุณเป็นเรื่องง่าย

การตั้งค่า Authentication ใน Brevo

ขั้นตอนที่ 1: เพิ่มโดเมนของคุณ

1. เข้าสู่ระบบบัญชี Brevo ของคุณ
2. ไปที่ Settings > Senders, Domains & Dedicated IPs
3. คลิก Add a Domain
4. ใส่ชื่อโดเมนของคุณ

ขั้นตอนที่ 2: กำหนดค่า SPF

Brevo ให้ SPF include ที่จะเพิ่มใน DNS ของคุณ:

include:spf.brevo.com

เพิ่มสิ่งนี้ใน SPF record ที่มีอยู่หรือสร้างใหม่:

v=spf1 include:spf.brevo.com -all

ขั้นตอนที่ 3: กำหนดค่า DKIM

Brevo สร้าง DKIM keys โดยอัตโนมัติ คัดลอก record ที่ให้มา:

1. ไปที่การตั้งค่าโดเมนใน Brevo
2. ค้นหาส่วน DKIM
3. คัดลอกชื่อ DNS record และค่า
4. เพิ่ม TXT record ใน DNS ของคุณ

ขั้นตอนที่ 4: ยืนยันการกำหนดค่า

Brevo ตรวจสอบ DNS records ของคุณโดยอัตโนมัติ เครื่องหมายถูกสีเขียวแสดงการกำหนดค่าที่สำเร็จ

ประโยชน์ของ Brevo Authentication ที่ถูกต้อง

เมื่อกำหนดค่า authentication กับ Brevo อย่างถูกต้อง:

• Inbox placement สูงขึ้น: Gmail, Microsoft และผู้ให้บริการอื่นๆ ไว้วางใจข้อความที่ผ่านการยืนยัน
• การป้องกันแบรนด์: DMARC ป้องกันการปลอมแปลงโดเมนของคุณ
• Analytics ที่ดีขึ้น: การติดตามการเปิดและคลิกที่แม่นยำ
• การสร้างชื่อเสียง: Authentication ที่สม่ำเสมอสร้าง sender reputation

ประโยชน์ของ Tajo Integration

การใช้ Tajo เพื่อเชื่อมต่อร้านค้า Shopify ของคุณกับ Brevo มีข้อได้เปรียบเพิ่มเติม:

• การซิงค์ลูกค้าอัตโนมัติ: ข้อมูลลูกค้าไหลอย่างราบรื่นสำหรับอีเมลส่วนบุคคล
• การติดตามเหตุการณ์: เหตุการณ์การซื้อ การเรียกดู และตะกร้าสินค้าทริกเกอร์ transactional emails ที่ผ่านการยืนยัน
• การประสานงานหลายช่องทาง: รักษา authentication ที่สม่ำเสมอทั่วอีเมล SMS และ WhatsApp
• Analytics แบบรวม: ติดตามประสิทธิภาพอีเมลควบคู่กับ metrics การตลาดอื่นๆ

การรวมกัน authentication อีเมลที่เหมาะสมและการซิงโครไนซ์ข้อมูลลูกค้าแบบ real-time ทำให้มั่นใจว่าอีเมลของคุณไม่เพียงแต่ถึงกล่องจดหมายแต่ยังสะท้อนกับผู้รับแต่ละคน

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

ความแตกต่างระหว่าง SPF, DKIM และ DMARC คืออะไร?

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

ฉันต้องการทั้งสาม (SPF, DKIM และ DMARC) หรือไม่?

เพื่อ deliverability และความปลอดภัยที่เหมาะสมที่สุด ใช่ SPF เพียงอย่างเดียวมีช่องโหว่ต่อการปลอมแปลง DKIM เพียงอย่างเดียวไม่ระบุนโยบาย DMARC ต้องการ SPF หรือ DKIM เพื่อทำงาน ร่วมกันให้การป้องกันที่ครอบคลุมและอัตรา inbox placement ที่ดีที่สุด

ใช้เวลานานแค่ไหนกว่า email authentication จะทำงาน?

การเปลี่ยนแปลง DNS มักแพร่กระจายภายใน 30 นาทีถึง 48 ชั่วโมง เมื่อแพร่กระจายแล้ว authentication ใช้งานได้ทันที อย่างไรก็ตาม การสร้าง sender reputation จากการ authentication ที่สม่ำเสมอต้องใช้เวลาหลายสัปดาห์ถึงหลายเดือน

การตั้งค่า DMARC ด้วย p=reject จะบล็อกอีเมลที่ถูกต้องหรือไม่?

อาจเป็นได้ถ้าตั้งค่าไม่ถูกต้อง นี่คือเหตุผลที่ควรเริ่มด้วย p=none (monitoring) วิเคราะห์รายงาน 2-4 สัปดาห์ แก้ไขปัญหา จากนั้นค่อยๆ ย้ายไป quarantine และ reject อย่าข้าม monitoring phase

SPF alignment กับ DKIM alignment คืออะไร?

Alignment หมายถึงโดเมนที่ผ่านการยืนยันตรงกับโดเมน From header ที่มองเห็น SPF alignment เปรียบเทียบโดเมน Return-Path DKIM alignment เปรียบเทียบโดเมนการลงนาม (d= tag) DMARC ต้องการให้อย่างน้อยหนึ่งตรงกัน

ฉันสามารถมี DKIM keys หลายรายการสำหรับโดเมนหนึ่งได้หรือไม่?

ได้ บริการอีเมลแต่ละรายสามารถใช้ selector ต่างกันได้ (เช่น brevo._domainkey, google._domainkey) ทำให้หลายบริการลงนามด้วย DKIM อิสระกัน ไม่มีขีดจำกัดจำนวน DKIM selectors

ทำไมอีเมลของฉันยังไปที่สแปมหลังตั้งค่า authentication แล้ว?

Authentication จำเป็นแต่ไม่เพียงพอสำหรับ inbox placement ปัจจัยอื่นๆ รวมถึง sender reputation คุณภาพเนื้อหา อัตราการมีส่วนร่วม และความสะอาดของรายการ Authentication ให้คุณผ่านตัวกรองแรก แนวปฏิบัติที่ดีกำหนดตำแหน่งสุดท้าย

จะอ่านรายงาน aggregate DMARC ได้อย่างไร?

รายงาน aggregate DMARC เป็นไฟล์ XML ใช้เครื่องมือเช่น dmarcian, Postmark DMARC หรือ DMARC Analyzer เพื่อ parse และแสดงผล เครื่องมือเหล่านี้แสดงว่า IP ใดส่งอีเมลในนามโดเมนของคุณและอัตรา authentication pass/fail ของพวกเขา

จะเกิดอะไรขึ้นถ้าฉันเกินขีดจำกัด 10 lookups ของ SPF?

SPF ส่งคืน permanent error (permerror) และการตรวจสอบ SPF ทั้งหมดล้มเหลว ในการแก้ไข ลบ includes ที่ไม่ใช้แล้ว แทนที่ includes ด้วย IP addresses ที่เป็นไปได้ หรือใช้บริการ SPF flattening

ควรใช้ -all หรือ ~all ใน SPF record?

ใช้ ~all (softfail) ระหว่างทดสอบและสร้างความมั่นใจ เมื่อยืนยันว่าแหล่งส่งที่ถูกต้องทั้งหมดผ่านแล้ว เปลี่ยนเป็น -all (hard fail) เพื่อการป้องกันที่แข็งแกร่งขึ้น Softfail ทำเครื่องหมายความล้มเหลวแต่ไม่ปฏิเสธ hard fail อนุญาตการปฏิเสธ

ควรหมุนเวียน DKIM keys บ่อยแค่ไหน?

ไม่มีข้อกำหนดที่เข้มงวด แต่การหมุนเวียนรายปีเป็นแนวปฏิบัติด้านความปลอดภัยที่ดี เมื่อหมุนเวียน เพิ่ม key ใหม่ก่อน รอการแพร่กระจาย DNS เปิดใช้งานการลงนามด้วย key ใหม่ จากนั้นลบ key เก่าหลังช่วงการเปลี่ยนผ่าน

subdomains ต้องการ authentication แยกต่างหากหรือไม่?

SPF: ใช่ แต่ละ subdomain ต้องการ SPF record ของตัวเองถ้าส่งอีเมลจากมัน DKIM: Keys สามารถใช้ร่วมกันหรือแยกตาม subdomain DMARC: Subdomains รับนโยบายผู้ปกครองเว้นแต่จะตั้งค่า sp= หรือ subdomain มี DMARC record ของตัวเอง

สรุป

Email authentication ผ่าน SPF, DKIM และ DMARC ไม่ใช่ทางเลือกอีกต่อไปสำหรับธุรกิจที่พึ่งพาการสื่อสารทางอีเมล โปรโตคอลเหล่านี้ป้องกันแบรนด์ของคุณจากการปลอมแปลง ปรับปรุง deliverability และสร้างความไว้วางใจที่จำเป็นสำหรับ email marketing ที่มีประสิทธิภาพ

สาระสำคัญ:

• SPF อนุญาตเซิร์ฟเวอร์ส่งผ่าน DNS
• DKIM พิสูจน์ความถูกต้องของข้อความด้วยลายเซ็นทางคริปโตกราฟี
• DMARC บังคับใช้นโยบายและให้ visibility ผ่านรายงาน
• เริ่มด้วยการติดตาม (p=none) ก่อนบังคับการปฏิเสธ
• แหล่งส่งที่ถูกต้องทั้งหมดต้องกำหนดค่าอย่างถูกต้อง
• การติดตามสม่ำเสมอป้องกันการ drift ของการกำหนดค่า

สำหรับธุรกิจ e-commerce ที่ใช้ Shopify การรวม email authentication ที่เหมาะสมกับการผสาน customer data ผ่าน Tajo และ Brevo สร้างรากฐานที่แข็งแกร่ง transactional emails ของคุณถึงลูกค้าอย่างน่าเชื่อถือ แคมเปญการตลาดของคุณได้รับ inbox placement ที่ดีขึ้น และแบรนด์ของคุณได้รับการป้องกันจากการโจมตีปลอมแปลง

พร้อมปรับปรุง email deliverability ของคุณแล้วหรือยัง เริ่มต้นด้วยการตรวจสอบการตั้งค่า authentication ปัจจุบันของคุณด้วยเครื่องมือที่กล่าวถึงในคู่มือนี้ จากนั้นตั้งค่า SPF, DKIM และ DMARC อย่างเป็นระบบตามคำแนะนำทีละขั้นตอนที่ให้ไว้

เรียนรู้วิธีที่ Tajo ผสานกับ Brevo เพื่อให้มี email authentication ที่ราบรื่นควบคู่กับการซิงโครไนซ์ข้อมูลลูกค้าแบบ real-time สำหรับร้านค้า Shopify ของคุณ