DMARC ล้มเหลวแต่ SPF และ DKIM ผ่าน? การแก้ไขการจัดตำแหน่ง (2026)

เผยแพร่ 2026-07-08

ตัวเลข ณ วันที่ 2026-06-29 · ระเบียบวิธี v7 ข้อมูลสำมะโนรวมทั่ว 261 ล้านโดเมนที่ได้รับการให้คะแนน ดู วิธีที่เราให้คะแนน

DMARC ต้องการมากกว่าการผ่าน — โดเมนที่ผ่าน SPF หรือ DKIM ต้องตรงกับโดเมน From ของคุณ อีเมล “SPF pass, DMARC fail” ส่วนใหญ่ผ่าน SPF บนโดเมน bounce ของผู้ขาย ไม่ใช่ของคุณ มีเพียง 7.4% ของ 261,086,232 โดเมนที่ได้รับการให้คะแนนที่ผ่าน SPF ด้วยการจัดตำแหน่งภายใต้นโยบาย DMARC ที่บังคับใช้ ตามสำมะโน Defaults.Exposed (2026-06-29)

การแก้ไขเร็วกว่าที่ความสับสนแนะนำ อ่าน header Authentication-Results เพื่อดูว่าขาใด — SPF หรือ DKIM — กำลังผ่านบนโดเมนที่ผิด จากนั้นเปิดใช้งานการลงนาม DKIM ด้วยโดเมนที่กำหนดเองของบริการส่งของคุณ (ปกติคือ CNAME สองสามตัว และการแก้ไขที่รอดชีวิตจากการส่งต่อ) หรือตั้งค่า return-path ที่กำหนดเองเพื่อให้ SPF ผ่านบนโดเมนของคุณ ขาที่จัดตำแหน่งหนึ่งขาคือทั้งหมดที่ DMARC ต้องการ

DMARC จะล้มเหลวได้อย่างไรเมื่อ SPF และ DKIM ทั้งคู่ผ่าน?

เพราะ DMARC ไม่เคยถาม “SPF ผ่านหรือไม่?” มันถาม: SPF หรือ DKIM ผ่าน สำหรับโดเมนที่ตรงกับที่อยู่ From ที่ผู้รับของคุณเห็นหรือไม่? เงื่อนไขพิเศษนั้นเรียกว่า การจัดตำแหน่ง และมันคือจุดทั้งหมดของ DMARC — หากไม่มีมัน ใครก็สามารถผ่าน SPF บนโดเมนที่พวกเขาเป็นเจ้าของในขณะที่แสดงของคุณใน header From

การตรวจสอบแต่ละอย่างยืนยันตัวตนโดเมนที่แตกต่าง:

การตรวจสอบ	โดเมนที่ประเมินจริง	ที่จะดู
SPF	Return-Path (RFC5321.MailFrom, ที่อยู่ bounce/envelope-from) — ไม่ใช่ header From	`smtp.mailfrom=` ใน Authentication-Results
DKIM	โดเมนใน tag `d=` ของลายเซ็น — ไม่ว่า signer จะเลือกอะไร	`header.d=` ใน Authentication-Results
DMARC	*โดเมน From-header ของคุณ — และต้องการโดเมนของ SPF หรือ* `d=` ของ DKIM ให้ตรงกับมัน**	`header.from=` ใน Authentication-Results

นี่คือวิธีที่ส่วนต่างๆ มักไปผิด: แพลตฟอร์ม newsletter หรือ CRM ของคุณส่งโดยมี Return-Path เช่น [email protected], SPF ถูกตรวจสอบกับ vendor.com และผ่าน, DKIM ผ่านด้วย d=vendor.com — และ DMARC ล้มเหลว เพราะไม่มีโดเมนที่ผ่านตรงกับ yourcompany.com การตรวจสอบทุกอย่างบอกความจริง; ไม่มีข้อใดยืนยันตัวตน คุณ การแก้ไขระเบียน SPF ของคุณเองไม่สามารถแก้ไขสิ่งนี้ได้ — มันไม่เคยถูกปรึกษา มันคือกับดักเดียวกับที่ครอบคลุมใน SPF ล้มเหลวสำหรับเครื่องมือ SaaS ของคุณ

สำมะโนแสดงให้เห็นว่า sender น้อยแค่ไหนที่ทำขั้นตอนสุดท้ายนี้สำเร็จ: 27,640,987 ของ 261,086,232 โดเมนที่ได้รับการให้คะแนน (10.59%) มีนโยบาย DMARC ที่บังคับใช้เลย และมีเพียง 7.4% ที่ผ่าน SPF ด้วยการจัดตำแหน่งภายใต้หนึ่งในนั้น ในบรรดา 77.5 ล้านโดเมนที่ SPF ลงท้ายด้วย softfail (~all) มีเพียง 9.2% ที่อยู่ภายใต้นโยบาย DMARC ที่บังคับใช้; ในบรรดาผู้เผยแพร่ hardfail (-all), 12,142,351 ถูกบังคับใช้ในขณะที่ 42,514,532 ไม่ได้บังคับใช้ โดเมนส่วนใหญ่หยุดที่ “SPF ผ่าน” — ซึ่ง หากไม่มี DMARC กระทำกับมัน แทบไม่ปกป้องอะไรเลย

ฉันจะอ่าน Authentication-Results เพื่อดูว่าขาใดไม่จัดตำแหน่งได้อย่างไร?

ส่งข้อความให้ตัวเองผ่านบริการที่ล้มเหลว เปิด source/raw ดั้งเดิม และค้นหา header Authentication-Results ผลลัพธ์ที่ไม่จัดตำแหน่งทั่วไปมีลักษณะดังนี้:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

อ่านมันในสามการเปรียบเทียบ:

ขา SPF: smtp.mailfrom= ลงท้ายด้วยโดเมนของคุณหรือไม่? ที่นี่คือ bounces.espmail.net — ไม่จัดตำแหน่ง
ขา DKIM: header.d= ลงท้ายด้วยโดเมนของคุณหรือไม่? ที่นี่คือ espmail.net — ไม่จัดตำแหน่ง
คำตัดสิน DMARC: header.from= คือโดเมนที่ DMARC ปกป้อง ไม่มีขาใดที่ตรงกับมัน ดังนั้น dmarc=fail — แม้ว่าการตรวจสอบแต่ละรายการจะพูดว่า pass

ขาใดก็ตามที่เกี่ยวข้องกับโดเมนของคุณอยู่แล้ว (หรือสามารถทำได้) คือขาที่จะแก้ไข คุณต้องการเพียง หนึ่ง

ความแตกต่างระหว่างการจัดตำแหน่งแบบ relaxed และ strict คืออะไร?

DMARC เสนอโหมดการจับคู่สอง โหมด ตั้งค่าด้วย tag aspf (SPF) และ adkim (DKIM) ในระเบียน DMARC ของคุณ:

Relaxed (r, ค่าเริ่มต้น): สองโดเมนต้องแชร์ organizational domain เดียวกัน — โดเมนที่ลงทะเบียนได้ตาม Public Suffix List bounce.yourcompany.com จัดตำแหน่งกับ yourcompany.com; DKIM d=mail.yourcompany.com ก็เช่นกัน นี่คือเหตุผลที่ custom return-path และ DKIM ที่กำหนดเองของผู้ขาย ซึ่งอยู่บน subdomain ใช้งานได้
Strict (s): โดเมนต้องตรงกันแน่ๆ ตัวอักษรต่อตัวอักษร bounce.yourcompany.com ไม่จัดตำแหน่งกับ yourcompany.com อีกต่อไป

ถ้าระเบียนของคุณไม่กล่าวถึง aspf หรือ adkim คุณอยู่ในโหมด relaxed — และคุณเกือบแน่นอนต้องการอยู่ที่นั่น โหมด strict ไม่เพิ่มความปลอดภัยที่มีความหมายสำหรับ sender ส่วนใหญ่และทำลาย sender ย่อย subdomain ที่ถูกกฎหมายทุกรายที่คุณตั้งค่าอย่างเงียบๆ ถ้า DMARC ล้มเหลวและระเบียนของคุณมี aspf=s หรือ adkim=s นั่นอาจเป็น bug เพียงอย่างเดียว

ฉันจะแก้ไขการจัดตำแหน่ง DMARC ได้อย่างไร?

สแกนฟรีที่ defaults.exposed ก่อนแตะ DNS มันแสดงระเบียน DMARC และนโยบายของคุณ ว่า SPF และ DKIM ของคุณถูกตั้งค่าให้จัดตำแหน่งหรือไม่ และอะไรอื่นที่เสีย — เพื่อให้คุณแก้ไขขาที่ถูกต้องก่อน
ทดสอบบริการส่งแต่ละรายการและอ่าน Authentication-Results (ตามด้านบน) ระบุทุกแหล่ง — ผู้ให้บริการ mailbox, เครื่องมือ newsletter, CRM, แอป invoicing — และบันทึกต่อแหล่งว่า smtp.mailfrom และ header.d เป็นโดเมนของคุณหรือของผู้ขาย
เปิดใช้งานการลงนาม DKIM ด้วยโดเมนที่กำหนดเองสำหรับผู้ขายแต่ละราย — การแก้ไขที่คงอยู่ บริการส่งจริงจังทุกรายเสนอ “domain authentication”: ระเบียน CNAME สองสามตัวที่ให้มันลงนามเป็น d=yourcompany.com (หรือ subdomain ซึ่งจัดตำแหน่งในโหมด relaxed) DKIM ที่จัดตำแหน่งมักเป็นการแก้ไขที่ง่ายกว่าและเป็นเพียงอย่างเดียวที่รอดชีวิตจากการส่งต่อ เพราะ การส่งต่อทำลาย SPF โดยการออกแบบ
สำหรับการจัดตำแหน่ง SPF เปิดใช้งาน return-path ที่กำหนดเองของผู้ขาย (มักเรียกว่าโดเมน bounce ที่กำหนดเอง) — โดยทั่วไปคือ CNAME หนึ่งตัวเช่น bounce.yourcompany.com ชี้ไปยังผู้ขาย SPF จะผ่านบน organizational domain ของคุณและจัดตำแหน่ง ทำสิ่งนี้ที่มีให้ แต่ปฏิบัติต่อมันเป็นขาที่สอง ไม่ใช่ทดแทน DKIM ที่จัดตำแหน่ง
ทิ้งการจัดตำแหน่งไว้ในโหมด relaxed เว้นแต่คุณมีเหตุผลเฉพาะที่เข้าใจสำหรับ aspf=s/adkim=s
สแกนใหม่และยืนยันทั้งสองขา จากนั้นมุ่งไปสู่การบังคับใช้ นโยบาย DMARC ที่ p=none รายงานแต่ไม่บล็อกอะไร เมื่อ sender จริงของคุณจัดตำแหน่ง เส้นทางเต็มไปสู่นโยบายที่ปกป้องคุณอยู่ในหน้า แก้ DMARC และ walk-through ผู้ให้บริการเช่น DMARC บน IONOS ครอบคลุมการคลิก DNS panel

ฉันควรแก้ไขการจัดตำแหน่ง SPF หรือ DKIM?

คุณต้องการขาที่จัดตำแหน่งหนึ่งขาต่อแหล่งส่ง ถ้าคุณทำได้แค่หนึ่ง การเลือกไม่ใกล้เคียง:

การแก้ไข	สิ่งที่ต้องทำ	รอดชีวิตจากการส่งต่อ?
DKIM ที่จัดตำแหน่ง (การลงนามด้วยโดเมนที่กำหนดเอง)	CNAME สองสามตัวในแผง “domain authentication” ของผู้ขาย	ใช่ — ลายเซ็นเดินทางพร้อมข้อความ
SPF ที่จัดตำแหน่ง (custom return-path/bounce domain)	CNAME หนึ่งตัว ที่ผู้ขายเสนอมัน	ไม่ — IP ของ forwarder ใดๆ แทนที่ IP ของผู้ขาย

กรณีพิเศษที่ควรรู้: Google Workspace และ Microsoft 365 จะลงนาม DKIM อีเมลของคุณ โดยค่าเริ่มต้น ด้วยโดเมน fallback ของตัวเอง (gappssmtp.com, onmicrosoft.com) — ดังนั้น DKIM แสดง pass ในขณะที่ DMARC ยังล้มเหลว มันคือกรณีเฉพาะที่พบบ่อยที่สุดของปัญหาทั้งหมดนี้ และมีคู่มือของตัวเอง: DKIM ผ่านแต่ DMARC ยังล้มเหลว: กับดักลายเซ็นเริ่มต้น

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

ต้องจัดตำแหน่งทั้ง SPF และ DKIM เพื่อให้ DMARC ผ่านหรือไม่? ไม่ — การผ่านที่จัดตำแหน่งหนึ่งครั้งเพียงพอ best practice คือการจัดตำแหน่งทั้งคู่อยู่ดี เพื่อให้เมื่อการส่งต่อทำลายขา SPF ขา DKIM ยังคงถือ pass ของ DMARC ของ 261,086,232 โดเมนที่ได้รับการให้คะแนนในสำมะโน 2026-06-29 มีเพียง 3.87% ที่ทำ triad SPF + DMARC + DKIM ครบ

dashboard ESP ของฉันพูดว่า SPF และ DKIM “ผ่านการยืนยัน” — ทำไม DMARC ยังล้มเหลว? “ผ่านการยืนยัน” มักหมายความว่าการส่งของผู้ขายเองผ่านบนโดเมนของผู้ขาย เว้นแต่คุณทำขั้นตอน custom domain ของพวกเขา (DKIM CNAME, custom return-path) อีเมลยืนยันตัวตนเป็นผู้ขาย ไม่ใช่คุณ — และ DMARC เปรียบเทียบกับโดเมน From ของคุณ

ระเบียน SPF แบบ strict -all เพียงพอหากไม่มีการจัดตำแหน่งหรือไม่? ไม่ qualifier แบบ strict เพิ่มความแข็งแกร่งให้กับคำตัดสินของ SPF บนโดเมน Return-Path แต่ DMARC ยังคงต้องการโดเมนนั้นเป็นของคุณ ณ วันที่ 2026-06-29 ของสำมะโน มีเพียง 12,142,351 ของโดเมนที่เผยแพร่ -all ที่อยู่ภายใต้นโยบาย DMARC ที่บังคับใช้ — อีก 42,514,532 มีระเบียนแบบ strict ที่ไม่มีนโยบายกระทำ

ฉันควรเปลี่ยนเป็นการจัดตำแหน่งแบบ strict (aspf=s/adkim=s) เพื่อความปลอดภัยมากขึ้นหรือไม่? แทบไม่เคย การจัดตำแหน่งแบบ relaxed ยังคงต้องการ registrable domain เดียวกัน ซึ่ง spoofer ไม่ควบคุม โหมด strict ส่วนใหญ่ทำลาย sender ย่อย subdomain ของคุณเอง — ตรวจสอบมันเมื่อการจัดตำแหน่งล้มเหลวโดยไม่คาดคิด

DMARC ล้มเหลวเฉพาะบนอีเมลที่ผู้รับส่งต่อ — การแก้ไขเดียวกันหรือไม่? นั่นคือขา SPF ที่ตายระหว่างการส่ง: เซิร์ฟเวอร์ของ forwarder ไม่อยู่ในระเบียน SPF ของใครเลยสำหรับ return-path ของคุณ คุณไม่สามารถแก้ไข SPF สำหรับอีเมลที่ส่งต่อได้; DKIM ที่จัดตำแหน่งคือคำตอบ เนื่องจากลายเซ็นรอดชีวิตจากการส่งต่ออย่างสมบูรณ์ รายละเอียดใน อีเมลที่ส่งต่อล้มเหลว SPF

ส่งรายงานให้เจ้าของ

หากคุณแก้ไขปัญหานี้สำหรับลูกค้าหรือนายจ้างของคุณ ปิดลูปด้วยหลักฐาน รันใหม่ การสแกนฟรี หลังจาก CNAME เสร็จสมบูรณ์และส่งต่อรายงานที่ได้รับการให้คะแนนให้เจ้าของธุรกิจ: มีวันที่ ภาษาธรรมดา แสดง SPF, DKIM และ DMARC จัดตำแหน่งและผ่าน นั่นคือสิ่งประดิษฐ์ที่พวกเขาจะต้องใช้สำหรับการต่ออายุประกันภัยไซเบอร์และแบบสอบถามความปลอดภัยผู้จัดหาถัดไป — หลักฐานของการกำหนดค่าที่ทำงาน ไม่ใช่แค่ “ฉันเพิ่ม DNS records บางตัว”

ตรวจสอบโดเมนของคุณ → · DKIM ผ่านแต่ DMARC ยังล้มเหลว → · แก้ DMARC → · วิธีที่เราให้คะแนน → · ข้อมูลรวมเท่านั้น ข้อมูลถูกจัดเก็บและประมวลผลในสหภาพยุโรป