---
title: "SPF, DKIM และ DMARC: คู่มือ Email Authentication ฉบับสมบูรณ์"
description: "เชี่ยวชาญการยืนยันตัวตนอีเมลด้วยคู่มือฉบับสมบูรณ์ของ SPF, DKIM และ DMARC เรียนรู้ว่าแต่ละโปรโตคอลทำอะไร วิธีตั้งค่า DNS records แก้ปัญหาที่พบบ่อย และปรับปรุง email deliverability ของคุณ"
url: https://tajo.io/th/blog/spf-dkim-dmarc-guide/
markdown: https://tajo.io/th/blog/spf-dkim-dmarc-guide.md
lang: th-TH
author: "Set Noa"
author_url: https://tajo.io/th/set-noa/
published: 2026-03-08
updated: 2026-05-10
alternates: {en-US: /blog/spf-dkim-dmarc-guide.md, bg-BG: /bg/blog/spf-dkim-dmarc-guide.md, cs-CZ: /cz/blog/spf-dkim-dmarc-guide.md, de-DE: /de/blog/spf-dkim-dmarc-guide.md, da-DK: /dk/blog/spf-dkim-dmarc-guide.md, es-ES: /es/blog/spf-dkim-dmarc-guide.md, fr-FR: /fr/blog/spf-dkim-dmarc-guide.md, el-GR: /gr/blog/spf-dkim-dmarc-guide.md, hi-IN: /hi/blog/spf-dkim-dmarc-guide.md, id-ID: /in/blog/spf-dkim-dmarc-guide.md, hr-HR: /hr/blog/spf-dkim-dmarc-guide.md, it-IT: /it/blog/spf-dkim-dmarc-guide.md, ja-JP: /jp/blog/spf-dkim-dmarc-guide.md, ko-KR: /kr/blog/spf-dkim-dmarc-guide.md, ar-SA: /ar/blog/spf-dkim-dmarc-guide.md, nl-NL: /nl/blog/spf-dkim-dmarc-guide.md, pl-PL: /pl/blog/spf-dkim-dmarc-guide.md, ro-RO: /ro/blog/spf-dkim-dmarc-guide.md, ru-RU: /ru/blog/spf-dkim-dmarc-guide.md, sv-SE: /se/blog/spf-dkim-dmarc-guide.md, zh-CN: /zh-cn/blog/spf-dkim-dmarc-guide.md, sl-SI: /sl/blog/spf-dkim-dmarc-guide.md, sr-Latn-RS: /sr/blog/spf-dkim-dmarc-guide.md, tr-TR: /tr/blog/spf-dkim-dmarc-guide.md, ur-PK: /ur/blog/spf-dkim-dmarc-guide.md, vi-VN: /vi/blog/spf-dkim-dmarc-guide.md, sk-SK: /sk/blog/spf-dkim-dmarc-guide.md}
---

[อีเมล](https://tajo.io/th/blog/?category=email)

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

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

SPF DKIM DMARC

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

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

[เรียนรู้เพิ่มเติม](https://tajo.io/th/blog/spf-dkim-dmarc-guide/#%E0%B8%97%E0%B8%B3%E0%B9%84%E0%B8%A1-email-authentication-%E0%B8%88%E0%B8%B6%E0%B8%87%E0%B8%AA%E0%B8%B3%E0%B8%84%E0%B8%B1%E0%B8%8D)

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 | กำหนดนโยบายสำหรับความล้มเหลว + รายงาน | คำแนะนำว่าจะทำอย่างไรกับจดหมายที่น่าสงสัย |

แต่ละโปรโตคอลแก้ไขเวกเตอร์การโจมตีที่แตกต่างกัน 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:** กำหนดว่าใครส่งได้

| Mechanism | คำอธิบาย | ตัวอย่าง |
| --- | --- | --- |
| include: | ไว้ใจ SPF ของโดเมนอื่น | include:spf.brevo.com |
| ip4: | อนุญาต IPv4 ที่ระบุ | ip4:192.168.1.1 |
| ip6: | อนุญาต IPv6 ที่ระบุ | ip6:2001:db8::1 |
| a | อนุญาต IP จาก A record ของโดเมน | a |
| mx | อนุญาต IP ของเมลเซิร์ฟเวอร์โดเมน | mx |
| ptr | Reverse DNS (เลิกใช้แล้ว) | ptr:example.com |
| exists: | เงื่อนไขตรวจสอบ | exists:%{i}.spf.example.com |

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

| Qualifier | ความหมาย | ผลลัพธ์ |
| --- | --- | --- |
| + | Pass (default) | ได้รับอนุญาต |
| - | Fail (hard) | ไม่ได้รับอนุญาต ปฏิเสธ |
| ~ | SoftFail | ไม่ได้รับอนุญาต รับแต่ทำเครื่องหมาย |
| ? | Neutral | ไม่มีนโยบาย |

**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 ที่จำเป็น ตัวอย่างที่พบบ่อย:

| ผู้ให้บริการ | SPF Include |
| --- | --- |
| Brevo | include:spf.brevo.com |
| Google Workspace | include:\_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| Amazon SES | include:amazonses.com |
| SendGrid | include:sendgrid.net |
| Mailgun | include:mailgun.org |

**ขั้นตอนที่ 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 เพื่อยืนยัน:

```bash
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:**

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

Correct:
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...
```

| Tag | คำอธิบาย | ตัวอย่าง |
| --- | --- | --- |
| v= | Version (DKIM1 เสมอ) | v=DKIM1 |
| k= | ประเภท key (มักเป็น rsa) | k=rsa |
| p= | Public key (base64) | p=MIGfMA0… |
| t= | Flags (ตัวเลือก) | t=s (strict mode) |
| h= | Hash algorithms (ตัวเลือก) | h=sha256 |

### การตั้งค่า DKIM

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

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

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

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

```bash
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;
```

| Tag | ความหมาย |
| --- | --- |
| v= | Version (1 เสมอ) |
| a= | Algorithm (แนะนำ rsa-sha256) |
| c= | Canonicalization (relaxed อนุญาตการเปลี่ยนแปลงเล็กน้อย) |
| d= | Signing domain |
| s= | Selector |
| h= | Signed headers |
| bh= | Body hash |
| b= | Signature |

## ทำความเข้าใจ 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 ให้คุณ

*How DMARC decides what happens to a message*

### 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:**

| Mode | คำอธิบาย |
| --- | --- |
| Strict (s) | ต้องการการ match โดเมนที่แน่นอน |
| Relaxed (r) | อนุญาต subdomains (ค่าเริ่มต้น) |

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

### ไวยากรณ์ DMARC Record

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

```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
```

**Tags ที่จำเป็น:**

| Tag | คำอธิบาย | ค่า |
| --- | --- | --- |
| v= | Version | DMARC1 (เสมอ) |
| p= | Policy | none, quarantine, reject |

**Tags ตัวเลือก:**

| Tag | คำอธิบาย | ค่าเริ่มต้น |
| --- | --- | --- |
| rua= | ที่อยู่รายงาน aggregate | ไม่มี |
| ruf= | ที่อยู่รายงาน forensic | ไม่มี |
| pct= | เปอร์เซ็นต์ที่ใช้นโยบาย | 100 |
| sp= | นโยบาย subdomain | เหมือน p= |
| adkim= | DKIM alignment mode | r (relaxed) |
| aspf= | SPF alignment mode | r (relaxed) |
| fo= | ตัวเลือกรายงาน forensic | 0 |
| ri= | ช่วงเวลารายงาน (วินาที) | 86400 |

### อธิบาย DMARC Policies

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

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

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

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

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

```
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100
```

**p=reject (บล็อก):**

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

```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
```

### การตั้งค่า DMARC

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

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

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

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

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

**ขั้นตอนที่ 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
- ปริมาณอีเมล

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

```xml
<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 เพื่อยืนยัน:

```bash
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 from Brevo dashboard]
```

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

```
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BA... [key from Google Admin]
```

**DMARC record (TXT ที่ \_dmarc):**

```
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
```

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

แม้ตั้งค่าอย่างระมัดระวัง 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..."
"...continuation of 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:address@domain.com`
- ทดสอบว่าที่อยู่รายงานสามารถรับอีเมลภายนอก
- ตรวจสอบโฟลเดอร์สแปมสำหรับรายงาน
- หมายเหตุ: ไม่ใช่ผู้รับทุกรายส่งรายงาน 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:**

```bash
# Check SPF
dig TXT yourdomain.com

# Check DKIM
dig TXT selector._domainkey.yourdomain.com

# Check DMARC
dig TXT _dmarc.yourdomain.com

# Check from specific 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

## สรุป

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

**สาระสำคัญ:**

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

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

## Tajo เหมาะกับส่วนไหน

Tajo คือเครื่องมือสร้างการเชื่อมต่อที่ขับเคลื่อนด้วยเอเจนต์ ใช้ผู้ให้บริการเดิมของคุณต่อไป เอเจนต์เชื่อมทุกอย่างที่เหลือ และคุณอนุมัติการซิงค์ทุกรายการ Tajo อยู่ในช่วงทดลองใช้ก่อนเปิดตัว [ขอสิทธิ์ใช้งานก่อน](https://tajo.io/th/#early-access)

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

**SPF, DKIM และ DMARC คืออะไร**

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

**ต้องใช้ทั้งสามอย่าง (SPF, DKIM, DMARC) ไหม**

ต้องใช้ Google และ Yahoo กำหนดให้ผู้ส่งทุกรายต้องมี SPF และ DKIM แล้ว และผู้ที่ส่งเกิน 5,000 อีเมลต่อวันต้องมี DMARC การใช้ทั้งสามอย่างร่วมกันให้ความสามารถในการส่งถึงและความปลอดภัยที่ดีที่สุด

**ตั้งค่า SPF, DKIM และ DMARC อย่างไร**

เพิ่มระเบียน DNS ให้โดเมนของคุณ: SPF เป็นระเบียน TXT ที่ระบุผู้ส่งที่ได้รับอนุญาต DKIM เป็นระเบียน TXT ที่มีคีย์สาธารณะของคุณ และ DMARC เป็นระเบียน TXT ที่มีนโยบายของคุณ แพลตฟอร์มอีเมลของคุณจะให้ค่าที่ต้องใช้

**ความแตกต่างระหว่าง 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 Blacklist: คู่มือฉบับสมบูรณ์ของการตรวจหา การถอด และการป้องกัน](https://tajo.io/th/blog/email-blacklist-check-guide/)

8 มี.ค. 2569 · 7 นาทีอ่าน

9 ส่วน

### [Email Deliverability: คู่มือฉบับสมบูรณ์เพื่อให้อีเมลเข้าถึง Inbox \[2025\]](https://tajo.io/th/blog/email-deliverability-complete-guide/)

8 มี.ค. 2568 · 8 นาทีอ่าน

13 ส่วน

### [เซิร์ฟเวอร์ MCP คืออะไร MCP และ MCP UI ทำงานอย่างไรในปี 2026](https://tajo.io/th/blog/what-is-an-mcp-server/)

3 ต.ค. 2569 · 5 นาทีอ่าน

ขั้นที่ 1 → ขั้นที่ 6