# SPF, DKIM, DMARC คืออะไร? คู่มือตั้งค่ายืนยันตัวตนอีเมลองค์กรไม่ให้ตกสแปม

> SPF, DKIM และ DMARC คือมาตรฐานยืนยันตัวตนอีเมลที่ Gmail และ Yahoo บังคับใช้ตั้งแต่กุมภาพันธ์ 2024 คู่มือนี้อธิบายหลักการ ตัวอย่างระเบียน DNS และขั้นตอนตั้งค่าจนถึงนโยบาย reject

- ประเภท: คู่มือ · หมวด: Enterprise Apps
- เผยแพร่: 2026-10-01T18:20:00.000Z · อัปเดต: 2026-10-02T10:40:00.000Z
- โดย: กองบรรณาธิการ THAI DATA, THAI DATA IT BUSINESS ENTERPRISE
- ที่มา: https://thaidata.co.th/enterprise-apps/spf-dkim-dmarc-email-authentication-guide/

## สรุปประเด็นสำคัญ

- **SPF** ระบุว่าเซิร์ฟเวอร์ใดส่งอีเมลในนามโดเมนได้ **DKIM** ลงลายเซ็นดิจิทัลบนอีเมล และ **DMARC** บอกผู้รับว่าต้องทำอย่างไรเมื่ออีเมลไม่ผ่านการตรวจ ทั้งสามอย่างตั้งค่าผ่านระเบียน DNS
- ตั้งแต่ **1 กุมภาพันธ์ 2024** Gmail กำหนดให้ผู้ส่งทุกรายมี SPF หรือ DKIM และผู้ส่งเกิน **5,000 ฉบับต่อวัน** ต้องมีครบทั้ง SPF, DKIM และ DMARC ส่วน Yahoo ใช้ข้อกำหนดแนวเดียวกัน
- SPF ค้น DNS ได้ไม่เกิน **10 ครั้ง** ต่อการตรวจหนึ่งรอบ หากเกินจะได้ผล permerror ตาม RFC 7208 ซึ่งเป็นสาเหตุที่พบบ่อยเมื่อองค์กรใช้บริการส่งอีเมลหลายเจ้า
- ควรเริ่ม DMARC ที่ `p=none` เพื่อเก็บรายงานก่อน แล้วค่อยขยับเป็น `quarantine` และ `reject` เมื่อแน่ใจว่าอีเมลจริงทุกแหล่งผ่านการตรวจ

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

เรื่องนี้เปลี่ยนจาก "ควรทำ" เป็น "ต้องทำ" เมื่อ Gmail และ Yahoo เริ่มบังคับใช้ข้อกำหนดสำหรับผู้ส่งอีเมลในเดือนกุมภาพันธ์ 2024 โดเมนที่ไม่ผ่านเกณฑ์เสี่ยงที่อีเมลจะถูกจัดเป็นสแปมหรือถูกปฏิเสธ ขณะเดียวกันโดเมนที่ไม่มี DMARC ก็เปิดช่องให้มิจฉาชีพปลอมชื่อองค์กรส่งอีเมลหลอกลวงลูกค้าและคู่ค้า

## SPF, DKIM, DMARC ทำหน้าที่ต่างกันอย่างไร

| มาตรฐาน | ตรวจอะไร | ระเบียน DNS | เอกสารอ้างอิง |
| --- | --- | --- | --- |
| SPF | เซิร์ฟเวอร์ที่ส่งได้รับอนุญาตจากโดเมนหรือไม่ | TXT ที่ชื่อโดเมน | RFC 7208 (เมษายน 2014) |
| DKIM | ลายเซ็นดิจิทัลบนอีเมลถูกต้องและเนื้อหาไม่ถูกแก้ไข | TXT ที่ `selector._domainkey.โดเมน` | RFC 6376 (กันยายน 2011) |
| DMARC | โดเมนในช่อง From ตรงกับโดเมนที่ผ่าน SPF หรือ DKIM หรือไม่ และผู้รับควรทำอย่างไร | TXT ที่ `_dmarc.โดเมน` | RFC 7489 (มีนาคม 2015) |

![หน้าที่ของ SPF, DKIM และ DMARC และตำแหน่งของระเบียน DNS แต่ละชนิด](https://thaidata.co.th/images/articles/spf-dkim-dmarc-email-authentication-guide/spf-dkim-dmarc-roles.webp) _(ภาพ: THAI DATA (ข้อมูล: RFC 7208, RFC 6376 และ RFC 7489))_

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

SPF (Sender Policy Framework) ให้เจ้าของโดเมนประกาศรายชื่อเซิร์ฟเวอร์ที่มีสิทธิ์ส่งอีเมลในนามโดเมน เมื่อมีอีเมลเข้ามา เซิร์ฟเวอร์ผู้รับจะดูโดเมนในคำสั่ง MAIL FROM ของการเชื่อมต่อ SMTP แล้วค้นระเบียน SPF ของโดเมนนั้นเพื่อเทียบกับ IP ของผู้ส่ง

ตัวอย่างระเบียน SPF ขององค์กรที่ส่งอีเมลผ่าน Google Workspace และเซิร์ฟเวอร์ของตนเองอีกหนึ่งเครื่อง

```
v=spf1 include:_spf.google.com ip4:203.0.113.10 -all
```

ส่วนท้ายของระเบียนคือกลไก `all` ซึ่งตรงกับทุกกรณีที่เหลือ เครื่องหมายนำหน้ากำหนดผลลัพธ์ โดย `-all` หมายถึงไม่ผ่าน (fail) `~all` หมายถึงไม่ผ่านแบบอ่อน (softfail) และ `?all` หมายถึงไม่ระบุ (neutral)

ข้อจำกัดสำคัญที่ RFC 7208 กำหนดไว้มีสองเรื่อง

- **ค้น DNS ได้ไม่เกิน 10 ครั้ง** กลไก `include`, `a`, `mx`, `ptr`, `exists` และตัวปรับแต่ง `redirect` นับเป็นการค้น DNS หากรวมกันเกิน 10 ครั้ง ผู้รับต้องให้ผลเป็น permerror
- **โดเมนหนึ่งมีระเบียน SPF ได้ระเบียนเดียว** หากพบมากกว่าหนึ่งระเบียนจะได้ผล permerror เช่นกัน และต้องใช้ระเบียนชนิด TXT เท่านั้น ระเบียนชนิด SPF แบบเดิมถูกยกเลิกแล้ว

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

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

DKIM (DomainKeys Identified Mail) ให้โดเมนแสดงความรับผิดชอบต่ออีเมลด้วยลายเซ็นดิจิทัล เซิร์ฟเวอร์ผู้ส่งใช้กุญแจส่วนตัวลงลายเซ็นบนส่วนหัวและเนื้อหาของอีเมล แล้วแนบไว้ในส่วนหัวชื่อ `DKIM-Signature` ผู้รับนำกุญแจสาธารณะที่เผยแพร่ใน DNS มาตรวจลายเซ็นนั้น

ในส่วนหัว `DKIM-Signature` มีแท็กสำคัญสองตัว คือ `d=` ซึ่งระบุโดเมนที่รับผิดชอบอีเมล และ `s=` ซึ่งระบุ selector ที่ใช้ชี้ไปยังกุญแจ ผู้รับจะค้นกุญแจสาธารณะที่ชื่อ `selector._domainkey.โดเมน` เช่น

```
selector1._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
```

selector ทำให้โดเมนเดียวมีกุญแจได้หลายชุด เช่น แยกกุญแจของระบบอีเมลพนักงานกับระบบส่งใบแจ้งหนี้ และช่วยให้หมุนเวียนกุญแจได้โดยไม่กระทบการส่ง

ด้านความแข็งแรงของกุญแจ RFC 8301 (มกราคม 2018) กำหนดให้ใช้อัลกอริทึม rsa-sha256 และห้ามใช้ rsa-sha1 ผู้ลงลายเซ็นต้องใช้กุญแจ RSA ไม่ต่ำกว่า 1024 บิต และควรใช้ตั้งแต่ 2048 บิตขึ้นไป

ข้อดีของ DKIM คือลายเซ็นติดไปกับอีเมล จึงยังตรวจผ่านได้แม้อีเมลถูกส่งต่อ ตราบใดที่เนื้อหาส่วนที่ลงลายเซ็นไม่ถูกแก้ไข

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

SPF และ DKIM ตรวจโดเมนที่ผู้ใช้ทั่วไปมองไม่เห็น ผู้ไม่หวังดีจึงยังปลอมชื่อองค์กรในช่อง From ได้ โดยให้อีเมลผ่าน SPF หรือ DKIM ของโดเมนอื่นที่ตนควบคุม DMARC ปิดช่องนี้ด้วยแนวคิด **การจัดแนวโดเมน (alignment)**

ตาม RFC 7489 อีเมลจะผ่าน DMARC เมื่อมีกลไกอย่างน้อยหนึ่งอย่างระหว่าง SPF กับ DKIM ให้ผล pass และโดเมนที่ผ่านนั้นตรงแนวกับโดเมนในช่อง From การจัดแนวมีสองระดับ

- **แบบผ่อนปรน (relaxed)** โดเมนอยู่ภายใต้โดเมนองค์กรเดียวกัน เช่น `mail.example.com` กับ `example.com`
- **แบบเข้มงวด (strict)** ชื่อโดเมนต้องตรงกันทุกตัวอักษร

![DMARC ผ่านเมื่อ SPF หรือ DKIM อย่างน้อยหนึ่งอย่างผ่านและตรงแนวกับโดเมนในช่อง From](https://thaidata.co.th/images/articles/spf-dkim-dmarc-email-authentication-guide/dmarc-evaluation-flow.webp) _(ภาพ: THAI DATA (ข้อมูล: RFC 7489))_

เจ้าของโดเมนประกาศนโยบายด้วยระเบียน TXT ที่ `_dmarc.โดเมน` เช่น

```
_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
```

| แท็ก | ความหมาย |
| --- | --- |
| `p` | นโยบายต่ออีเมลที่ไม่ผ่าน: `none` ไม่ขอให้ดำเนินการ, `quarantine` ให้ถือว่าน่าสงสัย เช่น ส่งเข้าโฟลเดอร์สแปม, `reject` ให้ปฏิเสธ |
| `rua` | ที่อยู่สำหรับรับรายงานสรุป (aggregate report) |
| `ruf` | ที่อยู่สำหรับรับรายงานความล้มเหลวรายฉบับ |
| `pct` | สัดส่วนอีเมล (0–100) ที่ให้ใช้นโยบาย |
| `sp` | นโยบายสำหรับโดเมนย่อย หากไม่ระบุจะใช้ค่าเดียวกับ `p` |
| `adkim`, `aspf` | ระดับการจัดแนวของ DKIM และ SPF (`r` ผ่อนปรน, `s` เข้มงวด) |

รายงานสรุปที่ได้จาก `rua` คือเครื่องมือสำคัญที่สุดในช่วงเริ่มต้น เพราะแสดงว่ามี IP ใดบ้างส่งอีเมลในนามโดเมน และแต่ละแหล่งผ่าน SPF กับ DKIM หรือไม่

![ระเบียน SPF และ DMARC ที่ Google, Yahoo และ Microsoft ประกาศไว้จริง ค้นด้วยคำสั่ง dig เมื่อ 2 ตุลาคม 2026](https://thaidata.co.th/images/articles/spf-dkim-dmarc-email-authentication-guide/real-dmarc-spf-records.webp) _(ภาพ: THAI DATA (ข้อมูล: ระเบียน DNS สาธารณะของ google.com, yahoo.com และ microsoft.com))_

## Gmail และ Yahoo กำหนดอะไรบ้าง

Google ระบุว่าตั้งแต่ 1 กุมภาพันธ์ 2024 ผู้ส่งอีเมลถึงบัญชี Gmail ทุกรายต้องปฏิบัติตามข้อกำหนด และ Yahoo เริ่มบังคับใช้มาตรฐานแนวเดียวกันในเดือนเดียวกัน

| ข้อกำหนด | ผู้ส่งทุกราย | ผู้ส่งปริมาณมาก |
| --- | --- | --- |
| การยืนยันตัวตน | SPF หรือ DKIM อย่างน้อยหนึ่งอย่าง | ต้องมีทั้ง SPF และ DKIM |
| DMARC | ไม่บังคับ | ต้องมี โดยนโยบายเป็น `p=none` ได้ |
| การจัดแนวโดเมน | ไม่บังคับ | โดเมนในช่อง From ต้องตรงแนวกับโดเมนของ SPF หรือ DKIM |
| อัตราการถูกรายงานสแปม | ต่ำกว่า 0.3% | ต่ำกว่า 0.3% |
| DNS ของ IP ผู้ส่ง | ต้องมีระเบียน forward และ reverse ที่ถูกต้อง | เช่นเดียวกัน |
| ยกเลิกรับข่าวสาร | ไม่บังคับ | อีเมลการตลาดต้องรองรับการยกเลิกแบบคลิกเดียว |

Gmail นิยามผู้ส่งปริมาณมากว่าเป็นผู้ที่ส่งอีเมลถึงบัญชี Gmail มากกว่า 5,000 ฉบับต่อวัน และกำหนดให้ผู้ส่งทุกรายใช้การเชื่อมต่อแบบ TLS ส่วน Yahoo ระบุเพิ่มว่าต้องดำเนินการตามคำขอยกเลิกรับข่าวสารภายใน 2 วัน

## ขั้นตอนตั้งค่าสำหรับองค์กร

### ขั้นตอนที่ 1: สำรวจว่าใครส่งอีเมลในนามโดเมน

รวบรวมทุกระบบที่ส่งอีเมลด้วยโดเมนขององค์กร ไม่เฉพาะระบบอีเมลพนักงาน แต่รวมถึงระบบ ERP และบัญชีที่ส่งใบแจ้งหนี้ ระบบ CRM เครื่องมือส่งอีเมลการตลาด ระบบแจ้งเตือนของเว็บไซต์ และเครื่องพิมพ์หรือสแกนเนอร์ที่ส่งอีเมลได้ ระบบที่ตกสำรวจคือสาเหตุหลักที่ทำให้อีเมลจริงถูกปฏิเสธในภายหลัง

### ขั้นตอนที่ 2: สร้างระเบียน SPF ให้ครอบคลุมและไม่เกิน 10 การค้น

รวมผู้ส่งทุกแหล่งไว้ในระเบียน SPF เดียว นับจำนวนการค้น DNS รวมถึงการค้นที่ซ้อนอยู่ใน `include` ของผู้ให้บริการแต่ละราย หากใกล้ถึง 10 ครั้ง ให้ย้ายระบบบางส่วนไปส่งจากโดเมนย่อย เช่น `mail.example.com` ซึ่งมีระเบียน SPF ของตนเอง

### ขั้นตอนที่ 3: เปิด DKIM ให้ทุกระบบที่ส่งอีเมล

สร้างกุญแจขนาด 2048 บิตในแต่ละระบบ เผยแพร่กุญแจสาธารณะใน DNS ตาม selector ที่ระบบกำหนด และตั้งค่าให้ลงลายเซ็นด้วยโดเมนขององค์กรเอง ไม่ใช่โดเมนของผู้ให้บริการ เพราะ DMARC ต้องการให้โดเมนใน `d=` ตรงแนวกับช่อง From

### ขั้นตอนที่ 4: ประกาศ DMARC ที่ p=none พร้อมที่อยู่รับรายงาน

เริ่มด้วยนโยบาย `p=none` และกำหนด `rua` ไปยังกล่องจดหมายหรือบริการวิเคราะห์รายงาน ขั้นนี้ไม่กระทบการส่งอีเมล แต่ทำให้เริ่มเห็นข้อมูลจริง และเพียงพอต่อข้อกำหนดของ Gmail และ Yahoo สำหรับผู้ส่งปริมาณมาก

### ขั้นตอนที่ 5: อ่านรายงานและแก้ไขแหล่งที่ไม่ผ่าน

ติดตามรายงานอย่างน้อย 2–4 สัปดาห์ให้ครอบคลุมรอบการทำงาน เช่น รอบวางบิลสิ้นเดือน แยกแหล่งที่เป็นระบบขององค์กรแต่ยังไม่ผ่านออกจากแหล่งที่เป็นการปลอมแปลง แล้วแก้ SPF หรือ DKIM ของระบบจริงให้ครบ

### ขั้นตอนที่ 6: เพิ่มความเข้มของนโยบายทีละขั้น

เมื่อไม่พบอีเมลจริงที่ไม่ผ่านการตรวจ ให้เปลี่ยนเป็น `p=quarantine` โดยอาจใช้ `pct` เพื่อเริ่มจากบางส่วน แล้วจึงขยับเป็น `p=reject` หลังจากนั้นยังต้องเฝ้าดูรายงานต่อเนื่อง เพราะทุกครั้งที่องค์กรเพิ่มระบบส่งอีเมลใหม่ต้องปรับ SPF และ DKIM ตาม

![ลำดับการขยับนโยบาย DMARC จาก p=none ไปถึง p=reject](https://thaidata.co.th/images/articles/spf-dkim-dmarc-email-authentication-guide/dmarc-policy-steps.webp) _(ภาพ: THAI DATA (ข้อมูล: RFC 7489))_

## ข้อผิดพลาดที่พบบ่อย

- **มีระเบียน SPF มากกว่าหนึ่งระเบียน** มักเกิดเมื่อเพิ่มผู้ให้บริการใหม่โดยสร้างระเบียนใหม่แทนการแก้ระเบียนเดิม ผลคือ permerror และ SPF ใช้ไม่ได้ทั้งโดเมน
- **เกินขีดจำกัด 10 การค้น DNS** พบบ่อยในองค์กรที่ใช้บริการคลาวด์หลายเจ้า
- **ข้ามไปใช้ p=reject ทันที** โดยยังไม่ได้อ่านรายงาน ทำให้อีเมลจริงจากระบบที่ตกสำรวจถูกปฏิเสธ
- **ค้างอยู่ที่ p=none ถาวร** โดเมนผ่านเกณฑ์ขั้นต่ำของผู้ให้บริการอีเมล แต่ยังถูกปลอมแปลงได้เหมือนเดิม
- **ลืมโดเมนที่ไม่ได้ใช้ส่งอีเมล** โดเมนที่จดไว้เฉย ๆ ควรประกาศ SPF เป็น `v=spf1 -all` และ DMARC เป็น `p=reject` เพื่อไม่ให้ถูกนำไปใช้ปลอมแปลง
- **ใช้กุญแจ DKIM 1024 บิตและไม่เคยเปลี่ยน** ควรใช้ 2048 บิตและกำหนดรอบหมุนเวียนกุญแจ

## ผลต่อองค์กรไทย

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

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

1. ตรวจระเบียน SPF, DKIM และ DMARC ของทุกโดเมนที่องค์กรถือครอง รวมถึงโดเมนที่ไม่ได้ใช้ส่งอีเมล
2. มอบหมายผู้รับผิดชอบที่ดูแลทั้งระบบอีเมลและ DNS เพราะงานนี้ต้องแก้ไขทั้งสองฝั่ง
3. กำหนดขั้นตอนว่าทุกครั้งที่จัดซื้อระบบที่ส่งอีเมลในนามองค์กร ต้องตั้งค่า SPF และ DKIM ก่อนเปิดใช้งาน
4. ตั้งเป้าหมายและกรอบเวลาในการไปถึง `p=reject` แทนการหยุดที่ `p=none`

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

### SPF, DKIM และ DMARC ต่างกันอย่างไร?

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

### ถ้ามี SPF แล้วยังต้องทำ DKIM และ DMARC อีกหรือไม่?

ควรทำครบทั้งสามอย่าง เพราะ SPF เพียงอย่างเดียวมักไม่ผ่านเมื่ออีเมลถูกส่งต่อ และไม่ได้ป้องกันการปลอมชื่อผู้ส่งในช่อง From ที่ผู้รับเห็น นอกจากนี้ Gmail และ Yahoo กำหนดให้ผู้ส่งปริมาณมากต้องมีทั้ง SPF, DKIM และ DMARC

### DMARC p=none ป้องกันการปลอมอีเมลได้ไหม?

ไม่ได้ นโยบาย p=none ขอให้ผู้รับไม่ดำเนินการใดกับอีเมลที่ไม่ผ่านการตรวจ ใช้เพื่อเก็บรายงานว่ามีใครส่งอีเมลในนามโดเมนบ้าง การป้องกันจริงเริ่มเมื่อเปลี่ยนเป็น quarantine หรือ reject

### ตั้งค่า SPF, DKIM, DMARC ครบแล้ว ทำไมอีเมลยังตกสแปม?

การยืนยันตัวตนเป็นเพียงเงื่อนไขขั้นต้น ผู้ให้บริการอีเมลยังพิจารณาอัตราที่ผู้รับกดรายงานสแปม ซึ่ง Gmail และ Yahoo กำหนดให้ต่ำกว่า 0.3% รวมถึงชื่อเสียงของโดเมนและ IP เนื้อหาอีเมล และการมีปุ่มยกเลิกรับข่าวสารแบบคลิกเดียวสำหรับอีเมลการตลาด

### ใช้เวลานานแค่ไหนกว่าจะเปลี่ยน DMARC เป็น p=reject ได้?

ขึ้นกับจำนวนระบบที่ส่งอีเมลในนามโดเมน องค์กรที่มีผู้ส่งไม่กี่แหล่งอาจใช้เวลาไม่กี่สัปดาห์ ส่วนองค์กรที่มีระบบจำนวนมากมักใช้เวลาหลายเดือน หลักสำคัญคืออ่านรายงาน DMARC จนไม่พบอีเมลจริงที่ไม่ผ่านการตรวจก่อนเพิ่มความเข้มของนโยบายทีละขั้น


## แหล่งอ้างอิง

- [RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1](https://www.rfc-editor.org/rfc/rfc7208.html) — IETF
- [RFC 6376: DomainKeys Identified Mail (DKIM) Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) — IETF
- [RFC 8301: Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)](https://www.rfc-editor.org/rfc/rfc8301.html) — IETF
- [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc7489.html) — IETF
- [Email sender guidelines](https://support.google.com/a/answer/81126?hl=en) — Google
- [Sender Best Practices](https://senders.yahooinc.com/best-practices/) — Yahoo