หน้าแรก › คู่มือ

ตั้งค่า SPF, DKIM และ DMARC: เรคคอร์ด จุดพลาด และการตรวจสอบ

เผยแพร่ 2026-11-03 ／ อัปเดต 2026-11-03 ／ โดย Yuki Nakazawa

หากคุณส่งอีเมลจากโดเมนของตัวเอง การตั้งค่า SPF, DKIM และ DMARC ไม่ใช่ทางเลือกอีกต่อไป ให้ทำตามลำดับนี้ คือ เผยแพร่เรคคอร์ด SPF หนึ่งรายการ เปิดการลงนาม DKIM ด้วยคีย์ 2048 บิต แล้วเผยแพร่เรคคอร์ด DMARC ที่เริ่มจาก p=none พร้อมเปิดการรายงาน ระหว่างนี้ให้ตรวจสอบด้วยว่า IP address ที่ส่งอีเมลของคุณมี reverse DNS (PTR) ที่ตรงกัน

คู่มือนี้ใช้ได้ไม่ว่าคุณจะส่งจาก shared hosting, VPS ของคุณเอง, Google Workspace, Microsoft 365 หรือบริการส่งอีเมลจำนวนมาก มีเรคคอร์ดที่นำไปปรับใช้ได้ ข้อผิดพลาดที่ทำให้การยืนยันตัวตนล้มเหลวบ่อยที่สุด และวิธียืนยันว่าทุกอย่างทำงานได้จากส่วนหัวของข้อความจริง

ข้อเท็จจริงด้านล่างได้ตรวจสอบกับ RFC และหน้าทางการของ Google, Yahoo และ Microsoft ณ เดือนพฤศจิกายน 2026 ข้อกำหนดของผู้ให้บริการกล่องจดหมายอาจเปลี่ยนแปลงได้ จึงควรถือหน้าของผู้ให้บริการเป็นข้อมูลชี้ขาด

SPF, DKIM และ DMARC พิสูจน์อะไร และลำดับการตั้งค่า

SPF (Sender Policy Framework) ช่วยให้โดเมนระบุใน DNS ได้ว่าเซิร์ฟเวอร์ใดได้รับอนุญาตให้ส่งอีเมลของโดเมนนั้น เซิร์ฟเวอร์ผู้รับจะดูผู้ส่งในซองจดหมาย (ที่อยู่ SMTP MAIL FROM ซึ่งภายหลังจะปรากฏเป็น Return-Path) ดึงเรคคอร์ด SPF ของโดเมนนั้น แล้วตรวจว่า IP address ที่เชื่อมต่อเข้ามาอยู่ในรายการหรือไม่ SPF เพียงอย่างเดียวไม่ได้บอกอะไรเกี่ยวกับที่อยู่ From ที่ผู้อ่านเห็น

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

DMARC (Domain-based Message Authentication, Reporting and Conformance) ผูกทั้งสองอย่างเข้ากับโดเมน From ที่มองเห็นได้ ข้อความจะผ่าน DMARC ก็ต่อเมื่อ SPF หรือ DKIM ผ่าน และโดเมนที่ยืนยันตัวตนตรง (aligned) กับโดเมน From เรคคอร์ด DMARC ยังบอกผู้รับด้วยว่าคุณต้องการให้จัดการข้อความที่ไม่ผ่านอย่างไร (ไม่ทำอะไร กักกัน หรือปฏิเสธ) และให้ส่งรายงานสรุป (aggregate report) ไปที่ใด ซึ่งเป็นวิธีที่คุณจะพบแหล่งส่งอีเมลที่ลืมไปแล้ว

ลำดับการตั้งค่า

1. ทำรายการทุกระบบที่ส่งอีเมลในนามโดเมนของคุณ ได้แก่ เซิร์ฟเวอร์ของคุณเอง Google Workspace หรือ Microsoft 365 บริการจดหมายข่าวและอีเมลธุรกรรม ฟอร์มบนเว็บ เครื่องมือออกใบแจ้งหนี้และระบบ help desk
2. เผยแพร่เรคคอร์ด SPF เพียงรายการเดียวที่ครอบคลุมทั้งหมด
3. เปิด DKIM ในแต่ละระบบที่ส่ง และเผยแพร่ public key ของระบบนั้น
4. เผยแพร่ DMARC ด้วย p=none และที่อยู่สำหรับรับรายงาน rua Google แนะนำให้รอ 48 ชั่วโมงหลังตั้งค่า SPF และ DKIM ก่อนเพิ่ม DMARC
5. อ่านรายงาน แก้ไขแหล่งส่งที่ไม่ผ่าน แล้วจึงเปลี่ยนเป็น p=quarantine และสุดท้ายเป็น p=reject

ตั้งค่า SPF: เรคคอร์ดเดียว lookup ไม่เกินสิบครั้ง

SPF คือเรคคอร์ด TXT บนตัวโดเมนเอง ตัวอย่างนี้เป็นโดเมนที่ส่งจากเซิร์ฟเวอร์ของตนเองผ่าน IPv4 และ IPv6 และใช้ Google Workspace ด้วย

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

ในแผงควบคุม DNS ส่วนใหญ่ ให้เว้นช่อง host ว่างไว้ (หรือใส่ @) เลือก TXT แล้ววางค่าที่ขึ้นต้นด้วย v=spf1 ส่วนประกอบที่ใช้บ่อย:

จุดพลาดของ SPF

• หนึ่งชื่อต่อหนึ่งเรคคอร์ด SPF RFC 7208 ห้ามมีเรคคอร์ด SPF หลายรายการสำหรับโดเมนเดียวกัน ผู้รับจะตอบกลับ permerror และ SPF จะล้มเหลวทั้งหมด เมื่อเพิ่มบริการใหม่ ให้แก้ไขเรคคอร์ดเดิมแล้วต่อท้ายด้วย include: ของบริการนั้น แทนที่จะสร้างเรคคอร์ด v=spf1 รายการที่สอง
• ข้อจำกัด 10 lookup กลไก include, a, mx, ptr และ exists รวมถึง modifier redirect ล้วนทำให้เกิดการค้นหา DNS และจำนวนรวมตลอดการประเมิน รวมถึงการค้นหาภายใน include ที่ซ้อนกัน ต้องไม่เกิน 10 ครั้ง หากเกินจะได้ permerror ส่วน ip4:, ip6: และ all ไม่นับ นอกจากนี้ RFC 7208 ระบุว่าผู้รับควรหยุดหลังการค้นหาที่ไม่ได้คำตอบสองครั้ง จึงควรนำ include ของบริการที่ไม่ได้ใช้แล้วออก
• ~all กับ -all -all หมายถึงแหล่งที่ไม่อยู่ในรายการไม่ได้รับอนุญาต (fail) ส่วน ~all หมายถึงน่าจะไม่ได้รับอนุญาต (softfail) Google แนะนำ ~all สำหรับโดเมน Workspace ส่วน Microsoft แนะนำ -all สำหรับโดเมน Microsoft 365 ที่ใช้ DKIM และ DMARC ด้วย หากยังไม่แน่ใจว่าพบผู้ส่งครบทุกราย ให้เริ่มจาก ~all แล้วให้ DMARC เป็นตัวบังคับใช้
• ซับโดเมนต้องมีเรคคอร์ดของตนเอง เรคคอร์ด SPF บน example.com ไม่ครอบคลุม news.example.com การให้บริการส่งอีเมลจำนวนมากใช้ซับโดเมนของตนเองยังได้โควตา 10 lookup แยกต่างหาก และแยกชื่อเสียงออกจากอีเมลของพนักงาน
• ไวยากรณ์ผิดพลาด Microsoft ระบุข้อผิดพลาดที่พบบ่อยไว้ ได้แก่ ใช้ include= แทน include: มีช่องว่างหลังเครื่องหมายทวิภาค และมีจุดต่อท้ายโดเมนที่ include

สำหรับโดเมนที่ไม่เคยส่งอีเมล ให้เผยแพร่ v=spf1 -all เพื่อให้ปลอมแปลงได้ยากขึ้น

ตั้งค่า DKIM: คีย์ 2048 บิตและ selector

DKIM มีสองส่วน คือ ระบบที่ส่งลงนามด้วย private key และ DNS เผยแพร่ public key ที่คู่กัน สำหรับ Google Workspace, Microsoft 365 แผงควบคุมโฮสติ้งส่วนใหญ่ และบริการอีเมลส่วนใหญ่ คุณจะสร้างคีย์ในคอนโซลผู้ดูแลระบบแล้วคัดลอกค่า DNS ที่แสดงขึ้นมา

ความยาวคีย์และ selector

ใช้คีย์ RSA 2048 บิต RFC 8301 กำหนดขั้นต่ำไว้ที่ 1024 บิต และระบุว่าผู้ลงนามควรใช้อย่างน้อย 2048 บิต รวมทั้งห้ามใช้ rsa-sha1 คำแนะนำของ Google สอดคล้องกัน คือเลือก 2048 บิตหากผู้ให้บริการ DNS รองรับ และใช้ 1024 เฉพาะเมื่อไม่รองรับเท่านั้น

selector คือป้ายชื่อที่ระบุว่าคีย์ใดเป็นผู้ลงนามข้อความ โดเมนหนึ่งจึงมีหลายคีย์พร้อมกันได้ เช่น หนึ่งคีย์ต่อบริการที่ส่ง หรือหนึ่งคีย์ต่อรอบการหมุนเวียนคีย์ public key อยู่ที่ selector._domainkey.yourdomain Google Workspace ใช้ google เป็น selector ค่าเริ่มต้น ส่วน Microsoft 365 ใช้เรคคอร์ด CNAME สองรายการ คือ selector1._domainkey และ selector2._domainkey ซึ่งชี้ไปยังคีย์ที่ Microsoft โฮสต์ไว้ ให้นำปลายทางที่ถูกต้องจาก Defender portal หรือ Get-DkimSigningConfig เพราะรูปแบบแตกต่างกันไปตาม tenant

การเผยแพร่ public key ที่ยาว

public key ขนาด 2048 บิตยาวกว่า 255 อักขระที่ DNS character-string หนึ่งชุดรองรับ ในรูปแบบ zone file จึงเขียนเป็นสตริงในเครื่องหมายคำพูดหลายชุดภายในเรคคอร์ด TXT เดียว

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

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

บน VPS ของคุณเองที่ใช้ Postfix หรือ MTA ลักษณะเดียวกัน milter สำหรับลงนามอย่าง OpenDKIM สามารถสร้างคู่คีย์ได้ เช่น opendkim-genkey -b 2048 -s selector1 -d example.com แล้วเผยแพร่เนื้อหาของไฟล์ public key ที่สร้างขึ้นตามตัวอย่างด้านบน

ตรวจว่าข้อความถูกลงนามจริง

เปิดข้อความที่คุณส่งแล้วหาส่วนหัว DKIM-Signature: แท็ก d= ควรเป็นโดเมนของคุณ และ s= ควรเป็น selector ที่คุณเผยแพร่ไว้ บริการอีเมลหลายแห่งลงนามด้วยโดเมนของตนเองเป็นค่าเริ่มต้น ซึ่งผ่าน DKIM แต่ไม่ตรง (aligned) กับโดเมน From ของคุณ จึงไม่ช่วยเรื่อง DMARC ให้เปิดการยืนยันตัวตนด้วยโดเมนที่กำหนดเอง (custom domain authentication) ของบริการนั้น เพื่อให้ d= เป็นโดเมนของคุณ

ตั้งค่า DMARC: เริ่มที่ p=none แล้วค่อยบังคับใช้

DMARC คือเรคคอร์ด TXT ที่ _dmarc ภายใต้โดเมนของคุณ ให้เริ่มในโหมดเฝ้าดู ซึ่งขอให้ผู้รับไม่เปลี่ยนวิธีจัดการอีเมลของคุณ และขอรับรายงานสรุป

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

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

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

alignment อธิบายแบบเข้าใจง่าย

เพื่อให้ผ่าน DMARC อย่างน้อย SPF หรือ DKIM อย่างใดอย่างหนึ่งต้องผ่านสำหรับโดเมนที่ตรงกับโดเมน From ในโหมดผ่อนปรน โดเมนระดับองค์กรต้องตรงกัน ลายเซ็น DKIM ที่มี d=example.com จึงตรงกับอีเมลจาก alerts@news.example.com ส่วนโหมดเข้มงวดต้องตรงกันทุกตัว บริการอีเมลมักใช้โดเมนของตนเองใน Return-Path ดังนั้น SPF จะไม่ตรงแม้จะผ่าน DKIM ที่ตรง (aligned) จึงเป็นวิธีที่ใช้ได้จริงในการทำให้ข้อความเหล่านั้นผ่าน DMARC

หากต้องการนโยบายที่ต่างออกไปสำหรับซับโดเมน ให้เพิ่ม sp= ตัวอย่างเช่น p=reject; sp=quarantine จะปฏิเสธอีเมลที่ไม่ผ่านจากโดเมนหลัก แต่เพียงกักกันอีเมลที่ไม่ผ่านจากซับโดเมน

หมายเหตุเกี่ยวกับมาตรฐานฉบับปรับปรุง

ในเดือนพฤษภาคม 2026 DMARC ได้รับการเผยแพร่ใหม่เป็น RFC 9989 ซึ่งแทนที่ RFC 7489 เรคคอร์ดที่มีอยู่ยังใช้งานได้และยังขึ้นต้นด้วย v=DMARC1 มาตรฐานใหม่ตัดแท็ก pct ออก ซึ่งแทบไม่ถูกนำไปใช้อย่างแม่นยำยกเว้นที่ค่า 0 หรือ 100 และเพิ่มแท็กอย่าง t=y (โหมดทดสอบ) และ np (นโยบายสำหรับซับโดเมนที่ไม่มีอยู่จริง) หน้าความช่วยเหลือของผู้ให้บริการบางรายยังแสดง pct อยู่ วิธีที่กำกวมน้อยที่สุดในการเริ่มบังคับใช้จึงเป็นการไล่เปลี่ยนค่า p= ทีละขั้น

Reverse DNS (PTR) สำหรับ IP ที่ใช้ส่ง

Reverse DNS จับคู่ IP address กลับไปยังชื่อโฮสต์ Google กำหนดให้ผู้ส่งทุกรายที่ส่งถึงบัญชี Gmail ส่วนตัวต้องมีเรคคอร์ด PTR ที่ชื่อโฮสต์แปลงกลับเป็น IP ที่ใช้ส่งเดียวกัน และ Yahoo กำหนดให้ IP ที่ใช้ส่งต้องมี forward DNS และ reverse DNS ที่ถูกต้อง พร้อมแนะนำให้ใช้เรคคอร์ด PTR ที่มีความหมายและไม่ใช่ชื่อทั่วไป

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

เรคคอร์ด PTR ไม่ได้อยู่ใน zone ของโดเมนคุณ ผู้ที่เป็นเจ้าของ IP address เป็นผู้ควบคุม บน VPS จึงต้องตั้งค่าในแผงควบคุมของผู้ให้บริการ (มักเรียกว่า reverse DNS หรือ rDNS) แล้วสร้างเรคคอร์ด A ที่ตรงกัน (AAAA สำหรับ IPv6) ใน DNS ของคุณเอง หากส่งผ่าน IPv6 ที่อยู่ IPv6 ก็ต้องตั้งค่าแบบเดียวกัน สำหรับ Google Workspace, Microsoft 365 บริการอีเมล และ shared hosting ส่วนใหญ่ ผู้ให้บริการจะดูแล IP ที่ใช้ส่งและ reverse DNS ให้

วิธีตรวจสอบการตั้งค่า

อ่าน Authentication-Results

ส่งข้อความทดสอบไปยังกล่องจดหมายภายนอก แล้วดูส่วนหัวทั้งหมด ใน Gmail ให้เปิดข้อความแล้วเลือก แสดงต้นฉบับ หน้าความช่วยเหลือเรื่อง DKIM ของ Google ระบุว่าควรส่งถึงผู้ใช้อื่น ไม่ใช่ส่งถึงตัวเอง ให้มองหาส่วนหัวลักษณะนี้

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

รูปแบบที่แน่นอนแตกต่างกันไปตามผู้รับ สิ่งสำคัญคือ spf=pass, dkim=pass และ dmarc=pass โดยมีโดเมนของคุณเองอยู่ใน header.i หรือ header.d และใน header.from หาก SPF ผ่านสำหรับโดเมนของบริการ แต่ DKIM แสดงโดเมนอื่น DMARC จะล้มเหลว ให้แก้ DKIM alignment ก่อน

ค้นหา DNS โดยตรง

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

บน Windows คำสั่ง nslookup -type=TXT _dmarc.example.com ทำงานได้เหมือนกัน การเปลี่ยนแปลง DNS อาจใช้เวลาในการแพร่กระจาย Google ระบุว่า SPF และ DKIM อาจใช้เวลาถึง 48 ชั่วโมงกว่าจะเริ่มทำงาน เครื่องมือตรวจสอบออนไลน์ฟรีก็ช่วยแยกวิเคราะห์เรคคอร์ดและนับจำนวน lookup ของ SPF ให้ได้

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

ข้อกำหนดผู้ส่งของ Gmail, Yahoo และ Outlook.com

ผู้ให้บริการกล่องจดหมายรายใหญ่บังคับใช้การยืนยันตัวตนแล้ว ณ เดือนพฤศจิกายน 2026 หน้าทางการของแต่ละรายระบุไว้ดังนี้

• Gmail (มีผลตั้งแต่ 1 กุมภาพันธ์ 2024): ทุกคนที่ส่งถึงบัญชี Gmail ส่วนตัวต้องมี SPF หรือ DKIM, forward DNS และ reverse DNS ที่ตรงกัน, การเชื่อมต่อ TLS และอัตราสแปมใน Postmaster Tools ต่ำกว่า 0.3% ผู้ที่ส่งมากกว่า 5,000 ฉบับต่อวันต้องมีทั้ง SPF และ DKIM เรคคอร์ด DMARC (ใช้ p=none ได้) โดเมน From ที่ตรง (aligned) กับ SPF หรือ DKIM และการยกเลิกการสมัครรับด้วยคลิกเดียวสำหรับอีเมลการตลาด คีย์ DKIM ต้องมีอย่างน้อย 1024 บิต และแนะนำ 2048
• Yahoo (บังคับใช้ตั้งแต่กุมภาพันธ์ 2024): ผู้ส่งทุกรายต้องมี SPF หรือ DKIM, forward DNS และ reverse DNS ที่ถูกต้อง และอัตราสแปมต่ำกว่า 0.3% ผู้ส่งจำนวนมากต้องมีทั้ง SPF และ DKIM นโยบาย DMARC อย่างน้อย p=none ที่ผ่าน alignment ของ From (แบบผ่อนปรนก็ได้) การยกเลิกการสมัครรับด้วยคลิกเดียวที่ใช้งานได้ และ forward DNS กับ reverse DNS ที่ถูกต้องสำหรับ IP ที่ใช้ส่ง
• Outlook.com (บริการสำหรับผู้บริโภคที่อยู่เบื้องหลัง outlook.com, hotmail.com และ live.com): โดเมนที่ส่งมากกว่า 5,000 ฉบับต่อวันต้องผ่าน SPF และ DKIM และเผยแพร่ DMARC อย่างน้อย p=none ที่ตรง (aligned) กับ SPF หรือ DKIM Microsoft ระบุว่าตั้งแต่วันที่ 5 พฤษภาคม 2025 ข้อความที่ไม่เป็นไปตามข้อกำหนดจะถูกปฏิเสธด้วยข้อผิดพลาด 550; 5.7.515

อ่านฉบับเต็มได้ที่ หลักเกณฑ์สำหรับผู้ส่งอีเมลของ Google, แนวทางปฏิบัติที่ดีสำหรับผู้ส่งของ Yahoo และประกาศเกี่ยวกับ Outlook.com ของ Microsoft แม้คุณจะส่งน้อยกว่านี้มาก การตั้งค่าทั้งสามอย่างไว้ตั้งแต่ตอนนี้ก็ช่วยให้ไม่ได้รับผลกระทบหากเกณฑ์ลดลงในภายหลัง สำหรับการแก้ปัญหาเฉพาะ Gmail โปรดดูGmail ไม่ส่งอีเมลของคุณ

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

• มีเรคคอร์ด SPF รายการที่สอง การเพิ่มเรคคอร์ด v=spf1 ใหม่สำหรับแต่ละบริการทำให้ SPF ของทั้งโดเมนใช้ไม่ได้ ให้รวมทุกอย่างไว้ในรายการเดียว
• include มากเกินไป บริการเก่าที่ค้างอยู่ใน SPF กินโควตา 10 lookup ให้นำสิ่งที่ไม่ได้ใช้แล้วออก และย้ายอีเมลจำนวนมากไปยังซับโดเมน
• เผยแพร่คีย์แล้วแต่ยังไม่เปิดการลงนาม ใน Google Workspace คุณยังต้องคลิก เริ่มตรวจสอบสิทธิ์ (Start authentication) หลังจากเรคคอร์ด DNS มีผลแล้ว แพลตฟอร์มอื่นก็มีสวิตช์ลักษณะเดียวกัน
• บริการลงนามด้วยโดเมนของตนเอง ทั้ง SPF และ DKIM ผ่าน แต่ DMARC ไม่ผ่าน ให้เปิดการลงนามด้วยโดเมนที่กำหนดเอง
• กระโดดไปที่ p=reject ทันที ฟอร์มบนเว็บหรือระบบออกใบแจ้งหนี้ที่ลืมไปจะส่งอีเมลไม่ได้ในชั่วข้ามคืน ให้เริ่มที่ p=none และอ่านรายงาน
• ความเสียหายจากการคัดลอกและวาง มีเครื่องหมายคำพูดเกินมาในค่า คีย์ถูกตัดขาด หรือชื่อโฮสต์กลายเป็น _dmarc.example.com.example.com เพราะแผงควบคุมต่อท้ายโดเมนให้เอง การตรวจด้วย dig สั้น ๆ จะพบปัญหาเหล่านี้ทั้งหมด

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

หน้าทางการที่ใช้อ้างอิง

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

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

คู่มือที่เกี่ยวข้อง

คู่มือทั้งหมด →