Defaults.Exposed › รายงาน
SPF ~all vs -all: Softfail หรือ Hardfail — สิ่งที่ 139 ล้านบันทึกเลือก (2026)
เผยแพร่ 2026-07-03
ตัวเลข ณ 2026-06-29 · วิธีการ v7 ข้อมูลสำมะโนรวมจาก 261 ล้านโดเมนที่ได้รับการให้คะแนน ตัวเลขทั้งหมดเป็นภาพรวม — เราไม่เคยเผยแพร่บันทึกของธุรกิจแต่ละราย ดู วิธีที่เราให้คะแนน
ทุกบันทึก SPF จบด้วยกลไก “all” — คำตัดสินเกี่ยวกับเมลจากที่ไหนก็ตามที่ไม่อยู่ในรายการของคุณ — และอินเทอร์เน็ตได้เลือกแบบ soft อย่างท่วมท้น: 55.8% ของ 139 ล้านโดเมนที่เผยแพร่ SPF จบด้วย ~all (softfail) เทียบกับ 39.3% ที่จบด้วย -all (hardfail) อักขระหนึ่งตัวคั่นระหว่าง “ปฏิเสธการปลอมแปลง” กับ “น่าจะเป็นการปลอมแปลง — ส่งไปก็ได้” ตัวไหนถูกต้องสำหรับคุณขึ้นอยู่กับการตั้งค่าที่สองที่เจ้าของส่วนใหญ่ไม่เคยกำหนดค่า
~all และ -all บอกผู้รับจริง ๆ ว่าอะไร?
-all(hardfail): “ปฏิเสธเมลจากที่อื่น” ปฏิเสธอย่างชัดเจน~all(softfail): “เมลจากที่อื่นน่าจะไม่ถูกต้อง — รับไว้ อาจทำเครื่องหมายไว้” การยักไหล่?all(neutral): “ไม่มีความเห็น” เลือกโดย 3.0% ของผู้เผยแพร่; การป้องกันในนามเท่านั้น+all: “ใครก็ส่งในนามฉันได้” เผยแพร่โดย 36,014 โดเมน และแย่กว่าไม่มีบันทึก — ปัญหา welcome-mat มีรายงานของตัวเอง
~all ผิดหรือเปล่า? เฉพาะถ้ามันอยู่คนเดียว — และมักจะเป็นอย่างนั้นเสมอ
Softfail มีกรณีที่ป้องกันได้ในยุคปัจจุบัน: แนวปฏิบัติของ Google สำหรับผู้ส่ง และแนวปฏิบัติด้านการส่งมอบส่วนใหญ่ที่ตามมา ล้วนรวมกันที่ ~all จับคู่กับนโยบาย DMARC ที่บังคับใช้ (p=reject) การจับคู่นี้ให้การป้องกันดีพอ ๆ กับ -all ที่ผู้รับที่ประเมิน DMARC ทุกรายการ — ซึ่งตอนนี้รวมผู้ให้บริการกล่องข้อความหลักทั้งหมด — โดยไม่ bounce เมลที่ถูกส่งต่อที่ถูกต้อง ซึ่งเป็นเหยื่อคลาสสิกของ -all ในการกำหนดค่านั้น การยักไหล่มีฟัน: DMARC ให้คำตัดสินที่ SPF ปฏิเสธที่จะให้
แต่การจับคู่คือประเด็นทั้งหมด และนี่คือสิ่งที่สำมะโนเพิ่มเติมที่คู่มือการตั้งค่าไม่สามารถทำได้: จาก 77,484,057 บันทึก softfail บนอินเทอร์เน็ต มีเพียง 7.1 ล้าน — ประมาณ 1 ใน 11 — ที่มีนโยบาย DMARC ที่บังคับใช้อยู่เบื้องหลัง สำหรับอีก 70.4 ล้านโดเมน ~all คือสิ่งที่ฟังดูตามตัวอักษร บันทึกของพวกเขาระบุการปลอมแปลงและส่งผ่าน
คำสั่งของปี 2024 ไม่ได้แก้ปัญหานี้หรือ?
ไม่ — และความแตกต่างมีความสำคัญมากกว่าที่รายงานส่วนใหญ่แนะนำ Google และ Yahoo เริ่มต้องการการยืนยันตัวตนจากผู้ส่งจำนวนมากในเดือนกุมภาพันธ์ 2024 โดย Microsoft ตามมาในเดือนพฤษภาคม 2025: ผ่าน SPF หรือ DKIM ที่สอดคล้อง บวกกับบันทึก DMARC ที่ อย่างน้อย p=none คำสั่งเหล่านี้หยุดสั้นจากการต้องการ การบังคับใช้ — โดเมนที่มี ~all, บันทึก p=none และ DKIM ที่สอดคล้องปฏิบัติตามอย่างครบถ้วน และยังสามารถถูกปลอมแปลงได้อย่างครบถ้วน คำสั่งได้ทำให้เอกสารกลายเป็นมาตรฐาน ไม่ใช่การป้องกัน ส่วนกลางที่ไม่มีการบังคับใช้ — ปฏิบัติตาม เผยแพร่แล้ว ปลอมแปลงได้ — เป็นช่องว่างที่สำมะโนนี้วัด และเป็นจำนวนประชากรที่ใหญ่ที่สุดในด้านความปลอดภัยอีเมล
แล้วบันทึกของคุณควรจบด้วยอะไร?
- คุณส่งเมลและการส่งต่อสำคัญ (จดหมายข่าว รายชื่อเมล aliases):
~allพร้อม DMARCp=rejectอยู่เบื้องหลัง — การจับคู่ที่แนะนำด้านบน - คุณส่งเมลจากการตั้งค่าที่ควบคุมอย่างเข้มงวด:
-allใช้งานได้และระบุนโยบายในบันทึกเอง แมปผู้ส่งของคุณก่อน — การจบที่เข้มงวดบนบันทึกที่ไม่ได้แมป ทำลายเมลจริง หรือแย่กว่านั้น - โดเมนไม่เคยส่ง:
-allบวกกับp=rejectวันนี้เลย ไม่มีสิ่งที่ถูกต้องที่ต้องปกป้อง ดังนั้นไม่มีอะไรที่จะทำลาย
ไม่ว่าคุณจะเลือกการจบแบบใด บทเรียนบรรทัดเดียวของสำมะโนยังคงอยู่: qualifier ช่วยได้มากเท่ากับสิ่งที่บังคับใช้มันเท่านั้น ตำแหน่งของคุณบนบันไดนั้น วัดได้
คำถามที่พบบ่อย
SPF ~all หรือ -all ดีกว่ากัน?
ไม่มีตัวไหนดีกว่าสากล ~all พร้อมนโยบาย DMARC ที่บังคับใช้คือรูปแบบที่แนวปฏิบัติของ Google แนะนำ — การป้องกันเท่ากันที่ผู้รับที่ประเมิน DMARC โดยไม่ทำลายเมลที่ส่งต่อ -all เหมาะกับผู้ส่งที่ควบคุมอย่างเข้มงวด ~all เพียงอย่างเดียว — สถานะของโดเมน softfail ทั้งหมด ยกเว้น 1 ใน 11 — คือตัวเลือกที่อ่อนแอ
SPF softfail หมายความว่าอะไร?
~all บอกผู้รับว่าเมลจากเซิร์ฟเวอร์ที่ไม่ได้อยู่ในรายการน่าจะไม่ถูกต้องแต่ควรยังรับไว้ มักพร้อมความสงสัย มันกลายเป็นการป้องกันจริงเฉพาะเมื่อนโยบาย DMARC ดำเนินการกับความล้มเหลว; ดู SPF ที่ไม่มี DMARC
Hardfail -all จะทำให้อีเมลที่ส่งต่อของฉันพัง?
มันอาจ: การส่งต่อส่งเมลของคุณใหม่จากเซิร์ฟเวอร์ของผู้ส่งต่อ ซึ่ง SPF ของคุณไม่ได้ระบุ และ hardfail เชิญให้ปฏิเสธก่อนที่ DKIM หรือ DMARC จะชั่งน้ำหนัก นั่นคือเหตุผลที่การจับคู่ ~all + p=reject มีอยู่
Google และ Microsoft ต้องการ -all ตอนนี้หรือไม่?
ไม่ คำสั่งสำหรับผู้ส่งจำนวนมากต้องการการยืนยันตัวตนที่ผ่านและสอดคล้องกัน และบันทึก DMARC ที่อย่างน้อย p=none — ไม่มีการบังคับใช้ ไม่มี qualifier เฉพาะ การปฏิเสธเมลที่ไม่ปฏิบัติตามจำนวนมากของ Google มีผลแล้ว Microsoft กำลังส่งความล้มเหลวไปที่ junk และเคลื่อนไปสู่การปฏิเสธโดยตรง การปฏิบัติตามไม่ใช่การป้องกัน
ตรวจสอบว่าบันทึกของคุณจบด้วยอะไร — และอะไรอยู่เบื้องหลัง
การค้นหาสองครั้งบอกคุณทั้งสองอย่าง ฟรี ใน 30 วินาที หากคุณเป็นหนึ่งในการยักไหล่ที่ไม่มีการบังคับใช้ 70.4 ล้าน การแก้ไขคือบันทึก DNS ไม่ใช่การซื้อ
ตรวจสอบโดเมนของคุณ → · แก้ไข SPF → · แก้ไข DMARC → · โมเดลความสมบูรณ์ SPF → · แผนที่ +all → · เฉพาะข้อมูลรวม ข้อมูลจัดเก็บและประมวลผลในสหภาพยุโรป